From: Brian M. <bma...@ma...> - 2002-02-26 07:01:21
|
Interesting things about views: if you hold down shift, you can select icons in different views (same dir or not). views don't redraw until they've been focused on once. Open a dir twice (the second will be on top of the first), move the top one, and observe the bottom one. I'm close to getting and implementation of the reworked layout finished. I added a view_layout module that loads a bits file, and sizes it to the view, and then creates structs with the geometry of each of its bits, and their name (more, such as class, can be added later). Then, you can simply do: e_view_layout_get_element_geometry(v->layout, "Iconbar", &x, &y, &w, &h); to get the geometry for the iconbar. This works for anything, just give it the name of the element you want, and it will return the geometry of the corresponding bit of the layout db (the one with the same name). So basically, its just an abstraction of the ebits calls, that stores the info, only updating it on resizes, and could contain more info later. I have the iconbar and scrollbars getting their geometry this way, and a quick hack for the file icons (it sets the view->window->spacing.l,r,t,b values). We should probably clip the icons to the area specified. It looks as though the icon layout code needs a bit of reworking. So, if you have a .e_layout dir, with a layout.bits.db it will use that info, otherwise it will use a system wide version (either desktop.bits.db or view.bits.db in data/layout). The iconbar only looks in the .e_layout dir at the moment, and the scrollbars look local first, then system. I need to work out a few more kinks (for some reason iconbars aren't loading in non-desktop views), and then i'll commit, so within the next few days probably. just wanted to give a heads up. -- brian |
From: Christian K. <kre...@in...> - 2002-02-26 10:46:20
|
Brian Mattern wrote: > > I'm close to getting and implementation of the reworked layout finished. > I added a view_layout module that loads a bits file, and sizes it to the > view, and then creates structs with the geometry of each of its bits, > and their name (more, such as class, can be added later). Then, you can > simply do: > e_view_layout_get_element_geometry(v->layout, "Iconbar", &x, &y, &w, &h); > to get the geometry for the iconbar. This works for anything, just give > it the name of the element you want, and it will return the geometry of > the corresponding bit of the layout db (the one with the same name). So > basically, its just an abstraction of the ebits calls, that stores the > info, only updating it on resizes, and could contain more info later. Nice, that should provide everything we need. Do you think an overlay ebit to give the layout an integrated look (like I mentioned yesterday) makes sense? > I have the iconbar and scrollbars getting their geometry this way, and a > quick hack for the file icons (it sets the view->window->spacing.l,r,t,b > values). We should probably clip the icons to the area specified. It > looks as though the icon layout code needs a bit of reworking. If you revamp that, try to keep it as flexible as possible, so that we could have layouts that look completely different (list views, small-icon mode etc) and can switch layout modes easily :) Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Till A. <ti...@ad...> - 2002-02-26 17:42:44
|
# Quoting Brian Mattern (bma...@ma...): > if you hold down shift, you can select icons in different views (same > dir or not). Hm, true. Is that a bug or a feature? ;) No, seriously, what would be the most sensible policy for this? Disallow selects in all views of a dir as soon as one view has selected something in the dir ( view_model->something_selected flag)? How about selects acros views of different dirs? This could be nice to have, actually. Select 2 files in dir a, select another 3 in dir b and drag them all to c. What's your take, guys? > views don't redraw until they've been focused on once. Open a dir twice > (the second will be on top of the first), move the top one, and observe > the bottom one. hihi. I'll fix that. > I'm close to getting and implementation of the reworked layout finished. > I added a view_layout module that loads a bits file, and sizes it to the > view, and then creates structs with the geometry of each of its bits, > and their name (more, such as class, can be added later). Then, you can > simply do: > e_view_layout_get_element_geometry(v->layout, "Iconbar", &x, &y, &w, &h); > to get the geometry for the iconbar. This works for anything, just give > it the name of the element you want, and it will return the geometry of > the corresponding bit of the layout db (the one with the same name). So > basically, its just an abstraction of the ebits calls, that stores the > info, only updating it on resizes, and could contain more info later. nice > I have the iconbar and scrollbars getting their geometry this way, and a > quick hack for the file icons (it sets the view->window->spacing.l,r,t,b > values). We should probably clip the icons to the area specified. It > looks as though the icon layout code needs a bit of reworking. Amen! > So, if you have a .e_layout dir, with a layout.bits.db it will use that > info, otherwise it will use a system wide version (either > desktop.bits.db or view.bits.db in data/layout). The iconbar only looks > in the .e_layout dir at the moment, and the scrollbars look local first, > then system. Sounds good, too. Till |
From: Christian K. <kre...@in...> - 2002-02-27 20:08:25
|
Till Adam wrote: > > # Quoting Brian Mattern (bma...@ma...): > > > if you hold down shift, you can select icons in different views (same > > dir or not). > > Hm, true. Is that a bug or a feature? ;) No, seriously, what would be > the most sensible policy for this? Disallow selects in all views of a > dir as soon as one view has selected something in the dir ( > view_model->something_selected flag)? How about selects acros views of > different dirs? This could be nice to have, actually. Select 2 files in dir a, > select another 3 in dir b and drag them all to c. What's your take, > guys? Simply dispatch the selects -- if you (de)select an icon in instance 1, it should become (de)selected in the remaining instances as well. Anything done to any view instance should be reflected in the other instances as well. Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Till A. <ti...@ad...> - 2002-02-27 21:26:13
|
# Quoting Christian Kreibich (kre...@in...): > Simply dispatch the selects -- if you (de)select an icon in instance 1, > it should become (de)selected in the remaining instances as well. > Anything done to any view instance should be reflected in the other > instances as well. Really think so? I tend to think the way I made it behave today is less confusing. But your way is possible, of course. Other opinions on this? Till |
From: Christian K. <kre...@in...> - 2002-02-27 21:55:50
|
Till Adam wrote: > > # Quoting Christian Kreibich (kre...@in...): > > > Simply dispatch the selects -- if you (de)select an icon in instance 1, > > it should become (de)selected in the remaining instances as well. > > Anything done to any view instance should be reflected in the other > > instances as well. > > Really think so? I tend to think the way I made it behave today is less > confusing. But your way is possible, of course. Other opinions on this? What way is that (sorry had very little time for email today). I definitely think so. Otherwise, how could it be consistent? If you select a couple files in one view, go to a different desktop, look at a second instance of the view there, you wouldn't know what's already selected and what not ... Basically, think multiple frames in XEmacs. Everything is duplicated if you edit two views of a document side by side. Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Till A. <ti...@ad...> - 2002-02-27 22:20:00
|
# Quoting Christian Kreibich (kre...@in...): > What way is that (sorry had very little time for email today). I > definitely think so. Otherwise, how could it be consistent? If you > select a couple files in one view, go to a different desktop, look at a > second instance of the view there, you wouldn't know what's already > selected and what not ... Currently selecting something in a view locks all other views of this dir from selection. So once you start selecting in a view, as long as something in that view is selected, you just cant select anything in the other views of that dir. Come to think of it, if I select something in a view then open another view of the same dir that view will currently not be blocked. So I guess I better forget about that route alltogether and do it your way :). Till |
From: Christian K. <kre...@in...> - 2002-02-27 22:29:56
|
Till Adam wrote: > > Currently selecting something in a view locks all other views of this > dir from selection. So once you start selecting in a view, as long as > something in that view is selected, you just cant select anything in the > other views of that dir. Oooh that's not so good imho -- it's a restriction no user will understand, only the coders who see that it was easier to implement :o) > Come to think of it, if I select something in a view then open another view > of the same dir that view will currently not be blocked. So I guess I > better forget about that route alltogether and do it your way :). It's just my view (pun :). Let's see what the others are thinking. Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Brendon D. <bda...@ma...> - 2002-02-28 00:58:28
|
On Wed, 2002-02-27 at 16:27, Christian Kreibich wrote: > Till Adam wrote: > > > > Currently selecting something in a view locks all other views of this > > dir from selection. So once you start selecting in a view, as long as > > something in that view is selected, you just cant select anything in the > > other views of that dir. > > Oooh that's not so good imho -- it's a restriction no user will > understand, only the coders who see that it was easier to implement :o) > > > Come to think of it, if I select something in a view then open another view > > of the same dir that view will currently not be blocked. So I guess I > > better forget about that route alltogether and do it your way :). > > It's just my view (pun :). Let's see what the others are thinking. Guess I'll throw in my opinion then for whatever it's worth... I think selecting something in one instance of a view automatically selecting it in all other instances of that view is just plain wrong. It just doesn't seem to make any sense. I just took a quick little poll of 10 linux users and 4 windows users to see what they thought and they all thought I was insane for even thinking of that. Not to say you're insane, cK :) I'm just saying that to most (as far as i can tell) people, it makes much more sense the other way. Brendon > Christian. > -- > ________________________________________________________________________ > http://www.whoop.org > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel |
From: Christian K. <kre...@in...> - 2002-02-28 10:52:03
|
Brendon Davidson wrote: > > Guess I'll throw in my opinion then for whatever it's worth... I think > selecting something in one instance of a view automatically selecting it > in all other instances of that view is just plain wrong. It just > doesn't seem to make any sense. I just took a quick little poll of 10 > linux users and 4 windows users to see what they thought and they all Clearly not a significant random sample, especially since it includes windows users :o) Just kidding of course. > thought I was insane for even thinking of that. Not to say you're > insane, cK :) I'm just saying that to most (as far as i can tell) > people, it makes much more sense the other way. Michael Jennings wrote: > > Multiple views are useless if they are not independent of each other. > Even Microsoft knows that one. As far as I can see, Microsoft allows selections in only a single view at all times, even for different directories. So they have decided to take the easiest route of all I guess. I dare say they messed even that up -- select a bunch of files in one view in Win98. Ctrl-select others in the view of a different directory -- you end up with files selected that you were never interested in. Not sure if that changed in later versions. Anyway I caused Explorer to crash when opening the C: drive yesterday on XP (see the news on my website) on a friend's laptop, so I'm not really keen on finding out :) > Beware of confusing or too closely associating "views" with the > objects they are viewing. Flexibility and power comes from > *de*coupling objects from each other, not binding ourselves by > arbitrary associations. Multiple view instances are just that -- multiple views of the same files. A file is either selected or it isn't. We're allowing selections in multiple views, so I think it's important to be consistent. I don't think that's an arbitrary association. I think my way actually *helps* the user -- say you select a couple files in a view on desktop 1, then go to desktop 2, where you have a view for the same directory open, and it doesn't show you your existing selection. By accident you forget to push ctrl or shift when selecting additional files, so you don't event notice that you've lost the selection in the view on desktop 1 until you see the result of a following drag operation. What benefit does it have to not reflect selections in other views, when the effect is the same? Anyway, I'm apparently the only one with that pov, so I'll shut up now. I can always add that in my local version :) Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Alan S. <ala...@in...> - 2002-02-28 12:57:42
|
* Christian Kreibich (kre...@in...) wrote: > As far as I can see, Microsoft allows selections in only a single view > at all times, even for different directories. So they have decided to > take the easiest route of all I guess. I dare say they messed even that > up -- select a bunch of files in one view in Win98. Ctrl-select others > in the view of a different directory -- you end up with files selected > that you were never interested in. > > Not sure if that changed in later versions. Anyway I caused Explorer to > crash when opening the C: drive yesterday on XP (see the news on my > website) on a friend's laptop, so I'm not really keen on finding out :) I just needed to try that, since I've got an xp box not far. It seems that xp (and probably older win versions) makes a difference between "selected" and "currently selected". Selected means it's highlighted, and many things on many views may be selected. Each view is independent: you may have some things selected in one, and others in another view of the same directory. "currently selected" is simply what is selected in the active view, and that's what is going to be affected by the action you make. So the only way to move things from several directories is to have a view that lets you see several directories at once (like a tree view). I hope that clarifies things as how win does it. Now I think I'd like to have consistent selection among views: a file that is selected in one should appear in all the views that display the file (even if a filter is on) as selected. Alan -- The hacker: someone who figured things out and made something cool happen. |
From: Till A. <ti...@ad...> - 2002-02-28 17:22:05
|
Ok, may I propose the following compromise: default behaviour: - the list of selected icons is independent for each view - drag and drop operates only on the files selected in the current view (the one with focus) That's the way Explorer and Konqueror do it, I believe and I think users would be least surprised by this. Modifier-key enabled power user behaviour ;) - the list of selected icons is still independent for each view - drag and drop operates on the logical OR of all files selected in all views. That means if two views of the same dir are open and a file is selected in one, but not the other, it is included in the list. Sounds reasonable? Protest loudly to prevent me from implementing this, please ;) Till |
From: Michael J. <e-...@ka...> - 2002-02-28 17:31:00
|
On Thursday, 28 February 2002, at 17:06:39 (+0100), Till Adam wrote: > Ok, may I propose the following compromise: > > default behaviour: > > - the list of selected icons is independent for each view > - drag and drop operates only on the files selected in the current view > (the one with focus) > > That's the way Explorer and Konqueror do it, I believe and I think users > would be least surprised by this. > > Modifier-key enabled power user behaviour ;) > > - the list of selected icons is still independent for each view > - drag and drop operates on the logical OR of all files selected in all > views. That means if two views of the same dir are open and a file is > selected in one, but not the other, it is included in the list. > > Sounds reasonable? > > Protest loudly to prevent me from implementing this, please ;) That's the best idea I've heard so far. Especially compared with Bowis and his semi-transparent this and pseudo-linked invisible that. :P Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> n+1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "I have gotten into the habit of recording important meetings. One never knows when an inconvenient truth will fall between the cracks and vanish." -- Ambassador Londo Mollari, Babylon Five |
From: Peter J. <ta...@hi...> - 2002-03-01 03:25:38
|
> Modifier-key enabled power user behaviour ;) > > - the list of selected icons is still independent for each view > - drag and drop operates on the logical OR of all files selected in all > views. That means if two views of the same dir are open and a file is > selected in one, but not the other, it is included in the list. I don't really understand the allure of this approach. From my perspective, it will save me a drag for each view beyond the first from which I want to copy, but it will add a whole boatload of confusion. What if I have something selected in one view and accidentally add some things into that "selection group" from another view? I like the idea of continuing in the vein of Explorer and Konqueror and having a single selection set in a single view across the entire window manager. If we want to go balls-out, we could take a page from the book of WarCraft, and be able to assign selection sets to number keys. ;) pete -- http://www.hiddenrock.com "I see that I have turned my eyes to a treasure no less dear than the treasure of Thingol that Beren once desired." |
From: Nathan I. <ningerso@d.umn.edu> - 2002-02-28 17:17:10
|
On Thu, Feb 28, 2002 at 11:37:29AM +0100, Christian Kreibich is quoted as saying: > > Anyway, I'm apparently the only one with that pov, so I'll shut up now. > I can always add that in my local version :) If you do, please make the patch available, I (and I'm sure others) would like that feature as well. Thanks, RbdPngn --------------------------------------------------------------------------- | Nathan Ingersoll | Computer Science/Mathematics | | mailto: ningerso@d.umn.edu | University of Minnesota-Duluth | | http://umn.edu/~ningerso | http://www.d.umn.edu | --------------------------------------------------------------------------- |
From: Michael J. <e-...@ka...> - 2002-02-28 17:37:01
|
On Thursday, 28 February 2002, at 11:37:29 (+0100), Christian Kreibich wrote: > Multiple view instances are just that -- multiple views of the same > files. Agreed. > A file is either selected or it isn't. Agreed. On a per-view basis. :) > We're allowing selections in multiple views, so I think it's > important to be consistent. I don't think that's an arbitrary > association. Sure it is. It's like Emacs letting you have 2 views of the same file but insisting that you view the same portion of the file in each view. I will agree that each view should reflect the current state of the files on disk. If a file is deleted in one view, it should disappear in all views. But each view should be independent in terms of selection, arrangement of icons, area in view, size, etc. > I think my way actually *helps* the user -- say you select a couple > files in a view on desktop 1, then go to desktop 2, where you have a > view for the same directory open, and it doesn't show you your > existing selection. By accident you forget to push ctrl or shift > when selecting additional files, so you don't event notice that > you've lost the selection in the view on desktop 1 until you see the > result of a following drag operation. Confusion (n.) - having operations in a file manager affect selections in non-focused views, esp. views that are hidden on other desktops. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> n+1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Pleure pas petite sirene, la ville dort encore. Ton histoire commence a peine. Pleure pas petite sirene, le jour attend dehors dans les brumes et les fontaines." -- Francis Cabrel |
From: Christian K. <kre...@in...> - 2002-02-28 21:40:41
|
Michael Jennings wrote: > > I will agree that each view should reflect the current state of the > files on disk. If a file is deleted in one view, it should disappear > in all views. But each view should be independent in terms of > selection, arrangement of icons, area in view, size, etc. We agree in all that, except for the selections :) > > I think my way actually *helps* the user -- say you select a couple > > files in a view on desktop 1, then go to desktop 2, where you have a > > view for the same directory open, and it doesn't show you your > > existing selection. By accident you forget to push ctrl or shift > > when selecting additional files, so you don't event notice that > > you've lost the selection in the view on desktop 1 until you see the > > result of a following drag operation. > > Confusion (n.) - having operations in a file manager affect selections > in non-focused views, esp. views that are hidden on other desktops. ergonomic (adj.) - property of a file manager that doesn't make people waste efforts on memorizing what they selected where to make best use of it or what different behaviour they need to be aware of when manipulating files from multiple view instances. solution (n.) - making solutions to controversial issues configurable. Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Chris b. R. <ch...@da...> - 2002-02-28 08:28:58
|
On Wed, Feb 27, 2002 at 10:53:34PM +0100, Christian Kreibich muttered... : Till Adam wrote: : > : > # Quoting Christian Kreibich (kre...@in...): : > : > > Simply dispatch the selects -- if you (de)select an icon in instance 1, : > > it should become (de)selected in the remaining instances as well. : > > Anything done to any view instance should be reflected in the other : > > instances as well. : > : > Really think so? I tend to think the way I made it behave today is less : > confusing. But your way is possible, of course. Other opinions on this? : : What way is that (sorry had very little time for email today). I : definitely think so. Otherwise, how could it be consistent? If you : select a couple files in one view, go to a different desktop, look at a : second instance of the view there, you wouldn't know what's already : selected and what not ... You could have a shadowed 'selection' - so say in view A of /path I select file 'a' and 'b', when in view B of /path i see a transparent selection of 'a' and 'b' [looks like a ghost version of normal selection, so I know they have been selected somewhere] : Basically, think multiple frames in XEmacs. Everything is duplicated if : you edit two views of a document side by side. The ability to lock view together like in konqueror would be cool :) Regards, Chris -- +------------------------------------------------------------------+ | Chris Ross | ch...@da... | ct...@fe... | | | http://www.darkrock.co.uk | http://www.ferite.org | +------------------------------------------------------------------+ "SYSOP \sis' op\ n: the person laughing as you type." |
From: Till A. <ti...@ad...> - 2002-02-28 09:00:56
|
# Quoting Chris boris Ross (ch...@da...): > You could have a shadowed 'selection' - so say in view A of /path I select > file 'a' and 'b', when in view B of /path i see a transparent selection of > 'a' and 'b' [looks like a ghost version of normal selection, so I know they > have been selected somewhere] Now _that_ I find really confusing :). > : Basically, think multiple frames in XEmacs. Everything is duplicated if > : you edit two views of a document side by side. > > The ability to lock view together like in konqueror would be cool :) lock views together? you mean in a closet and let them fight it out? Till |
From: Carsten H. (T. R. <ra...@ra...> - 2002-02-27 22:12:31
|
On Wed, 27 Feb 2002 22:27:42 +0100 Till Adam <ti...@ad...> babbled: > # Quoting Christian Kreibich (kre...@in...): > > > Simply dispatch the selects -- if you (de)select an icon in instance 1, > > it should become (de)selected in the remaining instances as well. > > Anything done to any view instance should be reflected in the other > > instances as well. > > Really think so? I tend to think the way I made it behave today is less > confusing. But your way is possible, of course. Other opinions on this? I don't agree. You should be able to select different icons in each view... isn't that the idea of multiple view instances? not just size an location...? -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9439 |
From: Christian K. <kre...@in...> - 2002-02-27 22:26:59
|
"Carsten Haitzler (The Rasterman)" wrote: > > On Wed, 27 Feb 2002 22:27:42 +0100 Till Adam <ti...@ad...> babbled: > > > # Quoting Christian Kreibich (kre...@in...): > > > > > Simply dispatch the selects -- if you (de)select an icon in instance 1, > > > it should become (de)selected in the remaining instances as well. > > > Anything done to any view instance should be reflected in the other > > > instances as well. > > > > Really think so? I tend to think the way I made it behave today is less > > confusing. But your way is possible, of course. Other opinions on this? > > I don't agree. You should be able to select different icons in each view... > isn't that the idea of multiple view instances? not just size an location...? Mhmm well first of all I think the issue is fairly unrealistic in general -- if I select a few files in order to copy (or move, or whatever) them around, I probably don't switch to other desktops where I have other view instances to select different files. But the issue needs to be addressed, no doubt. To make sure I understand your reasoning -- you want to define the currently selected set of files of a directory as the union of the selections of all view instances, right? Personally, I'd be more confused if I see a file selected in one view but not in others. Maybe others are confused by seeing the file be selected everywhere automatically. But after all, it doesn't really make sense to have them selected in one view but not in another, does it? We're not selecting icons (of which we have multiple), we're selecting *files*. And there is only one file, no matter in how many views it's displayed. YMMV :) Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Michael J. <e-...@ka...> - 2002-02-28 03:33:18
|
On Wednesday, 27 February 2002, at 23:24:40 (+0100), Christian Kreibich wrote: > Mhmm well first of all I think the issue is fairly unrealistic in > general -- if I select a few files in order to copy (or move, or > whatever) them around, I probably don't switch to other desktops > where I have other view instances to select different files. But the > issue needs to be addressed, no doubt. > > To make sure I understand your reasoning -- you want to define the > currently selected set of files of a directory as the union of the > selections of all view instances, right? Personally, I'd be more > confused if I see a file selected in one view but not in > others. Maybe others are confused by seeing the file be selected > everywhere automatically. > > But after all, it doesn't really make sense to have them selected in > one view but not in another, does it? We're not selecting icons (of > which we have multiple), we're selecting *files*. And there is only > one file, no matter in how many views it's displayed. Multiple views are useless if they are not independent of each other. Even Microsoft knows that one. Beware of confusing or too closely associating "views" with the objects they are viewing. Flexibility and power comes from *de*coupling objects from each other, not binding ourselves by arbitrary associations. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> n+1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "We both lie silently still in the dead of the night. Although we both lie close together, we feel miles apart inside. Was it something I said or something I did? Did my words not come out right?" -- Poison, "Every Rose Has Its Thorn" |
From: Chris T. <ch...@it...> - 2002-02-28 01:43:13
|
> I don't agree. You should be able to select different icons in each view... > isn't that the idea of multiple view instances? not just size an location...? I agree with raster on this one.. if i have two views open of one dir i would not want something to be selected in both. I can't think of any file manager that does it that way. Obviously if the file gets moved/deleted/whatever then the other views should take notice. -Chris |
From: Christian K. <kre...@in...> - 2002-03-06 10:19:24
|
Chris Thomas wrote: > > > I don't agree. You should be able to select different icons in each > view... > > isn't that the idea of multiple view instances? not just size an > location...? > > I agree with raster on this one.. if i have two views open of one dir i > would not want something to be selected in both. I can't think of any file > manager that does it that way. Obviously if the file gets > moved/deleted/whatever then the other views should take notice. This issue is really quite amazing. I was so sure about my way (dispatching the selection) that I wouldn't even have asked on the list if I would have been hacking on it. This is really a point that should be configurable, as there appear to be two camps here. And with me being in one and mej in the other, we'll never reach consensus anyway *grin* :) Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Till A. <ti...@ad...> - 2002-03-06 12:32:02
|
# Quoting Christian Kreibich (kre...@in...): > This issue is really quite amazing. I was so sure about my way > (dispatching the selection) that I wouldn't even have asked on the list > if I would have been hacking on it. This is really a point that should > be configurable, as there appear to be two camps here. And with me being > in one and mej in the other, we'll never reach consensus anyway *grin* > :) well, I promise to get to that, eventually. What is implemented now is the way all others do it. The cK trademark way of doing this will end up being added once the view stuff settles. By the way, I'd appreciate people given this selection/drag'n'drop thing a thorough beating, to see if we have forgotten any corner cases. Till |