...generally right button does reverse of left button so you can scroll up and down using one scroll button without moving the mouse.
ROX doesn't implement reverse scrolling itself,
as it uses Gtk's scrollbars. However, I have made
a patch for Gtk. See the bug report on bugzilla for the discussion. I don't think the developers realise how useful this is, though, so don't expect to see it in 2.0:-(
when a file has an executable flag - it automatically runs it -- but i'm sure there's a option somewhere to turn that off... I just havn't looked..
The Options box would be a good place to start;-)
Try Options->Types->Ignore eXecutable bit for known extensions.
Also, for text files, click with Shift held down to
load it into a text editor instead of running it (this works with other files too).
Shift + right button click to get a menu of possible applications to send it to.
Who want's to go to submenu after submenu just to get to the delete option?
There are a few things you can do about this:
Bind a key (eg, Ctrl-X) to Delete. Now, you can just press Ctrl-X and click on the file.
Bring up the menu with Ctrl held down. That way, the pointer will appear right in the middle of the menu you want.
Bind ! to open the shell minibuffer. Then you can type !rm<Return> to delete the file under the cursor.
Use Gtk+-2.0 (compile using --with-gtk2). This supports Mac-style menus that let you move quickly from the root menu to the Delete entry in the submenu without it closing. Since the menu with Delete is already open when the main menu is displayed, you just move the mouse straight to the item.
I may make an option so that right-clicking a file goes straight to the context menu. For most users, though, it's better to show them the whole menu every time.
Oh, and ROX *does* use a "CHOICESPATH" environment variable (as I just discovered) which should allow the directory to be moved (I think), but ROX breaks when the variable is set:(
Note that it's a path, not just a directory. If you set it to just ~/.choices then the filer won't be able to find its icons... (still seems to run OK, though, apart from that;-)
This is quite funny from a social psyc perspective.
Actually, although it sounds like a way to 'trick' developers into fixing your bug, I find that broken patches are quite nice from the other end too (ie, as the one doing the fixing).
It seems easier to fix a broken patch (even one so broken that you end up rewriting the whole thing) than to get round to doing it yourself from scratch.
I'd also suggest people try submitting broken documentation for various projects. Even if you don't understand something, still document it. The developers are more likely to correct your text than they are to spotaneously write it themselves...
Well, it sounds like start-up time is good (which is the important thing for me).
Compile time doesn't matter much, since I guess the compiler is running under the CLR too, so someone will write a fast C version sooner or later (as eg, IBM's jikes solved the compilation speed problem of Sun's javac).
Does anyone know how.NET does for speed?
ie, Java takes an absolute age to initialise which makes it unsuitable for desktop applications or utilities (although people still try... maybe in a few years' time...).
Does.NET introduce an even bigger overhead, or have they sorted it out?
Also, is there any overhead for languages that aleady use a VM (eg, python, perl) if they switch to.NET instead? Will the tailor-made version be more efficient because it's designed with the language in mind, or does the benefit of having all the optimisations done on a common system compensate for that?
I really like the idea of a common cross-platform runtime, but not if it makes my text editor take 5 seconds to load!
If you're using a program that cycles through all available memory + 10Mb, of COURSE it will be slow!
Nonsense. That assumes that you always throw out the least-recently-used pages from memory (so, in this case, you throw out each page just before you access it).
A good VM could spot this access pattern and throw out the page just used (which won't been needed again for ages) instead, keeping the pages that are about to be used in memory.
There are other places where this helps, eg playing a video or audio file from disk, where recently accessed data is never needed again and should be quickly thrown away (rather than paging out other processes, etc).
With X running as root, you lose the security of Linux...
Now, you do realise that X runs a root on normal Linux distros, too, don't you?
(and yes, this is very bad design, but we're stuck with it until a bit more of the device handling goes in the kernel and the rest of X can run as a normal user)
Don't get me wrong - KDE is a good looking and extremely functional desktop. It's really slick, and I like a lot of the KDE apps. The same goes for GNOME, although it still doesn't feel quite as polished to me. The problem is, these desktops are all clones of Windows. One of the reasons I left Windows in the first place was the annoying GUI, and these "desktop environments" do little more than mimic it.
So, use one of the others. ROX (which I develop for) is quite different to Windows, and XFCE is different again.
The original poster said these were things the user had to be told. I think the reasons for the actual names are historical (/usr used to contain user home directories, with programs in/bin, then programs started appearing in/usr/bin and homes got moved out to/home?).
It should be tidied up. A nice starting point is to assume that everyone should be able to understand the root directory. Eg:
/System stuff only the sysadmin needs to care about (/etc,/proc,/dev,/var,/lib,/boot,/sbin, etc all go in here).
/Apps programs users want to run (Gimp, Galeon, etc live here).
/Documents users files (like/home).
/Floppy, etc (as before)
At least then I could show my parents the root dir , ATM it's just embarassing trying to explain it:-(
Eh? It already does solve it for me (and Gtk+-2.0's in API freeze now, so that should be the end of it). ROX-Filer (CVS) should compile cleanly against 1.3.11 or 1.2.x. (current developer release doesn't support 1.3.11 because that was before the API freeze).
Sure, it means compiling against both versions for testing (but there are other developers who do that).
I know it would be nice to dump the 1.2.x users, but it simply won't work (already had enough complaints about the developer releases requiring gdk-pixbuf, even though the stable release doesn't).
For 2.0, they've changed the signal handling, menu short-cuts, text rendering, image handling, etc.
Do I require everyone to install Gtk+-2.0 (when it's officially released, of course), thus annoying everyone who hasn't upgraded their distro in the last few months. Or should I stick to 1.2, and not let anyone benifit from the new features, even if they have it installed?
there is also something to be said for double clicking 'setup.exe'
Well first, this isn't the issue here. We're talking about compiling from source which isn't the same as deciding how to install a binary once compiled.
As for rpm, etc you just want a graphical front-end, I think.
That said, Window's setup.exe is actually unnecessary complicated for users. With ROX, we're using application directories. There is no setup program because the program can just run in-place.
See the example at the bottom of this page for an example. As a bonus, running a source package is done in exactly the same way as running a binary (it just takes a bit longer).
The whole business of installing is terribly arcane if you think about it (hint: the computer already has everything it needs to run the application... why the extra steps?)
I need to demonstrate that the benefits of autoconf outweigh the costs
You don't have to migrate the whole thing at once.
Just start with a nice simple configure.in that
copies Makefile.in to Makefile and config.h.in
to config.h and add #includes for config.h everywhere.
Make sure new tests go in configure.in and you can slowly move across with little trouble. It should therefore be pretty easy to show that the costs are very low...
Unix and Linux have always had the chroot() system call. This call was used to trap a process into a sub-directory. After the system-call, the process is led to believe that the sub-directory is now the root directory. This system call can't be reversed. In fact, the only thing a process can do is trap itself further and further in the file-system (calling chroot() again).
And...
The vserver is trapped into a sub-directory of the main server and can't escape. This is done by the standard chroot() system call found on all Unix and Linux boxes.
But, I thought you couldn't (safely) run root processes in a chroot jail, because escape is easy if you can call chroot? Eg, create a subdirectory in your jail and chroot to that (keeping the same current directory), then chroot("../../../../") to get out of jail. Is it really safe to give someone the root password to a vserver in this system?
Why can't I drag my text file on top of the XEmacs icon on the panel or kicker and have it automatically open up in XEmacs?
Does this really not work? Dragging a text file onto emacs on the panel works fine here (ROX), and I'd be amazed if the two big desktops didn't do that too...
I can't stand it when people say they like diversity in the desktop; they feel that having umpteen desktop environments is beneficial. How the fuck is that remotely true?
Because different people have different ways of working. With KDE vs GNOME you may have a point; they basically both try to reimplement the same interface, which is pointless as far as users are concerned.
To reimplement a desktop because you prefer
a different langauge, don't like the project leader, etc... that is indeed a waste of time.
But when a new desktop offers something new and useful at the user's level... that's good to have. That's what keeps us ahead of simply being stuck with the Windows UI, and the GPL allows good ideas to spread freely.
Witness their install instructions -- download something from a web site, and pipe it into a shell run as root. I think not...
And how is this different from installing a.deb or a.rpm file? Fetch from web, run script as root.
Even a source archive that requires the 'make install' to be run as root has the same problem.
Really, unless something is installing a set-uid binary, it shouldn't need to be root to install...
Slashdot Mirror
Actually, ROX-Filer does deal with that (although a patch recently appeared on the developer list to let it use the GNOME settings instead).
As an example, let's say you want HTML documents to load into Galeon:
You can also supply a command in the dialog box instead, eg galeon "$@".
ROX doesn't implement reverse scrolling itself, as it uses Gtk's scrollbars. However, I have made a patch for Gtk. See the bug report on bugzilla for the discussion. I don't think the developers realise how useful this is, though, so don't expect to see it in 2.0 :-(
The Options box would be a good place to start ;-)
Try Options->Types->Ignore eXecutable bit for known extensions.
Also, for text files, click with Shift held down to load it into a text editor instead of running it (this works with other files too). Shift + right button click to get a menu of possible applications to send it to.
There are a few things you can do about this:
I may make an option so that right-clicking a file goes straight to the context menu. For most users, though, it's better to show them the whole menu every time.
Note that it's a path, not just a directory. If you set it to just ~/.choices then the filer won't be able to find its icons... (still seems to run OK, though, apart from that ;-)
Actually, although it sounds like a way to 'trick' developers into fixing your bug, I find that broken patches are quite nice from the other end too (ie, as the one doing the fixing).
It seems easier to fix a broken patch (even one so broken that you end up rewriting the whole thing) than to get round to doing it yourself from scratch.
I'd also suggest people try submitting broken documentation for various projects. Even if you don't understand something, still document it. The developers are more likely to correct your text than they are to spotaneously write it themselves...
Thanks for the replies!
Well, it sounds like start-up time is good (which is the important thing for me).
Compile time doesn't matter much, since I guess the compiler is running under the CLR too, so someone will write a fast C version sooner or later (as eg, IBM's jikes solved the compilation speed problem of Sun's javac).
Does anyone know how .NET does for speed?
.NET introduce an even bigger overhead, or have they sorted it out?
.NET instead? Will the tailor-made version be more efficient because it's designed with the language in mind, or does the benefit of having all the optimisations done on a common system compensate for that?
ie, Java takes an absolute age to initialise which makes it unsuitable for desktop applications or utilities (although people still try... maybe in a few years' time...).
Does
Also, is there any overhead for languages that aleady use a VM (eg, python, perl) if they switch to
I really like the idea of a common cross-platform runtime, but not if it makes my text editor take 5 seconds to load!
Nonsense. That assumes that you always throw out the least-recently-used pages from memory (so, in this case, you throw out each page just before you access it).
A good VM could spot this access pattern and throw out the page just used (which won't been needed again for ages) instead, keeping the pages that are about to be used in memory.
There are other places where this helps, eg playing a video or audio file from disk, where recently accessed data is never needed again and should be quickly thrown away (rather than paging out other processes, etc).
Now, you do realise that X runs a root on normal Linux distros, too, don't you?
(and yes, this is very bad design, but we're stuck with it until a bit more of the device handling goes in the kernel and the rest of X can run as a normal user)
Even better, AVFS puts this at the filesystem level, so every application can do this, including shell commands.
It does allow icons on the background but, unlike gmc, only if you turn the feature on. See the Pinboard Support section of the manual.
Integration with other GNOME apps should be pretty good, although many GNOME apps have hideously broken support for the XDND protocol.
So, use one of the others. ROX (which I develop for) is quite different to Windows, and XFCE is different again.
The original poster said these were things the user had to be told. I think the reasons for the actual names are historical (/usr used to contain user home directories, with programs in /bin, then programs started appearing in /usr/bin and homes got moved out to /home?).
It should be tidied up. A nice starting point is to assume that everyone should be able to understand the root directory. Eg:
/System stuff only the sysadmin needs to care about (/etc, /proc, /dev, /var, /lib, /boot, /sbin, etc all go in here). /Apps programs users want to run (Gimp, Galeon, etc live here). /Documents users files (like /home). /Floppy, etc (as before)
At least then I could show my parents the root dir , ATM it's just embarassing trying to explain itSure, it means compiling against both versions for testing (but there are other developers who do that).
Mostly it's just one line stuff, like this:
#ifdef GTK2
gtk_accel_map_load(menurc);
#else
gtk_item_factory_parse_rc(menurc);
#endif
I know it would be nice to dump the 1.2.x users, but it simply won't work (already had enough complaints about the developer releases requiring gdk-pixbuf, even though the stable release doesn't).
For 2.0, they've changed the signal handling, menu short-cuts, text rendering, image handling, etc.
Do I require everyone to install Gtk+-2.0 (when it's officially released, of course), thus annoying everyone who hasn't upgraded their distro in the last few months. Or should I stick to 1.2, and not let anyone benifit from the new features, even if they have it installed?
Or shall I just use autoconf and support both?
So how would you cope with supporting three different releases of libxml, each with different functions and prototypes for saving out an XML document?
Well first, this isn't the issue here. We're talking about compiling from source which isn't the same as deciding how to install a binary once compiled.
As for rpm, etc you just want a graphical front-end, I think.
That said, Window's setup.exe is actually unnecessary complicated for users. With ROX, we're using application directories. There is no setup program because the program can just run in-place. See the example at the bottom of this page for an example. As a bonus, running a source package is done in exactly the same way as running a binary (it just takes a bit longer).
The whole business of installing is terribly arcane if you think about it (hint: the computer already has everything it needs to run the application... why the extra steps?)
You don't have to migrate the whole thing at once. Just start with a nice simple configure.in that copies Makefile.in to Makefile and config.h.in to config.h and add #includes for config.h everywhere.
Make sure new tests go in configure.in and you can slowly move across with little trouble. It should therefore be pretty easy to show that the costs are very low...
Unix and Linux have always had the chroot() system call. This call was used to trap a process into a sub-directory. After the system-call, the process is led to believe that the sub-directory is now the root directory. This system call can't be reversed. In fact, the only thing a process can do is trap itself further and further in the file-system (calling chroot() again).
And...
The vserver is trapped into a sub-directory of the main server and can't escape. This is done by the standard chroot() system call found on all Unix and Linux boxes.
But, I thought you couldn't (safely) run root processes in a chroot jail, because escape is easy if you can call chroot? Eg, create a subdirectory in your jail and chroot to that (keeping the same current directory), then chroot("../../../../") to get out of jail. Is it really safe to give someone the root password to a vserver in this system?
ROX-Filer doesn't use wxWindows, it used GTK+.
Does this really not work? Dragging a text file onto emacs on the panel works fine here (ROX), and I'd be amazed if the two big desktops didn't do that too...
Because different people have different ways of working. With KDE vs GNOME you may have a point; they basically both try to reimplement the same interface, which is pointless as far as users are concerned.
To reimplement a desktop because you prefer a different langauge, don't like the project leader, etc... that is indeed a waste of time.
But when a new desktop offers something new and useful at the user's level... that's good to have. That's what keeps us ahead of simply being stuck with the Windows UI, and the GPL allows good ideas to spread freely.
Provide a fail-safe mode on boot that uses framebuffer?
And how is this different from installing a .deb or a .rpm file? Fetch from web, run script as root.
Even a source archive that requires the 'make install' to be run as root has the same problem.
Really, unless something is installing a set-uid binary, it shouldn't need to be root to install...