Menu
▾
▴
rox-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(11) |
Jul
(47) |
Aug
(42) |
Sep
(54) |
Oct
(29) |
Nov
(50) |
Dec
(101) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(126) |
Feb
(62) |
Mar
(96) |
Apr
(67) |
May
(54) |
Jun
(61) |
Jul
(159) |
Aug
(115) |
Sep
(132) |
Oct
(65) |
Nov
(143) |
Dec
(108) |
| 2002 |
Jan
(148) |
Feb
(122) |
Mar
(95) |
Apr
(114) |
May
(141) |
Jun
(49) |
Jul
(74) |
Aug
(50) |
Sep
(30) |
Oct
(121) |
Nov
(88) |
Dec
(98) |
| 2003 |
Jan
(81) |
Feb
(111) |
Mar
(120) |
Apr
(111) |
May
(88) |
Jun
(102) |
Jul
(70) |
Aug
(140) |
Sep
(149) |
Oct
(120) |
Nov
(95) |
Dec
(116) |
| 2004 |
Jan
(122) |
Feb
(51) |
Mar
(172) |
Apr
(469) |
May
(306) |
Jun
(174) |
Jul
(120) |
Aug
(172) |
Sep
(166) |
Oct
(408) |
Nov
(112) |
Dec
(33) |
| 2005 |
Jan
(166) |
Feb
(132) |
Mar
(228) |
Apr
(150) |
May
(161) |
Jun
(68) |
Jul
(113) |
Aug
(227) |
Sep
(141) |
Oct
(124) |
Nov
(87) |
Dec
(104) |
| 2006 |
Jan
(130) |
Feb
(91) |
Mar
(87) |
Apr
(50) |
May
(152) |
Jun
(82) |
Jul
(96) |
Aug
(68) |
Sep
(39) |
Oct
(60) |
Nov
(79) |
Dec
(75) |
| 2007 |
Jan
(51) |
Feb
(65) |
Mar
(32) |
Apr
(51) |
May
(58) |
Jun
(59) |
Jul
(72) |
Aug
(32) |
Sep
(35) |
Oct
(46) |
Nov
(20) |
Dec
(60) |
| 2008 |
Jan
(67) |
Feb
(16) |
Mar
(41) |
Apr
(69) |
May
(77) |
Jun
(60) |
Jul
(1) |
Aug
(12) |
Sep
(13) |
Oct
(12) |
Nov
(19) |
Dec
(10) |
| 2009 |
Jan
(6) |
Feb
(10) |
Mar
(8) |
Apr
(34) |
May
(18) |
Jun
(8) |
Jul
(16) |
Aug
(11) |
Sep
(7) |
Oct
(7) |
Nov
(9) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(9) |
Apr
(6) |
May
|
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(17) |
Oct
(4) |
Nov
(16) |
Dec
(5) |
| 2011 |
Jan
|
Feb
(3) |
Mar
(15) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(1) |
Sep
(2) |
Oct
(7) |
Nov
|
Dec
|
| 2012 |
Jan
(3) |
Feb
(4) |
Mar
(5) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(6) |
Sep
(11) |
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(2) |
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(1) |
Dec
(9) |
| 2015 |
Jan
|
Feb
(4) |
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thomas L. <ta...@le...> - 2000-09-07 17:57:11
|
I've added a couple of new icons - Large and Small - which can be used to set the display style. Clicking the other button brings up a menu showing the 'X, With...' menu to let you choose the extra details. I've also made some changes that make it easier to run a second copy of rox as another user (eg root): Running a second copy of the filer as another user will start a new copy instead of reusing the existing one. Added the '-u' option to display the name of the user running the filer in each window (also suppresses the normal don't-run-as-root warning). I had wanted to put an 'open-as-root' option on the menu, but it seems incredibly difficult to do! Added '-d', which opens a directory as a directory, even if it looks like an application. Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: Thomas L. <ta...@le...> - 2000-09-06 21:16:17
|
OK, I've implemented the new MIME-type handler setting system - see what you think. Changes to CVS in this commit: Moved 'Set Run Action' to the file menu (suggested by Ewan Mac Mahon), and make using it bring up a dialog rather than a minibuffer. Hopefully it is now easier to use! Added much improved icons for executables and for applications without icons of their own (Victor Liu See-le). Allow '/' on the pinboard and panel (text wasn't displayed - spotted by Tim Rowledge). Bugfix: auto-scrolling didn't always stop when a drag ended. Bugfix: creating a panel with the same name as a file in the current directory caused an error due to a throwback from when panels were directories (spotted by Ewan Mac Mahon). Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: Andrew B. <ab...@re...> - 2000-09-06 12:29:07
|
In message <Pin...@ar...>
Thomas Leonard <ta...@le...> wrote:
> On Tue, 5 Sep 2000, Tim Rowledge wrote:
>
> > e) should I really be getting the enlightenment menu when I menu-click
> > on the screen backgournd? Shouldn't I be getting a pinboard menu?
>
> Ah. I think the middle button is reserved for the window manager in the
> GNOME spec. So, if the pinboard menu is on button-2 then you've got a
> problem. Should we make the menu always on button-3 for the pinboard?
You can have global RISC OS style menu on middle button by adding the
following to your .xsession file: (Is this the best way of doing this?)
xmodmap -e "pointer = 1 3 2"
Of course, you then have to remember not to set the RISC OS style mouse
bindings in ROX-Filer; and also that whenever any program refers to the
right mouse button you have to use the middle, and vice versa. Also cut
and paste will now use the right button for pasting.
Despite this, I still find it quite handy. I think it could usefully be
added to the documentation somewhere, and maybe give the option to add
the line to .xsession during installation? Or even make it a feature of
ROX-Session?
Andrew
--
No signature yet...
|
|
From: Thomas L. <ta...@le...> - 2000-09-06 11:32:43
|
On Tue, 5 Sep 2000, Tim Rowledge wrote:
> Thomas Leonard <ta...@le...> is widely believed to have
> written:
> > Choose 'Set Run Action' from the menu. Drag an HTML file to Netscape :-)
> OK, I finally got this to work and make some sense. It was a bit tricky
> though- I had to try several times before it would work.
> First, since I have netscape on my icon bar (usingthe wrpper you
> provided) I thought it should work by selecting cvsbook.html, choose
> Window->set run action and drag it to the netscape icon. No luck.
> Then I tried doing it textually by typing netscape $1 in the text field;
> no luck there either as it kept insisting that some other file was
> selected, or that a file had to be highlighted. Eventually I got the
> right combination, but it wasn't a simple as I suspect you intended it
> to be!
Oh. Hmm... the MIME system needs updating a bit anyway - no time like the
present!
Here's what I propose:
- Move 'Set Run Action' to the File menu, as Ewan suggested. It works on
a file and shouldn't be in the Window menu just 'cos it opens the
minibuffer!
- Give it a dialog rather than using the minibuffer and the standard
window.
- Make the user drag the application to the dialog, rather than the file
to the application. This prevents problems like the above. It's also
easier to implement ;-)
The box should also allow entering a shell command somehow, like the
current system.
This shouldn't make it any slower, either:
Current system:
- Choose 'Set Run Action' (possibly on keyboard shortcut)
- Drag to file application
- Choose which action to set from the query box
New system:
- Choose 'Set Run Action' (possibly on keyboard shortcut)
- Drag application to dialog
- Click on one of the action buttons to set it
Actually, I think the reason for the old system was that you couldn't drag
applications from the panel. Now you can :-)
> Do you have a collection of MIME-types/* files ready to use? It might be
> nice to include a few more defaults than just text and ps files.
Ideally, packages would add a default handler to
/usr/share/Choices/MIME-types when they are installed (if there wasn't one
already). In practise, a few more examples might be good, but this is
probably up to the packagers...
The existing actions are just there to make sure people can read the
manual!
> And now for some new questions:-
> a) is there a way to set the text for icons on the iconbar? I added '</'
> to my ~/Iconbar file and it successfully put an icon for theroot dir
> there - but no text!
Oops, fixed! It appears as a mount point though, which surprised me at
first, although that's correct, of course!
> b) in the MIME-types files I see you are using 'exec mumble'. Can I do
> anything to make it cd to the directory containing the file mentioned in
> $1 ? This would help a lot in making sure the right version of Squeak is
> run when I d-click on a squeak.image file
Something like this in the applications' AppRun files:
#!/bin/bash
if [ -n "$1" -a "$1" != "-" ]; then
cd ${1%/*}
fi
exec prog "$@"
All the wrappers should be updated where this is useful. Is this
bash-only?
It could go in the filer, but it's messy. For example, if you load
something from a floppy then you can't unmount the floppy until the
application quits! Therefore, I think this should just be a hack for
now, for applications that need it...
> c) any chance of making the old shift-close trick work to open the
> parent directory? I see you have it in the window menu and yo uhave
> that up-trianlge, but still...
Depends on your window manager... I posted a thing for sawfish a while
back ;-)
> d) do you have any idea how to setup X (or enlightnement or whatever) to
> mimic RISCOS's focus/bring-forward behaviour?
Enlightentment doesn't do RISC OS's move-without-raising thing. Sawfish
does this happily though, but isn't set up quite like RISC OS by default.
Easy to change, if someone has time...
Focussing can be set to click-to-focus in most WMs.
> e) should I really be getting the enlightenment menu when I menu-click
> on the screen backgournd? Shouldn't I be getting a pinboard menu?
Ah. I think the middle button is reserved for the window manager in the
GNOME spec. So, if the pinboard menu is on button-2 then you've got a
problem. Should we make the menu always on button-3 for the pinboard?
Otherwise, complain to the WM people ;-)
Thomas Leonard
--
tal197 at users.sourceforge.net
The ROX desktop (free/GPL) : http://rox.sourceforge.net
|
|
From: Thomas L. <ta...@le...> - 2000-09-04 16:12:27
|
I've put up a new release of ROX-Session at: http://rox.sourceforge.net/rox_session.php3 ROX-Session provides a simple and (hopefully!) very reliable session manager. This is the first update in a long time. The new features are: - Easier to install, - Default setup works with the new ROX-Filer panels, - Better failsafe operation, and - Easier to configure. To install it: 0. Download and install ROX-Filer first, in the normal way. 1. Download and extract the ROX-Session archive: $ tar xzf roxsession-0.1.9.tgz $ cd roxsession-0.1.9 2. Compile it: $ ROX-Session/AppRun --compile 3. Move it to whereever you want to keep it (eg /usr/local/apps, but anywhere will do). 4. Run it (by clicking on it in the filer, or with ROX-Session/AppRun). At this point, ROX-Session will detect that it isn't already running and will offer to become your session manager. Say 'Yes'. It will create suitable .xsession and .xinitrc scripts for you and ask you to log out. 5. Log out. If you were using the old ROX-Session then you need to log out by running the *old* copy. If you deleted it, just kill the old ROX-Session process, or Ctrl-Alt-Backspace (on some systems only). 6. Hopefully, when you log in again you'll have a panel and a pinboard (both blank!). Put useful stuff on them as usual... I'm not sure many people were using ROX-Session, so this isn't all that well tested yet. I've been using the latest version myself without any trouble, though. Feedback would be good... For more information, menu-click on it in a filer window and choose Help. Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: Thomas L. <ta...@le...> - 2000-09-03 14:45:13
|
On Sun, 3 Sep 2000, Thomas Leonard wrote: > I've made some more changes to ROX-Session: [ ... ] Just to let you know, there is now a CVS snapshot on: ftp://rox.sourceforge.net/pub/rox/ This should work just like the normal archive - you don't have to do anything special. Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: Vincent L. <vi...@vi...> - 2000-09-03 12:48:54
|
On Sun, Sep 03, 2000 at 12:24:53 +0100, Thomas Leonard wrote: > On Sat, 2 Sep 2000, Vincent Lefevre wrote: > > BTW, could rox support named directories as in zsh? > > Possibly.. what are they? For instance, I can have hash -d hd=/users/vlefevre in my .zshrc, and then I can use ~hd instead of /users/vlefevre, just like ~user instead of user's home directory (e.g. /home/user). zsh can also display pathnames using such names instead of the full pathname (which would take more space to display), e.g. ~hd/rest/of/the/path instead of /users/vlefevre/rest/of/the/path -- 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...@le...> - 2000-09-03 11:27:57
|
I've made some more changes to ROX-Session: The .xsession file it creates is now much simpler - it just runs ROX-Session (plus some failsafe measures, of course). ROX-Session itself runs the Choices/ROX-Session/Login script as soon as it starts (or a default script inside the application directory if there isn't one in Choices). Hopefully, this means less chance of losing your config when you upgrade. Also, the new .xsession adds ~/bin to PATH and ~/lib to LD_LIBRARY_PATH if they exist. Hopefully, this means less complicated instructions for users in future... Anyway, can someone with a real 'sh' make sure I'm not doing anything bash-only? Thanks, PS: Maybe this would be a good program to try the packaging stuff on first? Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: Thomas L. <ta...@le...> - 2000-09-03 11:23:28
|
On Sat, 2 Sep 2000, Vincent Lefevre wrote: > On Thu, Aug 31, 2000 at 20:41:40 +0100, Thomas Leonard wrote: > > Your home directory is now displayed as '~' in the title bar, rather > > than as a full path. > > BTW, could rox support named directories as in zsh? Possibly.. what are they? Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: Thomas L. <ta...@le...> - 2000-09-02 17:46:04
|
It's been pointed out to me that ROX-Session is rather out-of-date! I've make lots of changes and committed the new version to CVS. It should be much simpler to install - just compile it and run and it should offer to write your .xsession file for you. Could someone with CVS check that it works and creates sensible files? Take care of your old .xsession files, just in case! Let me know if it works, particularly on 'odd' systems... Thanks, Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: Vincent L. <vi...@vi...> - 2000-09-02 10:44:10
|
On Thu, Aug 31, 2000 at 20:41:40 +0100, Thomas Leonard wrote: > Your home directory is now displayed as '~' in the title bar, rather > than as a full path. BTW, could rox support named directories as in zsh? -- 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: Vincent L. <vi...@vi...> - 2000-09-02 10:27:23
|
On Mon, Aug 28, 2000 at 13:56:29 +0100, Garrett C wrote: > Or, some other solutions (I still prefer my suggestion above though): > 1. The panel doubles its height to include more icons > 2. The icons are scaled down to fit in, eventually taking up two rows when > they are small enough This would be a good idea. Or better: *some* icons (chosen by the user) are scaled down. Otherwise, I prefer the RISC OS style. -- 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...@le...> - 2000-09-01 21:30:52
|
One other issue... what libraries should we link with? ImLib support should be there, IMHO, but I'm not so sure about the libvfs support. Is there even a package that provides it? Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: Thomas L. <ta...@le...> - 2000-08-31 19:50:32
|
OK, I've made a new release and put it on the download area... Changes (since 0.1.26) ~~~~~~~ All the panel code has been completely rewritten: - Panels are now stored in Choices (allowing a system admistrator to set up defaults which individual users can override), - The icons may be arranged as you please, and can go on either side of the bar, - Panels can be scrolled if they get too long. - Verticle left and right panels are available, in addition to the old top and bottom panels, - Icons can be dragged from panels to other applications. The install script no longer overwrites the handlers for text/plain and application/postscript if they are already defined (spotted by Martin Ward). When the filer is in 'target mode' (waiting for you to click on something to delete, copy, etc) a message is displayed in the toolbar to remind you. There is a new option to set the default height for new filer windows (patch from James Kermode). The timeout for the spring-open feature is now configurable (requested by Chris Garrett). Now uses the short form of --version in install.sh and doesn't try to use unsetenv() if it isn't available (Mattias Engdegård) - fixes problems with Solaris and some other systems. New options to set the pinboard text foreground and background colours (suggested by James Kermode). Your home directory is now displayed as '~' in the title bar, rather than as a full path. Enjoy, Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: <and...@fr...> - 2000-08-31 12:23:41
|
Thomas Leonard wrote: > BTW, how do we get Debian packages made? Can we just stick them on the > website or do we need to get a registered Debian developer to help us? ISTR that you need to get some sort of permission... or "registration"... to get into Debian packages - presumably this could be done via an official Debian person. *ducks and waits for someone involved with the, ahem, "One True Linux Distro" to contradict him* Andy |
|
From: Thomas L. <ta...@le...> - 2000-08-31 10:43:31
|
On Wed, 30 Aug 2000, David Given wrote: > [...] > >FHS would be nice, but I'm not sure they specify a place for > >application directories? Someone will have to read it in detail, > >though. We might end up in /opt, which could be OK. > On my Debian system I put my Choices and Apps directories in /usr/local. > However, Debian packages must not install into /usr/local; they should go in > /usr instead (/usr/local is reserved for non-packaged software). > > I suspect that the global Choices directory should live in /etc; probably > /etc/rox/choices. I think we can leave Choices where it is now, because: - /etc is for host-specific config, which Choices isn't. - it shouldn't go under 'rox', because Choices is a general system, not ROX-specific. - Choices has already been moved to /usr/share/Choices to be FHS-compiant! > I'd expect applications to go in /usr/Apps or /usr/rox/Apps or something > like that. This is the bigger question. Adding a new top-level directory in /usr is quite anti-social, but would be acceptable if the application directory thing catches on. Again, I'd rather not make application directories ROX specific; it would be quite possible for gmc or kfm to support them if they wanted. /opt is for self-contained packages, which is closer to what we have. However, the FHS defines the structure inside the package too (/opt/rox-filer/man, /opt/rox-filer/bin, etc), which we don't follow. Another thing to remember is that there is no search path for applications, so distributions, sysadmins and users can put them whereever they please without causing compatibility problems. Whereas, Choices must be locateable by everyone without setting CHOICESPATH. Therefore, I believe we must decide globally where to put Choices, but let packagers decide where application directories go themselves... > Unfortunately, ROX doesn't really fit the Debian directory layout... ;-) > [...] > >So, I think the download page will say something like: > > > > Download <mime-stuff.rpm> > > Download <common.rpm> > > Download at least one of the following: > > <src.rpm> > > <i386.rpm> > > <arm32.rpm> > > <...> > > > >Not quite as easy, but not too bad, either? What would people think about > >that? > > This is all trivial under Debian (the One True Linux distro). With the proper > dependencies set, all you would do is: > > apt-get install rox-filer > > ...and it would automatically fetch and install (in order) rox-common, > rox-icons, and rox-filer. Debian's system is nice :-) But would RPM users be happy with the above, too? BTW, how do we get Debian packages made? Can we just stick them on the website or do we need to get a registered Debian developer to help us? Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: Thomas L. <ta...@le...> - 2000-08-31 10:43:18
|
Here are the latest changes to CVS: Increased the distance you have to move the pointer to start a drag slightly. Updated the manual. Panel icons can now be moved from one side to the other by simply moving over the gap in the middle. Previously, you had to jump over an icon on the other side (tricky if there weren't any!). Left and right panels look better now. Also, they shrink if you add a top or bottom panel to make room. This might have conflicts which a few window managers, but you can always use the -o option. Adding the arrows looks rather tricky :-( However, the 'drag-the-gap' method works really well, so I'm planning on just using that for now. I'll probably make a new release soon so people can test all the new panel stuff more easily, although the CVS snapshot should be valid by now. Then, we should try to make some packages for the next release to make sure we've got that working well before the actual stable release! Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: David G. <dg...@ta...> - 2000-08-30 12:04:40
|
[...] >FHS would be nice, but I'm not sure they specify a place for >application directories? Someone will have to read it in detail, >though. We might end up in /opt, which could be OK. > >It's up to you where it goes, but it would be nice if the user could open >a directory and easily see all the installed applications, without any >other clutter... On my Debian system I put my Choices and Apps directories in /usr/local. However, Debian packages must not install into /usr/local; they should go in /usr instead (/usr/local is reserved for non-packaged software). I suspect that the global Choices directory should live in /etc; probably /etc/rox/choices. I'd expect applications to go in /usr/Apps or /usr/rox/Apps or something like that. Unfortunately, ROX doesn't really fit the Debian directory layout... [...] >So, I think the download page will say something like: > > Download <mime-stuff.rpm> > Download <common.rpm> > Download at least one of the following: > <src.rpm> > <i386.rpm> > <arm32.rpm> > <...> > >Not quite as easy, but not too bad, either? What would people think about >that? This is all trivial under Debian (the One True Linux distro). With the proper dependencies set, all you would do is: apt-get install rox-filer ...and it would automatically fetch and install (in order) rox-common, rox-icons, and rox-filer. -- +- David Given ---------------McQ-+ | Work: dg...@ta... | Truth is stranger than fiction, because | Play: dg...@in... | fiction has to make sense. +- http://wired.st-and.ac.uk/~dg -+ |
|
From: Thomas L. <ta...@le...> - 2000-08-30 10:40:34
|
On Tue, 29 Aug 2000, Andy Piper wrote:
> Thomas Leonard wrote:
> >
> > On Tue, 29 Aug 2000, Andy Piper wrote:
> >
> > > Well, for RPMs at least, that would seem overkill, since you
> > > would presumably supply the source and binary RPMs, so you
> > > don't need three distinct packages - just your choice of
> > > packages, plus the source versions of those.
> >
> > I only thinking about the filer for now. Common would be
> > /usr/apps/ROX-Filer/{AppRun, pixmaps, Help, etc} plus the Choices
> > stuff.
>
> OK... filer only is easier. Are we bothered about conforming to FHS
> (filesystem hierarchy standard), or are we sticking with /usr/apps?
FHS would be nice, but I'm not sure they specify a place for
application directories? Someone will have to read it in detail,
though. We might end up in /opt, which could be OK.
It's up to you where it goes, but it would be nice if the user could open
a directory and easily see all the installed applications, without any
other clutter...
> NB I have a feeling you /won't/ be packaged for Debian if you don't
> follow FHS. RedHat have a fairly cavalier attitude to the standards
> anyway, so it wouldn't matter.
Of course, there's nothing to stop us putting it in a different place on
each, but standardising would be a good idea!
> > The point being that if I want i386 and alpha packages, I don't want or
> > need the common bits, like the manual, twice. And with a package system,
> > it's not just the package size, it's that you'll get errors if you try to
> > install two at once!
>
> Well... I don't quite agree with what you are saying, here. The RPM
> way of doing things - and I *believe* the apt way, which I looked at
> briefly once before - is to have a single source RPM, which
> essentially contains the sources themselves, an autoconfiguration
> script, and a .spec which defines what it all looks like to install.
> Then, you can build that RPM on your platform of choice (i386, i586,
> ARM, alpha, etc.) and you will get a binary package.
That doesn't work if you have separate run-time stuff though. Vim has the
same problem as us, and it uses a 'common' package for the stuff which is
needed by src and binaries.
It really would be good to just say "Download this RPM", but I don't
think it will work! Consider:
- The source must contain the icons, otherwise you can't get a working
system from the source package.
- The binary must contain the icons, otherwise you can't run using only
the binary package.
Now, if someone installs the binary first and then decides they want the
source, they're stuck! At best, they'll install to different locations and
the user has to download a load of stuff twice. At worst, we get
conflicts.
If you can think of a way to make this work, I'm listening!
In fact, I could make a case for splitting the Choices stuff into yet
another package. After all, it's not filer-specific. If someone writes
a replacement filer, they'll want to make their filer depend on the icons,
but not on rox.
Also, the icons may get big (just imaging if we actually had an icon for
each of the default MIME-types!). It would be pretty bad if you had to
download the same few megs of data each time you upgraded the filer (as
you have to do now). It would also mean that we couldn't upgrade the icons
without making a new release of the filer (and upgrading a dozen or so
packages!).
So, I think the download page will say something like:
Download <mime-stuff.rpm>
Download <common.rpm>
Download at least one of the following:
<src.rpm>
<i386.rpm>
<arm32.rpm>
<...>
Not quite as easy, but not too bad, either? What would people think about
that?
> OK... well, I've toyed with it in the past, but for smaller projects
> than ROX, so this will be fun ;)
>
> I'll probably have a look at it all later this week.
Should be interesting, anyway!
Thomas Leonard
--
tal197 at users.sourceforge.net
The ROX desktop (free/GPL) : http://rox.sourceforge.net
|
|
From: Andy P. <squ...@uk...> - 2000-08-29 22:22:42
|
Thomas Leonard wrote:
>
> On Tue, 29 Aug 2000, Andy Piper wrote:
>
> > Well, for RPMs at least, that would seem overkill, since you
> > would presumably supply the source and binary RPMs, so you
> > don't need three distinct packages - just your choice of
> > packages, plus the source versions of those.
>
> I only thinking about the filer for now. Common would be
> /usr/apps/ROX-Filer/{AppRun, pixmaps, Help, etc} plus the Choices
> stuff.
OK... filer only is easier. Are we bothered about conforming to FHS
(filesystem hierarchy standard), or are we sticking with /usr/apps?
NB I have a feeling you /won't/ be packaged for Debian if you don't
follow FHS. RedHat have a fairly cavalier attitude to the standards
anyway, so it wouldn't matter.
> 'src' would simply add the 'src' directory into that.
> 'i368' would add a Linux-i386 subdirectory (and probably a few symlinks
> too, for -i586 and so on).
>
> The point being that if I want i386 and alpha packages, I don't want or
> need the common bits, like the manual, twice. And with a package system,
> it's not just the package size, it's that you'll get errors if you try to
> install two at once!
Well... I don't quite agree with what you are saying, here. The RPM
way of doing things - and I *believe* the apt way, which I looked at
briefly once before - is to have a single source RPM, which
essentially contains the sources themselves, an autoconfiguration
script, and a .spec which defines what it all looks like to install.
Then, you can build that RPM on your platform of choice (i386, i586,
ARM, alpha, etc.) and you will get a binary package.
For a tarball, 'make install' should just install all of the binaries
in the correct places, and 'make uninstall' clean them up again (not
sure about binary tarballs really, probably just an install script to
do the dirty work).
> > - has anyone produced a .spec
> > file to build an RPM yet?
>
> Not yet, but I'll include it once it's done. I can't easily check it
> though, as I know almost nothing about RPM at the moment :-(
OK... well, I've toyed with it in the past, but for smaller projects
than ROX, so this will be fun ;)
I'll probably have a look at it all later this week.
--
Andy Piper - Fareham, Hampshire (UK)
and...@fr... | an...@un...
* OpenUT for Linux | http://openut.sourceforge.net
* Unreal Tournament News | http://www.unrealtournament.org
|
|
From: Thomas L. <ta...@le...> - 2000-08-29 21:13:12
|
On Tue, 29 Aug 2000, Andy Piper wrote:
> Thomas Leonard wrote:
> > I guess we'll want to split it into several packages?
> > rox-common, rox-src and rox-binary-* ?
> >
> > That way, everyone will need at least two packages: 'common' and then
> > either 'src' or at least one binary package. This probably applies to
> > tarballs and other packages too...
>
> Well, for RPMs at least, that would seem overkill, since you
> would presumably supply the source and binary RPMs, so you
> don't need three distinct packages - just your choice of
> packages, plus the source versions of those.
I only thinking about the filer for now. Common would be
/usr/apps/ROX-Filer/{AppRun, pixmaps, Help, etc} plus the Choices
stuff.
'src' would simply add the 'src' directory into that.
'i368' would add a Linux-i386 subdirectory (and probably a few symlinks
too, for -i586 and so on).
The point being that if I want i386 and alpha packages, I don't want or
need the common bits, like the manual, twice. And with a package system,
it's not just the package size, it's that you'll get errors if you try to
install two at once!
> I confess I've not looked (been tied up with Unreal
> Tournament things lately... :) - has anyone produced a .spec
> file to build an RPM yet? I guess I'll go and have a quick
> look once the download I'm in the middle of has completed.
Not yet, but I'll include it once it's done. I can't easily check it
though, as I know almost nothing about RPM at the moment :-(
Thomas Leonard
--
tal197 at users.sourceforge.net
The ROX desktop (free/GPL) : http://rox.sourceforge.net
|
|
From: Ewan M. M. <ec...@yo...> - 2000-08-29 19:11:23
|
On Tue, 29 Aug 2000, Andy Piper wrote: > Thomas Leonard wrote: <snip> > > Thanks! > > I guess we'll want to split it into several packages? > > rox-common, rox-src and rox-binary-* ? > > > > That way, everyone will need at least two packages: 'common' and then > > either 'src' or at least one binary package. This probably applies to > > tarballs and other packages too... > > Well, for RPMs at least, that would seem overkill, since you > would presumably supply the source and binary RPMs, so you > don't need three distinct packages - just your choice of > packages, plus the source versions of those. > > I confess I've not looked (been tied up with Unreal > Tournament things lately... :) - has anyone produced a .spec > file to build an RPM yet? I guess I'll go and have a quick > look once the download I'm in the middle of has completed. > > Can you describe what you envisage being in the "-common" > and "-binary" packages? Presumably we'd want to keep > ROX-Filer separate from the session stuff.... so maybe a > general rethink is required here! I think Thomas is thinking of a source package for source code, a binary package for compiled code, and a common one for other things like icons that aren't code at all (I think this is similar to the way Vim is distributed?). Hence everyone would need two packages, the resources plus either binary code, or source code to make their own binaries. I think this is indeed overkill; it would be best to include the resources in both the binary and source packages so that either can stand alone; it means a bit of 'unnecessary' duplication, but I think it's worth it for the gain in simplicity. If separate packages are made of the different components I think you'll end up with five: Filer binary, Filer source, Session binary, Session source, and one for the utils (which I think are all scripts so don't have the divide). That's before you get into packages for different platforms too, so I think that's probably enough complexity. Ewan |
|
From: Andy P. <squ...@uk...> - 2000-08-29 17:40:43
|
Thomas Leonard wrote: > > On Mon, 28 Aug 2000, Andy Piper wrote: > > > Well, I'm up for it - RedHat anyway - although I've not > > fulfilled the role before, so I'd have to have a look at it > > first and see what is required. > > Thanks! > > I guess we'll want to split it into several packages? > rox-common, rox-src and rox-binary-* ? > > That way, everyone will need at least two packages: 'common' and then > either 'src' or at least one binary package. This probably applies to > tarballs and other packages too... Well, for RPMs at least, that would seem overkill, since you would presumably supply the source and binary RPMs, so you don't need three distinct packages - just your choice of packages, plus the source versions of those. I confess I've not looked (been tied up with Unreal Tournament things lately... :) - has anyone produced a .spec file to build an RPM yet? I guess I'll go and have a quick look once the download I'm in the middle of has completed. Can you describe what you envisage being in the "-common" and "-binary" packages? Presumably we'd want to keep ROX-Filer separate from the session stuff.... so maybe a general rethink is required here! -- Andy Piper - Fareham, Hampshire (UK) and...@fr... | an...@un... * OpenUT for Linux | http://openut.sourceforge.net * Unreal Tournament News | http://www.unrealtournament.org |
|
From: Thomas L. <ta...@le...> - 2000-08-29 15:45:24
|
On Tue, 29 Aug 2000, Tom Hawtin wrote: [...] > The time taken and speed of the RISC OS iconbar scrolling irritated me. I > think to do it well you need to detect the retardation of the pointer as it > is about to stop in the scroll zone. Sitting there and waiting because any > shorter time might indicate that the pointer is about to leave is not good > enough, IMHO. Perhaps some subtle indication of when the scroll is about to > come would be helpful. If we have a visible arrow super-imposed on the bar, then I guess it will only scroll when you hold the mouse button down (although clicking should probably move it a noticable distance as well). This might need to be made an option, though... Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
|
From: Thomas L. <ta...@le...> - 2000-08-29 15:45:11
|
On Mon, 28 Aug 2000, Andy Piper wrote: > Thomas Leonard wrote: > > > > Speaking of which, we need to aquire some binary-maintainers and packagers > > for the eventual 1.0.0 release - any offers? > > Well, I'm up for it - RedHat anyway - although I've not > fulfilled the role before, so I'd have to have a look at it > first and see what is required. Thanks! I guess we'll want to split it into several packages? rox-common, rox-src and rox-binary-* ? That way, everyone will need at least two packages: 'common' and then either 'src' or at least one binary package. This probably applies to tarballs and other packages too... Thomas Leonard -- tal197 at users.sourceforge.net The ROX desktop (free/GPL) : http://rox.sourceforge.net |
79 messages has been excluded from this view by a project administrator.