From: Thomas L. <ta...@ec...> - 2001-03-14 14:49:37
|
On Sun, Mar 11, 2001 at 12:44:05PM -0500, Diego Zamboni wrote: > > ta...@ec... said: > > > 3. Shift-select? (select from the last selected up to the clicked > > > filename) > > But Shift-click already does something else... > > It can be useful functionality. Maybe binding it to Ctrl-Shift-click? > > On the other hand, it seems that the more-or-less-standard functionality is > Ctrl-click to select/unselect individual items (as it is now) and Shift-click > to range-select (from the last selected item to the current one). How about > adhering to this expected functionality, and move the reveal-link (which is > what shift-click does now) to something else, like Ctrl-Shift-click? It's more than reveal link, though. It's also edit-as-text which is a *very* common operation... (well, for me anyway!). > I don't really like the idea of changing things like that all of a sudden, but > maybe for the sake of standardizing the interface...? Then all the RISC OS users will be upset... What about if dragging a lasso box with Shift held down selects in sort order (like dragging a selection in a text editor) instead of with a rectangular selection? -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Diego Z. <za...@ce...> - 2001-03-14 15:14:26
|
ta...@ec... said: > It's also edit-as-text which is a *very* common operation... (well, > for me anyway!). Ha! I had _never_ realized that! That's quite useful to know, as I also use "Edit as text" quite often :-) > Then all the RISC OS users will be upset... Yes. I imagined that's why some things are not quite X-ish, because that's how they are in RISC OS. > What about if dragging a lasso box with Shift held down selects in > sort order (like dragging a selection in a text editor) instead of > with a rectangular selection? That would be very nice. And while we are in selection-related matters, I have a suggestion: how about making "show target" not only show the directory where the target of a link is, but also select it? That would be quite useful. Also, it would be nice if "New file" would select the new file after creating it. In both cases, it would make it easier to locate the corresponding file. Thanks, --Diego |
From: Thomas L. <ta...@ec...> - 2001-03-15 16:13:27
|
On Wed, Mar 14, 2001 at 10:16:26AM -0500, Diego Zamboni wrote: > > What about if dragging a lasso box with Shift held down selects in > > sort order (like dragging a selection in a text editor) instead of > > with a rectangular selection? > > That would be very nice. > > And while we are in selection-related matters, I have a suggestion: how about > making "show target" not only show the directory where the target of a link > is, but also select it? That would be quite useful. Also, it would be nice if > "New file" would select the new file after creating it. In both cases, it > would make it easier to locate the corresponding file. Follow link does wink the file, but perhaps it needs a longer timeout? New file should do the same (but doesn't yet). Maybe the file should flash a couple of times, instead of just once? -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Diego Z. <za...@ce...> - 2001-03-17 16:50:58
|
ta...@ec... said: > I've applied this patch now. Could people try it out with various > window managers - if there are problems then we can make it an > option... I would vote for making both of them options. Adding options is cheap now anyway :-) I personally don't like the continuous flashing of the window, particularly when it is a large directory mounted over NFS, for example, which may take a while to scan. I'd much rather wait until it finishes and then press "r" (which I have bound to auto-resize). Also, it seems that it's not working right all the time. When I first open my home directory (which is NFS-mounted), the end window is far larger than necessary. Doing a "auto resize" manually goes to the correct size, so I guess it's not using the same algorithm at some point, maybe? I haven't looked at that part of the code, so I'll just ask: is there a way to know when the directory has finished scanning, so that in any case a single resize can be done at that point, instead of doing several during the process? The other change (auto-resize on directory changes) also throws me off-balance. I personally don't like windows resizing without my approval. And resizing the window is not necessarily what I want when I'm traversing down a path. Note that I do like the auto-resizing when changing views, and I think it's very useful. It's just the auto-resizing when changing directories and the multiple auto-resizes when opening a new window that I'm not too thrilled about. --Diego |
From: Denis M. <de...@li...> - 2001-03-18 01:53:30
|
on 2001.03.17 17:53:06 +0100 Diego Zamboni wrote : > ta...@ec... said: > > I've applied this patch now. Could people try it out with various > > window managers - if there are problems then we can make it an > > option... > > I would vote for making both of them options. Adding options is cheap now > > anyway :-) > > I personally don't like the continuous flashing of the window, > particularly > when it is a large directory mounted over NFS, for example, which may > take a > while to scan. I'd much rather wait until it finishes and then press "r" > (which I have bound to auto-resize). I know the problem. Actually there are two hard-coded timeouts (the first for open_window and the second for the resize_window), increasing them can dramatically improve usability. > > Also, it seems that it's not working right all the time. When I first > open my > home directory (which is NFS-mounted), the end window is far larger than > necessary. Doing a "auto resize" manually goes to the correct size, so I > guess > it's not using the same algorithm at some point, maybe? > > I haven't looked at that part of the code, so I'll just ask: is there a > way to > know when the directory has finished scanning, so that in any case a > single > resize can be done at that point, instead of doing several during the > process? It's easy to know when the scanning terminate but in this way for very long scans may happen that the window opens with a minimum size and the items appear inside it all along the scan. then after a few seconds (the end of scanning process) and after we have begun to use it, the window resize unexpectedly. > The other change (auto-resize on directory changes) also throws me > off-balance. I personally don't like windows resizing without my > approval. And > resizing the window is not necessarily what I want when I'm traversing > down a > path. This is what I'd like to have :-) The problem is essentially this : After what operation do you use the resize key, or you use it seldomly, can we automate it ? > Note that I do like the auto-resizing when changing views, and I think > it's > very useful. It's just the auto-resizing when changing directories and > the > multiple auto-resizes when opening a new window that I'm not too thrilled > > about. Are you talking about keyboard navigation, mouse navigation or both ? |
From: Diego Z. <za...@ce...> - 2001-03-18 19:10:30
|
> Although, I'm still not sure if anyone is actually using ROX-Session :-/ I'm using it, and it works quite well. I like the way messages are handled, and I actually use it for display of status messages when certain things change. For example, I have a program (auctl) for controlling audio settings in my Sparc Station, and that program is bound to some keys in my keyboard. I run auctl with the "verbose" flag, so that when I press one of the corresponding keys, I get a short message telling me what it's doing. It's great for getting feedback. The only thing I haven't been able to explain is that sometimes the messages appear at the top of the screen, and sometimes at the bottom. Any ideas as to why this happens? I have changed the "LogoutCommand" setting in icewm to run "rox-session", so that it's now nicely integrated with my window manager. I haven't used the login auto-run-programs feature, mostly because I like to have precise control over what and when is run. But other than that it seems to work beautifully. Cheers, --Diego |
From: Thomas L. <ta...@ec...> - 2001-03-19 12:03:14
|
On Sun, Mar 18, 2001 at 02:12:43PM -0500, Diego Zamboni wrote: > > Although, I'm still not sure if anyone is actually using ROX-Session :-/ > > I'm using it, and it works quite well. I like the way messages are > handled, and I actually use it for display of status messages when > certain things change. For example, I have a program (auctl) for controlling > audio settings in my Sparc Station, and that program is bound to some > keys in my keyboard. I run auctl with the "verbose" flag, so that when > I press one of the corresponding keys, I get a short message telling > me what it's doing. It's great for getting feedback. That's nice :-) > The only thing I haven't been able to explain is that sometimes the > messages appear at the top of the screen, and sometimes at the bottom. > Any ideas as to why this happens? It appears wherever the pointer isn't... -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Diego Z. <za...@ce...> - 2001-03-21 15:00:51
|
> OK, I've changed it so that changing directory only ever makes the window > larger - this seems to work much better :-) Thanks. Still, I believe that any form of automatic size-changing on the windows should be an option. Particularly that repeated-resizing thing on new windows, which is still causing my heard to hurt every time I open a large remotely-mounted directory :-) Cheers, --Diego |
From: Thomas L. <ta...@ec...> - 2001-03-26 11:05:47
|
On Wed, Mar 21, 2001 at 10:00:45AM -0500, Diego Zamboni wrote: > > OK, I've changed it so that changing directory only ever makes the window > > larger - this seems to work much better :-) > > Thanks. Still, I believe that any form of automatic size-changing on > the windows should be an option. Particularly that repeated-resizing > thing on new windows, which is still causing my heard to hurt every > time I open a large remotely-mounted directory :-) Ah... think I may have found the problem here! When resizing during scanning we add the number of 'pending' items to the currently included items to get the initial guess for the size. But, unless Show Hidden is on, we're not actually going to add all of them! Anyway, it should be fixed now :-) -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Diego Z. <za...@ce...> - 2001-03-22 18:19:36
|
> I tried this out with your applet code last PM and it works. There > are Huh? Did I miss something? What applet code? Where? How? (doing a cvs upd right now, in case there's something there...) --Diego |
From: Diego Z. <za...@ce...> - 2001-03-23 16:03:11
|
ta...@ec... said: > If no-one has any problems with this version, I'll make a new release > in a couple of days... It's been working very nicely for me, and yesterday it saved me from a full session restart when my window manager crashed - I just reselected it from the list and was back in business... :-) --Diego |
From: Diego Z. <za...@ce...> - 2001-03-26 14:14:28
|
ta...@ec... said: > Anyway, it should be fixed now :-) Ahhhhhh, much better! I think I can actually live with it now :-) Thanks a lot, --Diego |
From: Diego Z. <za...@ce...> - 2001-03-26 14:49:26
|
ta...@ec... said: > Anyway, I've just rewritten the parsing code (quite a lot neater now!) > - does this fix/break it for anybody? Works OK for me. --Diego |
From: Diego Z. <za...@ce...> - 2001-03-27 13:27:36
|
ta...@ec... said: > Hopefully it's all fixed now, although older versions of libxml may > have stopped working? Surprisingly it didn't... almost. I had to remove the #include <xmlversion.h> and the call to XML_TEST_VERSION in main.c, and without that it compiles and runs nicely. Apparently libxml2 is backward-compatible with older versions, so there's probably no reason to test the version for now (and xmlversion.h does not exist in the old libxml). It took me a while to get my sysadmin to install libxml, I don't really want to go through the process again right now... --Diego |
From: Diego Z. <za...@ce...> - 2001-04-01 17:06:56
|
ta...@ec... said: > Appled. Couple of changes: Fantastic, works great. Thanks a lot, Denis and Thomas! --Diego |
From: Diego Z. <za...@ce...> - 2001-04-02 21:57:41
|
ta...@ec... said: > There's a new Display style - Huge Icons - that shows thumbnails nice > and large. Finally! This is very nice, and in fact made integrating my icon-scaling patch much easier, with the addition of the scale_pixbuf() function. I'm thinking about how to handle the interaction between the icon-size setting, the thumbnails, and my icon-sizing patch. Here are my current thoughts: I like the "huge icons" setting a lot - but only for thumbnails. In regular directories, it can create huge spacings between items, particularly when they have long filenames (because the filer allocates more "room to grow"). So how about having two different size settings: one for icons, and one for thumbnails? They could be exact mirrors in terms of the options available: small, large, huge and (with my patch) a slider for controlling the size. Or maybe just have the slider for regular icons, and let the thumbnails obey only the fixed options. What do you think? I'm still a little confused about it myself, I think I'll develop clearer ideas when I actually sit down and look at the code in detail. Cheers, --Diego |
From: Thomas L. <ta...@ec...> - 2001-04-04 11:21:06
|
On Mon, Apr 02, 2001 at 04:57:38PM -0500, Diego Zamboni wrote: > > ta...@ec... said: > > There's a new Display style - Huge Icons - that shows thumbnails nice > > and large. Finally! > > This is very nice, and in fact made integrating my icon-scaling patch > much easier, with the addition of the scale_pixbuf() function. > > I'm thinking about how to handle the interaction between the icon-size > setting, the thumbnails, and my icon-sizing patch. Here are my current > thoughts: > > I like the "huge icons" setting a lot - but only for thumbnails. In > regular directories, it can create huge spacings between items, > particularly when they have long filenames (because the filer allocates > more "room to grow"). The filer does reserve a small amount of extra space (mainly so you can see you're in Huge Icons mode ;-), but it shouldn't be too much. There were a few CVS updates over Sunday, so make sure you have the latest... It takes the truncation length for leafnames as twice the setting for normal icons, too. > So how about having two different size settings: > one for icons, and one for thumbnails? They could be exact mirrors in > terms of the options available: small, large, huge and (with my patch) a > slider for controlling the size. Or maybe just have the slider for > regular icons, and let the thumbnails obey only the fixed options. Not quite sure how that would work :-/ As for the slider, it would be most useful for normal icons. Huge Icons are large enough that a couple of pixels wouldn't matter (also, they takes ages to reload and rescale, whereas the other sizes are scaled from the huge icons). > What do you think? I'm still a little confused about it myself, I think > I'll develop clearer ideas when I actually sit down and look at the code > in detail. ;-) -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Diego Z. <za...@ce...> - 2001-04-11 18:09:17
|
ta...@ec... said: > Could it be a problem with nautilus? Or maybe the way D&D is configured? Particularly the "Don't use hostnames" option seems to cause problems (one way or the other) with some programs. --Diego |
From: Diego Z. <za...@ce...> - 2001-04-18 18:29:46
|
> I've made the automatic window resizing optional - although normally > useful, there were some cases where it was just too annoying ;-) You know what would be really useful? To have a toggle for this option in the filer menu. Then you could bind a key to it and toggle it on and off easily, which I anticipate might be very useful depending on where in the filesystem you are navigating... Thanks, --Diego (who has been job-interviewing and generally swamped with work lately, therefore hasn't been doing much rox-related) |
From: Diego Z. <za...@ce...> - 2001-04-30 14:31:52
|
ta...@ec... said: > [ Right-clicking an app loses the selection ] Could a case be made that in the special case of right-clicking on an icon, the selection should not be cleared? It might make many AppMenu tasks easier to perform (for example, select a URL, right-click on an App, select "add selection to URLs folder", without having to program menus and such by yourself). This would only happen when no other icons are selected, so I don't think it would break many other things. Thomas, any comments? Thanks, --Diego |
From: Thomas L. <ta...@ec...> - 2001-05-02 12:01:28
|
On Mon, Apr 30, 2001 at 09:31:47AM -0500, Diego Zamboni wrote: > > ta...@ec... said: > > [ Right-clicking an app loses the selection ] > > Could a case be made that in the special case of right-clicking on an icon, > the selection should not be cleared? It might make many AppMenu tasks easier > to perform (for example, select a URL, right-click on an App, select "add > selection to URLs folder", without having to program menus and such by > yourself). This would only happen when no other icons are selected, so I > don't think it would break many other things. What happens if I select two files in a directory, and then right-click on an application in the same directory? Is the menu that appears for the selected files (delete them, etc) or is it the application's appmenu? It's possible, but it could be a bit weird ;-) -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Diego Z. <za...@ce...> - 2001-05-02 12:49:52
|
ta...@ec... said: > What happens if I select two files in a directory, and then > right-click on an application in the same directory? > Is the menu that appears for the selected files (delete them, etc) or > is it the application's appmenu? I think "external behavior" should remain the same: if you already have some files selected, you get the corresponding multi-file menu. The difference is just if you don't have any files selected: in that case the clipboard does _not_ get cleared and set to the application you are right-clicking on, so that the program can access it. --Diego |
From: Thomas L. <ta...@ec...> - 2001-05-13 14:49:49
|
On Wed, May 02, 2001 at 07:49:47AM -0500, Diego Zamboni wrote: > > ta...@ec... said: > > What happens if I select two files in a directory, and then > > right-click on an application in the same directory? > > Is the menu that appears for the selected files (delete them, etc) or > > is it the application's appmenu? > > I think "external behavior" should remain the same: if you already have some > files selected, you get the corresponding multi-file menu. The difference is > just if you don't have any files selected: in that case the clipboard does > _not_ get cleared and set to the application you are right-clicking on, so > that the program can access it. As a first step towards this, I've merged all the code common to pinboard and panel handling of menus and selections into icon.c (at last!). Some things might have broken (test it!)... I'll wait a while to check it's OK before making any more changes... Unrelated change: The configure script now looks for 'xml2-config' as well as 'xml-config', so we should work with just about every version out there now! -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Thomas L. <ta...@ec...> - 2001-05-15 14:02:16
|
On Wed, May 02, 2001 at 07:49:47AM -0500, Diego Zamboni wrote: > > ta...@ec... said: > > What happens if I select two files in a directory, and then > > right-click on an application in the same directory? > > Is the menu that appears for the selected files (delete them, etc) or > > is it the application's appmenu? > > I think "external behavior" should remain the same: if you already have some > files selected, you get the corresponding multi-file menu. The difference is > just if you don't have any files selected: in that case the clipboard does > _not_ get cleared and set to the application you are right-clicking on, so > that the program can access it. OK, this is now implemented for pinboard and panel menus: - Menu-clicking an item doesn't select it. - 'Edit Icon', 'Show Location' and 'Show Help' act on the icon clicked, ignoring the selection. - 'Remove Item(s)' removes the icon clicked (if any), plus any selection on the same pinboard or panel. I think that should do what you want most of the time! -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Diego Z. <za...@ce...> - 2001-06-01 14:07:48
|
ta...@ec... said: > Seems to have gone a bit quiet in here! RL has me all busy lately. I have my Ph.D. defense on July 13, so work work work is all there is to me right now, finishing my dissertation. I'm still reading the lists, but I haven't even done a "cvs update" in weeks (*gasp*). I promise I'll go back to semi-normal after that day... :-) --Diego |