From: Thomas L. <ta...@le...> - 2000-07-17 17:26:07
|
I've committed the last few day's work to CVS. This should have pinboard support fully working. Lots has changed, both user visible stuff and behind the scenes, so please check it all still works for you. If all goes well, expect the 0.1.25 release very soon. Changes ~~~~~~~ Changed the install script so that the CVS directories don't get installed! Pinboard selections work, as does clicking on the root window. Added the pinboard popup menu. Keys bound to menu entries are automatically saved when the filer quits. The 'rox' script now just calls AppRun directly. Panels can be created without starting a new copy of the filer. The pinboard can be changed or removed by using --pinboard a second time. Files can be given as arguments - they are opened as if they were clicked on in a filer window (suggested by Alex Holden). If no arguments are given then the default is now the current directory (not your home directory). If you start the leafname in the path minibuffer with '.' then the Show Hidden feature is temporarily turned on. Pinned icons are now updated when the pointer moves over them, if necessary. Drag and drop works properly for the pinboard. Updated the manual. Have fun. Report back ;-) Thomas Leonard -- ta...@us... The ROX desktop (free/GPL) : http://rox.sourceforge.net |
From: James K. <ja...@ke...> - 2000-07-18 13:23:32
|
Unfortunately the latest CVS version of ROX-Filer doesn't compile on my system (RH Linux 6.0). Here is the error message resulting from doing 'AppRun --compile': gcc -g -O2 -Wall `gtk-config --cflags` -I. -c i18n.c -o i18n.o i18n.c: In function `i18n_init': i18n.c:59: storage size of `info' isn't known i18n.c:64: warning: implicit declaration of function `stat' i18n.c:59: warning: unused variable `info' make: *** [i18n.o] Error 1 Compile failed Okay, thanks. -- James Kermode ja...@ke... http://www.kerm.freeserve.co.uk |
From: Thomas L. <ta...@le...> - 2000-07-18 17:12:39
|
On Tue, 18 Jul 2000, James Kermode wrote: > Unfortunately the latest CVS version of ROX-Filer doesn't > compile on my system (RH Linux 6.0). Here is the error > message resulting from doing 'AppRun --compile': > > gcc -g -O2 -Wall `gtk-config --cflags` -I. -c i18n.c -o i18n.o > i18n.c: In function `i18n_init': > i18n.c:59: storage size of `info' isn't known > i18n.c:64: warning: implicit declaration of function `stat' > i18n.c:59: warning: unused variable `info' > make: *** [i18n.o] Error 1 > Compile failed Right, thanks. Should be fixed now! The only other change to CVS is to prevent drags from pinboard icons onto the desktop background. If it works now, I'll make this the new release (finally!). BTW, would there be any interest in making CVS snapshots available by FTP? I could probably set up a little script to archive the latest CVS version each night for people without CVS access... Thomas Leonard -- ta...@us... The ROX desktop (free/GPL) : http://rox.sourceforge.net |
From: James K. <ja...@ke...> - 2000-07-18 21:37:30
|
On Tue, 18 Jul 2000, Thomas Leonard wrote: > Right, thanks. Should be fixed now! Yes, thanks - it works fine now. I have been very impressed with rox so far, and I like all the new features, especially the pinboard support. However, I have a couple of suggestions. Firstly, I think it would look nicer if the text for the pinboard icons was transparent (like with KDE's file manager, for example). I realise this may be hard to implement, and it's not really all that important, though. Secondly, whenever I open a Filer window I seem to end up resizing it. I found the section in filer.c, in filer_opendir() (line 1015 in the current CVS version) which sets up the initial window height, and changed it from 3 rows of icons to 5, which worked. However, a better solution would take account of the number of files in the directory and size the window accordingly (up to some maximum height). I wasn't able to get this to work however; is the number_of_items attribute of the collection structure available when the window is being sized? What does anyone else think of these ideas? -- James Kermode ja...@ke... http://www.kerm.freeserve.co.uk |
From: Vincent L. <vi...@vi...> - 2000-07-18 22:43:24
|
On Tue, Jul 18, 2000 at 22:18:02 +0100, James Kermode wrote: > Firstly, I think it would look nicer if the text for > the pinboard icons was transparent (like with KDE's file > manager, for example). I realise this may be hard to > implement, and it's not really all that important, though. What do you mean? (I don't know KDE.) > Secondly, whenever I open a Filer window I seem to end up > resizing it. I found the section in filer.c, in > filer_opendir() (line 1015 in the current CVS version) which > sets up the initial window height, and changed it from 3 > rows of icons to 5, which worked. However, a better > solution would take account of the number of files in the > directory and size the window accordingly (up to some > maximum height). I wasn't able to get this to work however; This would be a good idea. And how about transparent icons when dragging, like under RISC OS? -- Vincent Lefèvre <vi...@vi...> - Web: <http://www.vinc17.org/> - 100% validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Computer science / computer arithmetic / Arénaire project at LIP, ENS-Lyon |
From: Garrett C <ga...@cs...> - 2000-07-19 07:16:35
|
On Wed, 19 Jul 2000, Vincent Lefevre wrote: > On Tue, Jul 18, 2000 at 22:18:02 +0100, James Kermode wrote: > > Firstly, I think it would look nicer if the text for > > the pinboard icons was transparent (like with KDE's file > > manager, for example). I realise this may be hard to > > implement, and it's not really all that important, though. > > What do you mean? (I don't know KDE.) The text sits directly on the background, rathwer than in a surrounding box on the background. Thus text looks like it is part of the background more - its a lot more aesthetically pleasing. However, it CAN be hard to read. If this were implemented, a drop shadow or surround-shadow might solve that problem. I saw eterm using that with its transparent option, and it looks cool and increases readability no end. > > > Secondly, whenever I open a Filer window I seem to end up > > resizing it. I found the section in filer.c, in > > filer_opendir() (line 1015 in the current CVS version) which > > sets up the initial window height, and changed it from 3 > > rows of icons to 5, which worked. However, a better > > solution would take account of the number of files in the > > directory and size the window accordingly (up to some > > maximum height). I wasn't able to get this to work however; > > This would be a good idea. > Yes, I like this one. I have that problem too. > And how about transparent icons when dragging, like under RISC OS? > Yes. And an option to change the level of translucency wold be good too. Cheers, Chris. |
From: Vincent L. <vi...@vi...> - 2000-07-19 11:25:21
|
On Wed, Jul 19, 2000 at 08:16:07 +0100, Garrett C wrote: > The text sits directly on the background, rathwer than in a surrounding > box on the background. OK. I used to have this under RISC OS, but I have random backdrops, and when the backdrop has bright colours, the text isn't readable. :( If the (foreground) colour of the text can automatically be changed depending on the background colours, it would really be good. Or it should have a shadow, as you said. -- Vincent Lefèvre <vi...@vi...> - Web: <http://www.vinc17.org/> - 100% validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Computer science / computer arithmetic / Arénaire project at LIP, ENS-Lyon |
From: Garrett C <ga...@cs...> - 2000-07-19 11:55:19
|
On Wed, 19 Jul 2000, Vincent Lefevre wrote: > On Wed, Jul 19, 2000 at 08:16:07 +0100, Garrett C wrote: > > The text sits directly on the background, rathwer than in a surrounding > > box on the background. > > OK. I used to have this under RISC OS, but I have random backdrops, > and when the backdrop has bright colours, the text isn't readable. :( > If the (foreground) colour of the text can automatically be changed > depending on the background colours, it would really be good. Or it > should have a shadow, as you said. Text colour would be good, but for really messy backgrounds it doesn't work too well. A thin black outline around the text is my favoured method for clarity. Incidentally, I mentioned earlier about organizing icons on the pinboard ala RO4. Some of you weren't sure what this entailed. Although I haven't seen it in action myself, I seem to remember reading in Acorn User that it could organise icons on the screen according to their type. For example, you could have apps automatically iconise to the left hand side, and files to the right. You could also add alignment along the designated edge (top/ middle/ bottom or left/ center/ right). Presumably this could be made as complex or as simple as you wished through the use of MIME types? Chris. |
From: Thomas L. <ta...@le...> - 2000-07-20 21:10:54
|
On Wed, 19 Jul 2000, Garrett C wrote: > > And how about transparent icons when dragging, like under RISC OS? > > Yes. And an option to change the level of translucency wold be good too. OK, before people get too excited about transparency, I'd like to point out that... it's impossible :-( aterm and friends work by getting the root window pattern and using that for their own background. Or, sometimes, by taking a screenshot and using that. Neither work if things change underneath the transparent window... And, since the point of transparent icon drags is to allow you to see what's going on under the icon (eg, exactly where some text will get inserted), that's not much use. The best approximation we can do is to use a stipple pattern over the mask to get a poor sort of 50% transparency (like NewerLook does). This could work, but it won't look so good. Make it an option? Thomas Leonard -- ta...@us... The ROX desktop (free/GPL) : http://rox.sourceforge.net |
From: Garrett C <ga...@cs...> - 2000-07-21 08:12:14
|
On Thu, 20 Jul 2000, Thomas Leonard wrote: > On Wed, 19 Jul 2000, Garrett C wrote: > > > > And how about transparent icons when dragging, like under RISC OS? > > > > Yes. And an option to change the level of translucency wold be good too. > > OK, before people get too excited about transparency, I'd like to point > out that... it's impossible :-( > > aterm and friends work by getting the root window pattern and using that > for their own background. Or, sometimes, by taking a screenshot and using > that. Neither work if things change underneath the transparent window... > > And, since the point of transparent icon drags is to allow you to see > what's going on under the icon (eg, exactly where some text will get > inserted), that's not much use. > But what sort of things are likely to change when you're dragging an icon? You can't move other stuff around, and you're unlikely to want to drop it onto a terminal that is displaying rolling output from a program. You are usually going to be dropping the icon on a static object - a filer, or pinboard for example. The problem with the transparent eterms is due to things being able to be moved around or updated whilst they are still there. Sure, you may need to drag the icon over an animation or something, but most of the time it would look fine. > The best approximation we can do is to use a stipple pattern over the mask > to get a poor sort of 50% transparency (like NewerLook does). This could > work, but it won't look so good. Make it an option? > That does sound like a good idea, actually. And it would look pretty good on my screen res (1600x1280). If you do this, could you add an option for the stipples to be static, or alternating - or try both to see which would look better? Cheers, Chris. |
From: Ewan M. M. <ec...@yo...> - 2000-07-21 12:08:18
|
On Fri, 21 Jul 2000, Garrett C wrote: > On Thu, 20 Jul 2000, Thomas Leonard wrote: > > On Wed, 19 Jul 2000, Garrett C wrote: > > > > > > And how about transparent icons when dragging, like under RISC OS? > But what sort of things are likely to change when you're dragging an > icon? You can't move other stuff around, and you're unlikely to want to > drop it onto a terminal that is displaying rolling output from a > program. You are usually going to be dropping the icon on a static object > - a filer, or pinboard for example. The problem with the transparent > eterms is due to things being able to be moved around or updated whilst > they are still there. Sure, you may need to drag the icon over an > animation or something, but most of the time it would look fine. I think you might be underestimating the amount of animated stuff that can be around; scrolling terminals, clocks, volume meters, progress bars... There's a lot that could change underneath an icon as you drag it about; it isn't just the target area that matters but the path you take too. That and I tend to find that things that are fine most of the time are really annoying on the occasions that they don't work. If you were going to use this approach when would you do the screen grab? If you do it at the beginning of the drag and don't update it then it would easily get out of date; if you keep doing it it would be a huge processing overhead. > > The best approximation we can do is to use a stipple pattern over the mask > > to get a poor sort of 50% transparency (like NewerLook does). This could > > work, but it won't look so good. Make it an option? > That does sound like a good idea, actually. And it would look pretty good > on my screen res (1600x1280). That kind of thing can give wierd aliasing effects on some icons, but it can't hurt as an option. Alternativly I seem to remember a little program on the acorn that flashed dragged icons on and off very rapidly - ie 100% transparent, then 0% transparent -> average of 50%. If you've got a refresh rate to match that resolution it would work for you at least :-) BTW, with regard to CVS snapshots - yes please; my PC doesn't have an internet connection and the university computers don't have CVS. Ewan |
From: Garrett C <ga...@cs...> - 2000-07-21 11:22:55
|
<snip> > I think you might be underestimating the amount of animated stuff that can > be around; scrolling terminals, clocks, volume meters, progress bars... > There's a lot that could change underneath an icon as you drag it about; > it isn't just the target area that matters but the path you take too. That > and I tend to find that things that are fine most of the time are really > annoying on the occasions that they don't work. > If you were going to use this approach when would you do the screen grab? > If you do it at the beginning of the drag and don't update it then it > would easily get out of date; if you keep doing it it would be a huge > processing overhead. > Yes, I see what you mean. It wouldn't really be practical. How about the option to drag icons as an outline? Obviously not as pretty as translucency, and with the disadvantage that you can't see the picture on the icon being dragged, but it would allow you to see what is under the icon better... > > > The best approximation we can do is to use a stipple pattern over the mask > > > to get a poor sort of 50% transparency (like NewerLook does). This could > > > work, but it won't look so good. Make it an option? > > That does sound like a good idea, actually. And it would look pretty good > > on my screen res (1600x1280). > > That kind of thing can give wierd aliasing effects on some icons, but it > can't hurt as an option. Alternativly I seem to remember a little program > on the acorn that flashed dragged icons on and off very rapidly - ie 100% > transparent, then 0% transparent -> average of 50%. If you've got a > refresh rate to match that resolution it would work for you at least :-) I think I remember that program. Using it on the old A3000 hurt the eyes, but it worked well on the RiscPC (about 70Hz refresh, I think). Chris. |
From: Thomas L. <ta...@le...> - 2000-07-26 18:26:04
|
On Wed, 19 Jul 2000, Garrett C wrote: > Incidentally, I mentioned earlier about organizing icons on the pinboard > ala RO4. Some of you weren`t sure what this entailed. Although I haven`t > seen it in action myself, I seem to remember reading in Acorn User that it > could organise icons on the screen according to their type. For example, > you could have apps automatically iconise to the left hand side, and files > to the right. I think this must refer to iconising windows rather than files - therefore, this is under the control of the window manager, not the filer. Maybe iconised directories went one way and apps the other? I'm sure there must be a WM out there somewhere that can handle this ;-) Thomas Leonard -- ta...@us... The ROX desktop (free/GPL) : http://rox.sourceforge.net |