On Thu, 2005-07-14 at 10:34 +0200, Christian Neumair wrote: > Am Mittwoch, den 13.07.2005, 14:09 +0200 schrieb Alexander Larsson: > > On Wed, 2005-07-13 at 13:51 +0200, Christian Neumair wrote: > > > Am Mittwoch, den 13.07.2005, 13:45 +0200 schrieb Alexander Larsson: > > > > On Tue, 2005-07-12 at 18:19 +0200, Christian Neumair wrote: > > > > > From bug 150116 [1]: > > > > > > > > > > "When trying to select a range of files if ordering is set to manual, > > > > > the range of files is determined by file names instead of spatial > > > > > location. > > > > > > > > > > This is especially obvious on the desktop where there is no auto-sort." > > > > > > > > > > Proposed patch attached. If you don't like the two separate code-paths > > > > > mangled into one function (like classic C coders do), we can also split > > > > > these two loops out into separate functions. > > > > > > > > > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=150116 > > > > > > > > > > > > > + x0 = MIN (icon1->x, icon2->x); > > > > + x1 = MAX (icon1->x, icon2->x); > > > > + y0 = MIN (icon1->y, icon2->y); > > > > + y1 = MAX (icon1->y, icon2->y); > > > > > > > > This doesn't look entierly right. Surely you want the whole part of the > > > > icons, not just its position (which i think is the corner? don't > > > > remember exactly). > > > > > > Yes, as far as I know it's the upper-left corner. What's wrong with it? > > > You think we should also select items which just "touch"/intersect the > > > range to be selected instead of matching only those that are actually > > > contained within the range? > > > > consider this case: > > > > a > > bc > > > > where b and c really overlap vertically, except c is one pixel above b. > > Now, range select on a-c will not select b, even though its basically > > beside it to the left. Maybe a better approach would to pick positions > > in the middle of a and c and pick any icons that intersect that. > > At least for the desktop a one-pixel offset is not possible. If I > pressed shift and clicked on a particular file, I wouldn't expect that > anything gets selected which is "more adjacent" (i.e. only intersects > the range between the two selection items). So for the desktop I > actually think that the behavior introduced by the patch is better than > what you propose, which might be appropriate for non-desktop icon views. Not possible? Do you mean with "keep aligned" enabled? Not everyone has that enabled. And even with that enabled, one icon might be one pixel taller, and thus one pixel above it. In the attached image of my desktop, your range select algorithm doesn't include the middle icon. I'm pretty sure this is not what most people expect. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl redhat com alla lysator liu se He's an underprivileged native American waffle chef fleeing from a secret government programme. She's a virginal extravagent safe cracker with her own daytime radio talk show. They fight crime!
Attachment:
icons.png
Description: PNG image
