GNOME Bugzilla – Bug 303408
Give user more control over what parts of styles to move when sorting
Last modified: 2018-05-22 13:10:42 UTC
Distribution/Version: Debian sid (unstable) Originally reported as http://bugs.debian.org/308068. I've verified that this problem is reproducible with a build of HEAD. Subject: Bug#308068: gnumeric: Sorting does not update hyperlinks From: Ian Turner <vectro@yahoo.com> Date: Sat, 7 May 2005 09:51:12 -0700 Package: gnumeric Version: 1.4.3-4 Severity: normal When sorting data, hyperlinks stay fixed according to cell location. For example, if you have the following: A ----- 1 XYZ <- Linked to http://www.xyzmusic.com/ 2 ABC <- Linked to http://abc.go.com/ and then you sort the spreadsheet, you end up with: A ----- 1 ABC <- Linked to http://www.xyzmusic.com/ 2 XYZ <- Linked to http://abc.go.com/ Which is obviously not correct. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages gnumeric depends on: ii gconf2 2.8.1-5 GNOME configuration database syste ii gnumeric-common 1.4.3-4 common files for Gnumeric, the GNO ii gsfonts 8.14+v8.11+urw-0.2 Fonts for the Ghostscript interpre ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit ii libbonobo2-0 2.8.1-2 Bonobo CORBA interfaces library ii libbonoboui2-0 2.8.1-2 The Bonobo UI library ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libgconf2-4 2.8.1-5 GNOME configuration database syste ii libglade2-0 1:2.4.2-2 library to load .glade files at ru ii libglib2.0-0 2.6.4-1 The GLib library of C routines ii libgnome2-0 2.8.1-2 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.8.0-1 A powerful object-oriented display ii libgnomeprint2.2-0 2.8.2-1 The GNOME 2.2 print architecture - ii libgnomeprintui2.2-0 2.8.2-2 GNOME 2.2 print architecture User ii libgnomeui-0 2.8.1-3 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.8.4-2 The GNOME virtual file-system libr ii libgsf-1 1.11.1-1 Structured File Library - runtime ii libgsf-gnome-1 1.11.1-1 Structured File Library - runtime ii libgtk2.0-0 2.6.4-1 The GTK+ graphical user interface ii libice6 4.3.0.dfsg.1-12.0.1 Inter-Client Exchange library ii liborbit2 1:2.12.1-1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libsm6 4.3.0.dfsg.1-12.0.1 X Window System Session Management ii libxml2 2.6.16-7 GNOME XML library ii xlibs 4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-3 compression library - runtime -- no debconf information
Created attachment 46138 [details] Testcase Sorting this by the A column illustrates the problem reported.
Whetehr the hyperlinks moved used to be connected to the "sorting preserves format" setting but apparently that has changed.
Sorry,I was mistaken. It works correctly. If you want to have the hyperlinks move you need to deselect "preserve formats". Note that you can set in the preference dialog whether "preserve formats" is on by default. *** This bug has been marked as a duplicate of 127613 ***
Hmm. My imagination may be lacking, but it's hard for me to see under what circumstances the current behaviour would be correct. Reopening.
One can currently choose which behaviour one wants (links attached to the content or links attached to the location). How can that choice be wrong? It is up to you to select the right option.
This is clearly a dupe of bug 127613. But sure, we can discuss the issue here. Andreas: "How can that choice be wrong?" Easy. If you have an alternate colour background and hyperlinks you might want to leave the background alone but move the hyperlinks.
Morten, your colour-background/hyperlink example is of course not really hyperlink specific. One can find such examples with many formatting issues. For example specific important items may have a red background colour but the top item has a double border on the top. So sorting should move the back ground colour but not the borders. I view the hyperlinks as such another such format they may or may not need to be attached tot the content rather than the location.
This is one of those areas where differences in our data structures are exposed. We store hyperlinks/validation/conditional fmts/input messages as part of the style. XL seems to store them seperately. At this point I have no plans to split them. We could conceivable provide a ui to move only _part_ of the style when sorting. Instead of 'sorting preserves fmt' we would have sort includes [] borders [] links [] ... that may get somewhat unwieldy unless we can provide an MS style combo with toggle buttons.
*** Bug 346131 has been marked as a duplicate of this bug. ***
*** Bug 514165 has been marked as a duplicate of this bug. ***
I was going to report this as a bug too, because "preserve formats" means the opposite of what I thought it meant.
Well I guess we can argue whether "preserve format" means that we keep the format with the content or with the cell location. I understand it as it preserves the formatting of the string (which may move under sort) rather than the formatting of the cell location.
*** Bug 527146 has been marked as a duplicate of this bug. ***
*** Bug 529269 has been marked as a duplicate of this bug. ***
*** Bug 554206 has been marked as a duplicate of this bug. ***
*** Bug 559048 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/38.