Menu
▾
▴
rox-devel
|
From: Thomas L. <ta...@ec...> - 2000-06-24 13:02:08
|
On Fri, 19 Nov 1999, Darren Winsper wrote: [ desired features ] > OK: > The ability to place icons on the root (X's background, similar to KFM > and GMC). ..and.. On Thu, 1 Jun 2000, P.S.S.Camp wrote: > I see that ROX Filer is progressing, Is there any chance of ROX filer > Having the pinboard type icons that gmc offers? as one day I would like > to roll with ROX rather than gmc, as it is much nicer to use. OK, it looks like I'm going to have to add this ;-) But there are various choices to make... 1. Do we want it RISC OS style (ie, just links) or everyone-else style (ie, the background acts like another directory)? Since even the iconbar is a directory, the second option seems logical... 2. If it is a directory, where is it stored? Should it be user-settable (like the panel location) rather than hard-wired? If it isn't a directory, should it go in a separate program? 3. The menu will have to be slightly different (some display styles don't make much sense). I imaging the clicking behaviour should follow the filer windows' style rather than the panel because you can make selections on the pinboard. 4. How are icons arranged? (sort type, grid, free, etc?) 5. Should we add it now, or do a stable release first? Pinboard support will probably take a while to add... Thomas Leonard -- ta...@ec... 3rd year computer science The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: Vincent L. <vi...@vi...> - 2000-06-24 14:37:13
|
On Sat, Jun 24, 2000 at 13:58:04 +0100, Thomas Leonard wrote: > 1. Do we want it RISC OS style (ie, just links) or everyone-else style > (ie, the background acts like another directory)? Since even the > iconbar is a directory, the second option seems logical... I prefer a directory with links. Well, removing an icon must not remove the file! > 2. If it is a directory, where is it stored? Should it be user-settable > (like the panel location) rather than hard-wired? Yes, of course. > If it isn't a directory, should it go in a separate program? I don't understand. > 3. The menu will have to be slightly different (some display styles > don't make much sense). I imaging the clicking behaviour should follow > the filer windows' style rather than the panel because you can make > selections on the pinboard. Yes. > 4. How are icons arranged? (sort type, grid, free, etc?) User configurable. > 5. Should we add it now, or do a stable release first? Pinboard support > will probably take a while to add... I don't know... -- 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: <da...@da...> - 2000-06-25 09:09:10
|
ReSent-From: Vincent Lefevre <vi...@vi...> ReSent-To: rox...@li... On Sat, Jun 24, 2000 at 04:32:56PM +0200, Vincent Lefevre wrote: > On Sat, Jun 24, 2000 at 13:58:04 +0100, Thomas Leonard wrote: > > 1. Do we want it RISC OS style (ie, just links) or everyone-else style > > (ie, the background acts like another directory)? Since even the > > iconbar is a directory, the second option seems logical... > > I prefer a directory with links. Well, removing an icon must not remove > the file! I agree with Vincent, but then again I have always prefered the pinboard's behaviour over the likes of GMC and KFM. > > If it isn't a directory, should it go in a separate program? > > I don't understand. If the pinboard isn't just a directory like everything else, then perhaps some form of launcher program rather than adding the functionality to the filer. I myself like this idea, since at the rate things are going, ROX-filer could end up as a monolithic mess. It already does normal filing and act as the icon bar, which I think should be separate programs, perhaps with a libROX for the functions both programs use. > > 5. Should we add it now, or do a stable release first? Pinboard support > > will probably take a while to add... > > I don't know... To be honest, I'd like to see it added now. However, if we do go with the "pinboard as a separate launcher program" then it won't really matter, since the filer won't be affected by the pinboard's development. -- Darren Winsper (El Capitano) - ICQ #8899775 Stellar Legacy project member - http://www.stellarlegacy.tsx.org DVD boycotts. Are you doing your bit? This message was typed before a live studio audience. |
|
From: Vincent L. <vi...@vi...> - 2000-06-25 10:56:16
|
On 24 Jun, <da...@da...> wrote: > If the pinboard isn't just a directory like everything else, then > perhaps some form of launcher program rather than adding the > functionality to the filer. Yes. Under RISC OS, I don't have anything installed on the pinboard (just iconized windows), and I use IconThang instead. -- 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: Thomas L. <ta...@ec...> - 2000-06-28 14:45:58
|
On Sat, 24 Jun 2000 da...@da... wrote: > On Sat, Jun 24, 2000 at 04:32:56PM +0200, Vincent Lefevre wrote: > > On Sat, Jun 24, 2000 at 13:58:04 +0100, Thomas Leonard wrote: > > > 1. Do we want it RISC OS style (ie, just links) or everyone-else style > > > (ie, the background acts like another directory)? Since even the > > > iconbar is a directory, the second option seems logical... > > > > I prefer a directory with links. Well, removing an icon must not remove > > the file! > > I agree with Vincent, but then again I have always prefered the > pinboard's behaviour over the likes of GMC and KFM. Well, if no-one has any complaints... this makes things easier :-) Of course, it might make sense for the iconbar to be an extension of the pinboard rather than an extension of the filer... > If the pinboard isn't just a directory like everything else, then > perhaps some form of launcher program rather than adding the > functionality to the filer. I myself like this idea, since at the rate > things are going, ROX-filer could end up as a monolithic mess. It > already does normal filing and act as the icon bar, which I think > should be separate programs, perhaps with a libROX for the functions > both programs use. There are still arguments for putting it all in one program though. For example, dragging files on to a directory should do a copy; dragging to an app should run the application, etc. I think we're OK on the bloat front for a bit (gmc is 5x the size of ROX-Filer!). The other argument for keeping it all together is that clicking on a directory on the backdrop can simply open a new window, rather than having to run a new copy of the filer (in fact, this is why the iconbar was made part of the filer). Thomas Leonard -- ta...@ec... 3rd year computer science The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: Ewan M. M. <ec...@yo...> - 2000-06-28 20:38:03
|
On Wed, 28 Jun 2000, Thomas Leonard wrote: > I think we're OK on the bloat front for a bit (gmc is 5x the size of > ROX-Filer!). The other argument for keeping it all together is that > clicking on a directory on the backdrop can simply open a new window, > rather than having to run a new copy of the filer (in fact, this is why > the iconbar was made part of the filer). Surely that's not a problem since re-invoking the filer now causes the old instance to open a new window rather than load another instance? While ROX-Filer is a fifth the size of gmc I'd quite like it to stay that way; my computer isn't very fast so I'm very keen on programs that are. Ewan |
|
From: Thomas L. <ta...@ec...> - 2000-06-30 14:41:54
|
On Wed, 28 Jun 2000, Ewan Mac Mahon wrote: > On Wed, 28 Jun 2000, Thomas Leonard wrote: > > I think we're OK on the bloat front for a bit (gmc is 5x the size of > > ROX-Filer!). The other argument for keeping it all together is that > > clicking on a directory on the backdrop can simply open a new window, > > rather than having to run a new copy of the filer (in fact, this is why > > the iconbar was made part of the filer). > > Surely that's not a problem since re-invoking the filer now causes the old > instance to open a new window rather than load another instance? Yep, although that needs to be made more efficient. Now that the 'rox' script is distributed with the filer I may just make it load the filer directly (as someone suggested as while back). We might also use a named pipe for communication rather than opening an X connection and communicating via the server... Although the idea of putting common functionality into a library solves (partly) the code size problem, it doesn't help to keep the two programs in sync. Eg, if I drag a file into a directory on the pinboard I'd want the filer to update itself straight away. We can't catch all cases of file systems changing, but this one is pretty common! My plan is to store the pinboard config somewhere in Choices. Possibly there will be a system for allowing various named configurations, eg `ROX-Filer/AppRun --pinboard MyPinboard'. Whatever happens, it's likely that the iconbar will use the same system. I was a bit worried that users used to GNOME / Windows might copy something to the pinboard and then delete the original, but I think I've found a neat solution: warn the user before deleting if the file is on the pinboard... Thomas Leonard -- ta...@ec... 3rd year computer science The ROX desktop (free/GPL) : http://rox.sourceforge.net |
Thanks for helping keep SourceForge clean.
X