“Although I have some doubts that XFCE is ‘so very much lighter’ than GNOME (GNOME 2.20 doesn’t take too much memory if you don’t start all kind of crap), it is still lighter, and in a few years there will be less and less antiquated computers who require extra-light window managers (Fluxbox, Openbox, Blackbox, WindowMaker, IceWM). XFCE is reasonably mature, and constantly improving, so it has all the chances to become the mid-weighted Desktop Environment of choice pretty soon! What is XFCE needing to reach the Nirvana? Here’s the way I see things.”
FTA: “XFCE should continue to cooperate with the Linux distros that ship with it, in order to ensure a reasonable level of bugginess.”
I know the author isn’t a native english speaker, but that sentence is quite funny.
FTA: “XFCE should avoid the mistake made by the GNOME project, who has abandoned some of the applications (e.g. Atomix, Agnubis, Glipper), only to integrate as “official” poor quality applications like Dia!”
These were abandoned by their respective developers, not the Gnome project. Any piece of software needs somebody committed to preventing bitrot and implementing new features. Dia has always had somebody working on it, and to be fair there isn’t really an alternative to Dia out there for drawing flow charts & technical diagrams.
Anyway, I doubt XFCE will ever become a major competitor to Gnome or KDE. It simply does not have the momentum, however it will occupy it’s niche as Gnome/KDE continue to move away from lower-spec PCs.
Does “Linux distros that ship it” sound better than “Linux distros that ship with it”?
I guess it was the last part of the sentence which sounded funny. You know, to “cooperate in order to ensure a decent level of bugginess” sounds like they will try to introduce some bugs just so the level of “bugginess” is not too low 🙂
Anyway, there is a nice follow up post about choosing an XFCE based distro:
http://tinyurl.com/2kja35
Well, I find Kivio much better than Dia on every possible aspect but then, it is a KDE/Qt application and thus probably doesn’t fit what XFCE and/or GNOME users may be looking for (although I will never understand people that choose to use inferior software because of its toolkit!)
I find extremely sad the author considers Mono dangerous enough to put it first on his list. To put things clear: I don’t like .net and therefore I don’t like Mono, but I fail to see why it’s such a threat for XFCE, or FOSS in general, for that matter. It’s just because of software patents?
And please, can we avoid the childish Winblows? Along with M(money symbol) if possible.
Edit: OSNews filtered the M(money). It’s a trap!
Edited 2008-02-20 01:05 UTC
WRT Mono, I’ve added to the article the following UPDATE:
“For most people, it’s because of the possible patent threats, but in my case it’s even simpler: I don’t want .EXE and .DLL files on my Linux box! Mono mimics .NET so well that it builds files with the EXE and DLL extensions, albeit Mono is not developed by Microsoft! Adding the possibility of having Mono on XFCE (e.g. Gtk#) for the development of some small tool (think of Tomboy) would soon transform into the customary practice of shipping XFCE with that small Mono tool by default. Why should I have EXE and DLL files in Linux… by default?! I don’t want to remove them: I don’t want them to be there in the first place!”
Heh.. Linux vs. Windows isn’t enough, nor GNOME vs. KDE or BSDL vs. GPL… now we need PE vs. ELF!
Well, I’ll be rooting for COFF.
Having EXE and DLL in front of my eyes under Linux makes me feel that Microsoft is still running my life! And this is not an accurate assertion…
Suppose you have a Debian testing box. Here’s some files with offending names needed in order to run F-Spot, and that make your Linux box to look like a Windows box!
/usr/lib/f-spot/f-spot.exe
/usr/lib/f-spot/FlickrNet.dll
/usr/lib/f-spot/gnome-keyring-sharp.dll
/usr/lib/f-spot/google-sharp.dll
/usr/lib/f-spot/libgphoto2-sharp.dll
/usr/lib/f-spot/NDesk.Glitz.dll
/usr/lib/f-spot/SemWeb.dll
/usr/lib/f-spot/SmugMugNet.dll
/usr/lib/f-spot/Tao.OpenGl.dll
/usr/lib/f-spot/Tao.OpenGl.ExtensionLoader.dll
/usr/lib/f-spot/Tao.OpenGl.Glu.dll
/usr/lib/mono/2.0/CustomMarshalers.dll
/usr/lib/mono/2.0/ICSharpCode.SharpZipLib.dll
/usr/lib/mono/2.0/Mono.CompilerServices.SymbolWriter.dll
/usr/lib/mono/2.0/Mono.Data.dll
/usr/lib/mono/2.0/Mono.Data.Sqlite.dll
/usr/lib/mono/2.0/Mono.Data.SqliteClient.dll
/usr/lib/mono/2.0/Mono.Data.SybaseClient.dll
/usr/lib/mono/2.0/Mono.Data.TdsClient.dll
/usr/lib/mono/2.0/Mono.GetOptions.dll
/usr/lib/mono/2.0/Mono.Http.dll
/usr/lib/mono/2.0/Mono.Posix.dll
/usr/lib/mono/2.0/Mono.Security.Win32.dll
/usr/lib/mono/2.0/mscorlib.dll
/usr/lib/mono/2.0/OpenSystem.C.dll
/usr/lib/mono/2.0/System.Configuration.dll
/usr/lib/mono/2.0/System.Configuration.Install.dll
/usr/lib/mono/2.0/System.Core.dll
/usr/lib/mono/2.0/System.Data.dll
/usr/lib/mono/2.0/System.dll
/usr/lib/mono/2.0/System.Drawing.dll
/usr/lib/mono/2.0/System.EnterpriseServices.dll
/usr/lib/mono/2.0/System.Management.dll
/usr/lib/mono/2.0/System.Security.dll
/usr/lib/mono/2.0/System.ServiceProcess.dll
/usr/lib/mono/2.0/System.Transactions.dll
/usr/lib/mono/2.0/System.Web.dll
/usr/lib/mono/2.0/System.Web.Services.dll
/usr/lib/mono/2.0/System.Xml.dll
/usr/lib/mono/gac/CustomMarshalers/2.0.0.0__b03f5f7f11d50a3a/CustomMar shalers.dll
/usr/lib/mono/gac/ICSharpCode.SharpZipLib/2.84.0.0__1b03e6acf1164f73/I CSharpCode.SharpZipLib.dll
/usr/lib/mono/gac/mono-service/2.0.0.0__0738eb9f132ed756/mono-service.exe
/usr/lib/mono/gac/Mono.CompilerServices.SymbolWriter/2.0.0.0__0738eb9f 132ed756/Mono.CompilerServices.SymbolWriter.dll
/usr/lib/mono/gac/Mono.Data.Sqlite/2.0.0.0__0738eb9f132ed756/Mono.Data .Sqlite.dll
/usr/lib/mono/gac/Mono.Data.Sqlite/2.0.0.0__0738eb9f132ed756/Mono.Data .Sqlite.dll.config
/usr/lib/mono/gac/Mono.Data.SqliteClient/2.0.0.0__0738eb9f132ed756/Mon o.Data.SqliteClient.dll
/usr/lib/mono/gac/Mono.Data.SqliteClient/2.0.0.0__0738eb9f132ed756/Mon o.Data.SqliteClient.dll.config
/usr/lib/mono/gac/Mono.Data.SybaseClient/2.0.0.0__0738eb9f132ed756/Mon o.Data.SybaseClient.dll
/usr/lib/mono/gac/Mono.Data.TdsClient/2.0.0.0__0738eb9f132ed756/Mono.D ata.TdsClient.dll
/usr/lib/mono/gac/Mono.Data/2.0.0.0__0738eb9f132ed756/Mono.Data.dll
/usr/lib/mono/gac/Mono.GetOptions/2.0.0.0__0738eb9f132ed756/Mono.GetOp tions.dll
/usr/lib/mono/gac/Mono.Http/2.0.0.0__0738eb9f132ed756/Mono.Http.dll
/usr/lib/mono/gac/Mono.Posix/2.0.0.0__0738eb9f132ed756/Mono.Posix.dll
/usr/lib/mono/gac/Mono.Security.Win32/2.0.0.0__0738eb9f132ed756/Mono.S ecurity.Win32.dll
/usr/lib/mono/gac/OpenSystem.C/2.0.0.0__b77a5c561934e089/OpenSystem.C.dll
/usr/lib/mono/gac/System.Configuration.Install/2.0.0.0__b03f5f7f11d50a 3a/System.Configuration.Install.dll
/usr/lib/mono/gac/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/Syste m.Configuration.dll
/usr/lib/mono/gac/System.Core/3.5.0.0__b77a5c561934e089/System.Core.dll
/usr/lib/mono/gac/System.Data/2.0.0.0__b77a5c561934e089/System.Data.dll
/usr/lib/mono/gac/System.Data/2.0.0.0__b77a5c561934e089/System.Data.dll.config
/usr/lib/mono/gac/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Draw ing.dll
/usr/lib/mono/gac/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Draw ing.dll.config
/usr/lib/mono/gac/System.EnterpriseServices/2.0.0.0__b03f5f7f11d50a3a/ System.EnterpriseServices.dll
/usr/lib/mono/gac/System.Management/2.0.0.0__b03f5f7f11d50a3a/System.M anagement.dll
/usr/lib/mono/gac/System.Security/2.0.0.0__b03f5f7f11d50a3a/System.Sec urity.dll
/usr/lib/mono/gac/System.ServiceProcess/2.0.0.0__b03f5f7f11d50a3a/Syst em.ServiceProcess.dll
/usr/lib/mono/gac/System.Transactions/2.0.0.0__b77a5c561934e089/System .Transactions.dll
/usr/lib/mono/gac/System.Web.Services/2.0.0.0__b03f5f7f11d50a3a/System .Web.Services.dll
/usr/lib/mono/gac/System.Web/2.0.0.0__b03f5f7f11d50a3a/System.Web.dll
/usr/lib/mono/gac/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
/usr/lib/mono/gac/System/2.0.0.0__b77a5c561934e089/System.dll
Thanks, but no, thanks.
I’ve seen less DLLs in a Windows machine.
The 8.3 touch is missing => fill a bug report.
Wow. Talk about getting upset over a file extention. Had he argued patents or embrace-and-extend or performance or bad architecture or whatever I could have seen his arguement (although not necessarily argeed). But disliking the file extention seems silly in the extreme. Especially when it is prbobably trivial to change.
Had he argued patents or embrace-and-extend or performance or bad architecture or whatever…
Yes, it’s a bad architecture! I don’t need an extra layer between the code and the hardware! Should I want Java… er… I already have Java, I don’t need .NET/Mono!
But disliking the file extention seems silly in the extreme. Especially when it is prbobably trivial to change.
Actually, not necessarily. They said that EXE and DLL should be maintained for cross-platform compatibility. But why can’t them be changed *at least* on Debian or Fedora or wherever the package maintainer can choose to filter a little the crap?!
I currently earn my money coding largely in python, so I obviously don’t share your opinion here.
Just because you don’t need it doesn’t make it bad. I am far from an MS fan but I have to admit, without having actually used it too much, that their whole CLR/.NET stuff looks pretty neat from a technical standpoint.
At a guess possibly because most people aren’t bothered by it at all. I’ve heard a lot of different critisisms of mono, and have to admit this is a new one. It hadn’t even crossed my mind.
I understand that on a surface level, .net seems to be MS’s version of Java. However, on a broader level, they are quite different insofar as what their big picture goals are. Java is more of “one language targeting many platforms”, whereas .net is more of “many languages targeting one platform”. It may seem like a subtle difference, but it is not.
Edited 2008-02-20 18:43 UTC
It might sound like a big difference, but in reality I don’t think it is. T
he languages runing on .Net will all use the same class libraries, so programming will be very similar regardless what language you use. Sometimes the languages are even slightly tweaked to fit into the .Net platform, so you migt feel slightly alienated by the .Net version of your programming language.
Besides, it is questionable if many using many languages really is such a big thing. If you use more than one language in a software project, your developer team will have a harder time to understand each others code. It will also be harder to replace one developer with one othe e.g. in case of sickness.
Most software projects doesn’t need tointroduce extra risks, its hard enough as it is to produce something on time and on budget.
Good programmers can program in any language.
I completely agree that in general it would be a bad idea for a single development team to work in multiple languages.
However, the strength of many languages is not about many languages in a one team/project environment. The strength is that different developers on different projects can all target the same platform regardless of the language they are using. A utility library written in Iron Python on one side of the world can be seamlessly used/extended by a developer working in C# on the other side of the worl. The usefulness of this will become even more apparent as people begin to create domain specific languages in .NET and MONO. The bulk of the work could be done with a DSL, then additional fine grained work could be done with another .net language. The same goes for frameworks. nHibernate may be written in C#, but someone programming with VB.NET or Iron Python can use nHibernate seamlessly.
It is true that languages are tweaked to mesh with some .net paradigms, but there is still real strength in having different languages because a person can choose a language that has the best idioms for solving a problem. Granted, C# and VB.net are syntactically close to each other, but if you take a look the upcoming functional .net language called F#, you’ll see that it looks practically nothing like C#, but it will compile down to CLR.
Edited 2008-02-21 18:32 UTC
Not necessarily.
Users could have file associations that link .exe files to Wine, so they can run Windows applications by “clicking them”.
It is obvisouly solvable by preinstalled associations since they can mark .exe as one of the type which need “MIME magic” detection in any case, but messing up existing user created ones is not very nice and in this case totally unnecessary.
Which is why I understand the article author’s frustration that this trivial change hasn’t been taken care of by the compiler or build system.
I have DOS .exe files, Wind32 and Win16 .exe files and Mono .exe files on my Debian box right now.
When I “just click them” the appropriate thing happens and they run. DOS apps open in DOSBox (I could have used dosemu, too, but dosbox was simpler), Windows apps open via Wine and Mono apps are run with mono.
There’s no reason distributions couldn’t set this to happen by default and (this is the important bit!) none of it needs to rely on file extension! It only took me ten minutes to learn enough about binfmts to make this work.
Basically it’s easy, but accurate detection of DOS exes would require knowing magic I don’t care to learn. My answer was to grep .exe files not grabbed by Wine or Mono magic and pass them to a trivial shell script which runs file(1) and decides whether it’s DOS or not. But, if you wanted to spend a few extra minutes you could work out the magic for DOS .exes, too.
This really should all be set up by your distribution; It’s so trivial I find it offensive that they don’t just *do* it.
Edited 2008-02-20 18:10 UTC
What are OS/2 .exe files run with? 🙂
Or you simply look at the system’s magic database. 🙂
What are OS/2 .exe files run with? 🙂
OS/2?
Let’s check…
% which os/2
os/2: Command not found.
No.
Maybe I failed to illustrate the relation I wanted to refer to (from the parent comment): “DOS apps open in DOSBox […] Windows apps open via Wine and Mono apps are run with mono.” Because OS/2 has .exe files too, I was just interested in what they were run with on a Linux system.
If your comment was a bit humoristic (like I intended mine to be), you could have added a “:-)” trigraph. 🙂
(My “:-)” indicates that I do know that “:-)” is of course not a trigraph.)
I’m afraid accurately detecting MS-DOS vs. Windows COFF magic is a bit complicated for me. Like I said, I did not care to learn it.
I think the mentioned file(1) utility does a good job here, so it may be sufficient to rely on it or on the respective database.
% file dos/defrag.exe
defrag.exe: MS-DOS executable (EXE)
% file win/regedit.exe
regedit.exe: MS-DOS executable (EXE), OS/2 or MS Windows
% file os2/tedit.exe
tedit.exe: MS-DOS executable (EXE), OS/2 or MS Windows
Precisely. If you look at file(1)’s magic for matching Windows and DOS .exes correctly, which I did do, it is difficult to follow. I decided to just rely on file(1) in a shell script rather than porting the magic to binfmt properly. But someone who knows what he’s about would have no problem doing so, streamlining the process.
Thanks for exposing you point but, with all due respect, that’s easily the weirdest reason not to like Mono I’ve ever seen. I suppose you delete every .doc, .ppt, .xls you receive too…
Maybe because you said: «It’s just because of software patents? » And it’s the major reason people didn’t reply or they did reply for something else.
Linux users generally try to use open document instead of doc. But MS Office document already is «de facto», which is not true for mono.
But in fact, software patents may be a serious threat to a project. Imagine that your project relies heavily on mono and some of its part falls under patents infringement. The consequences are real.
Time lost to reprogram
Halt in progress
Charge user to pay licenses fee
Court charges
etc.
Additionally, Mono/Novell doesn’t help much for two reasons.
First, by making a deal with Microsoft, they sent a message interpreted like “Yes, there are patent issues, so we signed”. It doesn’t really matter now if it’s true or not, it has already divided the community.
Second, they include stuff that fall outside the ECMA standard (ADO.NET, ASP.NET and Windows.Forms). This is where it gets risky. To include it in mono is dangerous and leads to patents infringement because it promote people to use it. In my opinion, they should strip the package, one being a free, open source mono that fully falls under the ECMA standard and another package for “Microsoft software compatibility” offer at a cost for those who want to port their software.
On mono’s main web page you can read:
«Mono provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix. Sponsored by Novell (http://www.novell.com), the Mono open source project has an active and enthusiastic contributing community and is positioned to become the leading choice for development of Linux applications. »
I think they can only achieve one of these objectives.
If they stick with one package
1. Provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix
OR if they split the package
2. Become the leading choice for development of Linux applications.
I do prefer mono/.net over java. It feels less over-engineer, cleaner, more focus on real world problem, a philosophy of multiple language and binding (java is to focus on the language and swing). But as long as ADO, ASP and W.F will be in mono, I will not use it.
“yum remove mono” work fine.
[admin@one ~]$ rpm -q -a | grep -i gnome | wc -l
49
[admin@one ~]$ rpm -q -a | grep -i mono | wc -l
0 // 0, nada
[admin@one ~]$
As to the facts regarding the inclusion of Mono, refer to
http://gregdek.livejournal.com/4008.html and this
http://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF
Any way, I don’t want mono.
Edit : I trust Red Hat/Fedora for providing only “safe” software. But I don’t want mono.
Edited 2008-02-21 05:54 UTC
Dear XFCE developers,
I love your software and use it everyday, as I have been for ~4 years. In that time, I’ve seen a lot of ‘features’ added, but to be honest I could have lived without all of them*. As payment for these ‘features’, the resources required to run Xfce have grown pretty rapidly, while my hardware has not grown.
I don’t know what “mid-weighted Desktop Environment of choice” means, but to me it just sounds like a WM that can’t decide what it wants to be. Freeze features, bug fix and optimize please! Maybe I’m weird like this, but I think software should get faster and smaller with each release, and we should only be adding features if the current feature set is rock solid and optimized…
*Thunar is really nice, but in 90% of the cases I’m faster using command line then I would be with a filemanager, and back in the day I could just start up konqueror for the exceptions.
Edited 2008-02-20 01:40 UTC
Dear developers:
It’d really be great if the panels could be covered; always on bottom, without setting every window to be on top, every time I log in, and without Devilspie.
Dear Devs.
I love XFCE as my “alternate” desktop for lower end machines.
imho, samba integration into thunar should be a high priority, I know this isn’t a xfce thing, but bar none, this is always the kicking point for me.
I have to disagree. I don’t want to see Thunar being bloated with samba plugin. After samba plugin, there will be users complaining about the lack of ssh plugin, then ftp plugin, then whatever-networked-file-model-plugin…
What I think Thunar needs is a better relationship with fuse, but I think (hmm… hope?) that will come with GIO+ GVFS … I’m even considering the possibility of getting my hands dirty to make thunar deal with GIO, if I ever get the time, as I heard Benny is having little time to work on it.
Isn’t it already the mid-weighted DE of choice?
It always sort of bugs me when people say the new Xfce 4.4 is ‘bloated’. The entire source tarball for all of the default Xfce desktop environment is only 25MB, compared to hundreds of MB’s for KDE and GNOME. While Xfce may not be as slim as dwm, heh, it’s still pretty darn small for a more full-fledged DE.
Other DE’s have more functionality, it dont make them bloated because they are a hundred MB. If Thunar wants samba and all the other modern functionally then it’s a fact the code will be bigger whether you like it or not.
Insightful article, many good points.
I personally spend a lot of time trying to get Linux to run on old hardware. I usually start with an Ubuntu “command line system” install, and build it from there. From personal experience I can say that XFCE is somewhat lighter than Gnome, but not significantly. I believe that a stock Xubuntu system consumes about 100 MB of RAM when initially logged into the desktop. On the other hand, I just finished installing an Ubuntu based system with GDM and a simple Gnome desktop. The entire system uses between 70 and 80 MB of RAM when first logged in. If I were to do a custom stripped install of XFCE I could get it a bit lower than that, but I don’t bother for the following reasons:
1. As the author mentioned, XFCE provides no easy way to configure keyboard layouts and switch them via a keyboard shortcut. I constantly have to switch between several keyboard layouts, and Gnome is the only environment that reliably lets me switch with Ctrl+Shift, which is my habit that I will never be able to change. For the last year or two even KDE has been unable to provide this functionality, although it used to work before that.
2. The last time I extensively used XFCE, I couldn’t make it disallow resizing of maximized windows, which I personally hate. Maybe this has changed.
3. Thunar is not much faster than Nautilus, and I have experienced quite a bit of instability with Thunar.
4. I like to use graphical system configuration tools, and the most powerful tools (BUM runlevel manager, several CUPS utilities, etc) all have Gnome dependencies. By the time I load a Gnome based tool in XFCE, the system is already consuming as much or more RAM than if I were using the tool within the Gnome environment.
That’s my take.
All you have to do is change the keyboard shortcut for changing keyboard layouts. It’s pretty easy if you bother to look.
“All you have to do is change the keyboard shortcut for changing keyboard layouts. It’s pretty easy”
..you could have ended the sentence there.
Reading the various pro/con comments here, I decided to retry XFCE, it has been a couple of years since I used it in earnest.
My mother has installed it on her machine, and my brother put it on his laptop, but he replaced it soon after with KDE.
I will sudo aptitude install xubuntu-desktop in a moment and give it a couple of minutes before I go to work.
I will give it further testing over the next couple of weeks.
Sorry pal, I don’t mean it bad, but what is the point of your post?
The point was this.
I used to have XFCE exclusively on my computers, and my family members got used with it.
I was tempted by the lure of Gnome and KDE.
My family stuck with XFCE for some reason, and I have decided to retry my once favourite DE.
I am using it on Ubuntu 7.10 and the whole thing is way snappier than it was on the default Ubuntu desktop and the Kubuntu desktop.
KDE apps seem to load way quicker than they do under KDE itself and Gnome. I can only assume that is the memory footprint. However, there is 1GB in this machine, so all the DE’s should be fine.
Well….Xfce doesn’t SUCK by default like gnome does.
I’m sorry, but I have spent a couple of house trying to figure how how to get the file manager in Gnome to work properly (not opening a new window every time you open a folder) and I still can’t find any option to fix this. I feel like I’m in windows 3.1.
In Xfce, by default you can right click and access the same menu that you do from the start bar.
Those are two differences that make a big deal to me. Other than that I don’t know what the differences are except for the fact that gnome seems to use at least 8,765 folders for storing it’s configuration.
So when my Gnome stuff crashes and doesn’t work the next time I boot into it I need to “rm -r .gnome .gconf .gconfd .config .20OtherFoldersThatGnomeUses”
Sorry, but Gnome is f’ing horrible. Xfce feels more usable and lighter at the same time.
So, if I want heavyweight I’ll use KDE, if I want lightweight I’ll use Xfce. If I want something in the middle I’ll flip a coin (Xfce or KDE) and avoid using Gnome at all costs.
By the wya, I don’t really care about the whole GTK vs. QT stuff either. I use Xfce and run KDE apps just fine.
I’m kinda drunk right now, so if it seems like I’m flaming I probably am, but I’m also saying what I really feel and if that is flaming I don’t care. Gnome sux!
Edited 2008-02-20 07:41 UTC
I’m sorry, but I have spent a couple of house trying to figure how how to get the file manager in Gnome to work properly (not opening a new window every time you open a folder) and I still can’t find any option to fix this. I feel like I’m in windows 3.1.
No offense, but I believe that they have menus and configuration dialogs in Windows 3.1 also, right? Why would it take hours for you to discover the solution?
1. Nautilus -> Edit -> Preferences -> Behavior -> Always open in browser windows.
2. Close and restart Nautilus.
Only in older versions of GNOME (<2.6) there was a need for the hard way: either run
“gconftool-2 –type bool –set /apps/nautilus/preferences/always_use_browser true”, or:
– open gconf-editor
– go to /apps/nautilus/preferences/
– find “always_use_browser”, and tick the box
– Quit out of gconf-editor, log out, then log back in.
As I said, the hard way is never needed nowadays.
Oh, here too: http://www.fedorafaq.org/#nautilus-spatial
This is the kind of option which, if you do not already know what it does, you would never be able to figure it out. Most people who want this behavior will have no idea how to turn it on and are unlikely to perform google searches sufficient to figure it out. How do you google for “Make nautilus work like a filemanager should” or “not suck”? Users don’t know what spatial means and even I find the word “browser” extremely confusing.
So much for easy to use.
It actually does get a result….
http://www.google.co.uk/search?q=%22make+nautilus+not+suck%…
Hah, that’s pretty funny. I should have pre-googled my hyperbolic examples…
Why would I care about opening things in browser windows, I’m working in the file manager.
Not a very descriptive name for an option.
It should be called “Open Folders in a new Window” or something more along those lines. Those are the complaints that I hear from my users. They do not say that they prefer the file browser over spatial windows. They ask how to keep Linux from opening up all those windows all over their screens.
The Gnome guys had their heads too far up their ivory towers when Spatial Mode was made the default. And the lack of provision for less sophisticated users to change the default mode left a bad taste in my mouth back in the 2.6 days.
I am a Gnome advocate. But the treatment of the spatial issue has never set well with me.
Edited 2008-02-20 20:47 UTC
Try working at a huge compandy where you’re always a couple versions behind…I’m stuck with RHEL 4
“GNOME 2.20 doesn’t take too much memory if you don’t start all kind of crap”
And I, humbly, thought starting all kind of crap is the main purpose of a de/wm.
and in a few years there will be less and less antiquated computers
I disagree. In my closet there are two “antiquated” computers. Both are 100% operational, despite being ten-years old. Celeron 400/128 MB from 1999 and Pentium 200/32 MB from 1997. And none of them can run XFCE-based Xubuntu. Well, 400 can, but runs it barely. And as I mentioned it before – 400 handles XP SP2 much better. So – in my opinion if XFCE ever want to become “number one” it should become lighter. If there is no difference in system requirements between XFCE and GNOME, 99% people will choose GNOME, simply because it is easiest and more productive.
Fortunately there is competition to XFCE in the form of Fluxbox. I tested Fluxbuntu recently and I am sure that if I ever be forced to use Linux on such antiquated system, I will certainly try to learn Fluxbox, not XFCE, even Fluxbox is much more difficult to master.
Such “antiiquated” systems can still be very useful in some settings, e. g. in a testing lab at a psychological facility. There I had a 300 MHz P2 with 128 MB running FreeBSD with XFCE 3. Very stable, could do video playback, Opera and burning of CDs, too. No problem. Why buy some expensive new stuff?
Due to Gtk2, I think XFCE 4 will get almost as “heavy” as Gnome, especially if it increases its functionality for desktop purposes. Just have a look at the XFCE included in FreeSBIE 1.1 and compare it to today’s XFCE.
If you’re searching for lightweight desktop systems, you will need to taylor something by yourself, e. g. XFCE 3, WindowMaker or Enlightenment. As far as I know, there’s no preconfigured distribution that works well on a 300 MHz system, but of course you can built a Linux or BSD based system on your own.
I don’t think this is possible. I admit, it’s already one of the three major players in Linux / UNIX desktopping (wow, I invented a new word!). But if it at least wants to keep this position, it will need to follow KDE and Gnome in terms of hardware requirements so it can keep up with their amount of functionalities. This is neccessary in order to be a modern software product – it needs to take advantage of the new technology that becomes available more and more quickly.
If XFCE wanted to be lightweight, it would miss lots of features, so it could never be “number one”. Users choose a desktop usually with a look at its capabilities. And it would be hard to implement them in a lightweight way. For example, Gtk2 could be abandoned and a much older (!) toolkit could be used, which would be more lightweight, but the implementation of certain functionalities would be more complicated, they would require developers to implement them from scratch instead of using means that modern toolkits already provide.
My conclusion: You cannot be lightweight and “number one”.
This follows my implication. If you can see no speed difference between XFCE and Gnome, you can focus on functionality, and I think Gnome is the better one in the field of desktopping (wow, again!).
On older systems, the combination of selected applications and a versatile and fast window manager will make the difference to just taking a preconfigured and completed desktop environment. You simply come down to use more tools that are simple on their own, e. g. WindowMaker as a window manager, some application that lets place you icons on the desktop (the root window) to represent files, maybe a pager program, and after having configured the dock, you start selecting which software you are going to use: which CD / DVD recording software, which media players (mplayer, xmms), which office product (OpenOffice 1.1.?) – you simply use “smaller” tools which you select from your individual experience instead of relying on a predefined set of applications.
Before any major XFCE improvements can be made quickly, XFCE may need many new developers. If you’re a programmer, and dislike GNOME for some reason or other, but still like GTK2 -based apps, why not join the XFCE developer community and contribute something? Translators etc. are needed too.
XFCE is often considered the 3rd biggest open source desktop environment. Yet the number of active developers is really small when compared to both GNOME or KDE. I read some interview of XFCE developers some months ago, and I was surprised to read how few active developers XFCE actually has. It is a project that would deserve more developers and support.
Fedora gained traction when they included Bluecurve. Gnome gained more traction when they made Clearlooks. Perhaps XFCE should adopt another theme, perhaps Gelatin, but some shade of blue would be accepted better for corporate use, or grays for people who work with graphics.
BTW, dump mono. It’s a horse you can’t steer. Mono will always go where Microsoft wants it to go, just as Java will always go where Sun wants it to go, just as PDF and Flash will always go where Adobe wants it to go.
The article is a little off base.
The fact is that XFce has been a refuge for C++-haters (and other people who for whatever reason do not want to use KDE) who abandoned GNOME shortly after it became clear that the major deficiencies of 2.0 were by design and not temporary. Or, to put it another way, GTK lovers who hate GNOME use XFce.
The challenge is attracting new users who don’t know what they’re missing.
That XFce has been lighter is mostly coincidental–it’s always been pretty easy to build a lighter WM than GNOME or KDE. I hear that GNOME has recently become less bloated, but culturally they still seem indifferent to memory usage.
As for the main thrust of the article and what XFce needs to become truly popular… well that’s easy!
– Don’t be minimalist, fascist usability nuts. Allow for minimalism to be configured as desired. (Don’t be GNOME)
– Put in sane defaults, name and position things logically and don’t make the default UIs so flashy that people feel intimidated. (Don’t be KDE).
– Be featureful and customizable so you work the way *I* want.
All you have to do is *not suck* in a couple of key ways and adopt some “Let’s make it point-and-click-easy!” apps, such as Ubuntu is fond of adding to its environment.
Xfce strives to be as configurable as possible through GUI menus. There are some hidden options in the text configs, but 99.999% of the time they aren’t needed.
Granted some parts still need a little polish, but I think the team has a great vision of where they want to go. It could end up being the Mac of the DE world, everything just works because of methodical, consistent design and vision.
Edited 2008-02-20 22:49 UTC
Well i read the first bullet point over not having Mono due to the file extensions!?! I refuse to read the rest of the article.
I like to run XFCE on Fedora since it runs well and looks great. I always add in a couple of Gnome utilities to make it easier to use. I usually edit the XFCE menu and add in the system monitor, resolution switcher, and other Gnome system utilities. Those GUI applications I miss on plain XFCE. I think Gnome users probably miss them too since they tell me my XFCE desktop feels too stipped down. Mixing and matching parts of DEs is the way to go for a customized feel.
Could you point me to the project pages of those apps you said you miss ? I just might have a bit of free time soon and perhaps I’ll give them a try on a Gtk+ only fashion (I’m not too fond of all that “Gnome app” or “Xfce app” stuff)
I certainly don’t avocate the removal of choice, and people should be free to use whatever GUI they are comfortable with and/or find most effective.
Having said that, I find the constant debates about “bloat” and “lightweight” to be a little irksome. I suspect everyone using either of these phrases has their own interpretation of what they really mean.
The drawback to a nice and efficient DE as opposed to big, bad and bloated Gnome or KDE, is that they generally lack an integrated application framework with a wealth of applications built against it. So even with a nice “lightweight” DE, you still wind up requiring comparable resources to Gnome or KDE once the library dependencies are brought in. I’m not sure where the gain is, particularly on older systems.
Taking it another step, if you took something like KDE and measured the resource usage, you’d most likely find that launching a selection of common applications (file manager, browser, office suite) adds only incrementally to requirements, thanks to the heavy use of shared components and frameworks. Given that KDE 3.5.x and related apps can run on a 128MB Nokia tablet, with little optimization required, or the fact that the KDE team was using a laptop with 224MB to demonstrate KDE4 at SCALE, I’m not sure how much more “lightweight” you can become without dropping functionality. Or simply offloading functionality to outside dependencies.
So I don’t get it when I hear about lightweight alternatives like XFCE or E17 as being better for low powered machines, when they’re ultimately going to draw the same resource requirement when it comes to the apps people generally use. While I understand XFCE does have it’s own app framework, I’m not aware of it being used for any more than a handful of XFCE-oriented utilities. Once you start using browsers, media players or productivity apps, the efficiency of a lightweight environment gets drowned out.
Certainly if there are usability enhancements, or they cater to particular use requirements etc. it would better define them as alternatives, and I suspect in fact that this is why many people prefer them. Nothing wrong with that, I just find the whole “lightweight” vs “bloat” thing misleading, because it seems to focus on a single aspect of the computing environment without considering real-world usage requirements.
I also suspect that the “efficiency” of various DE’s is directly related to the underlying platform and the manner with which the DE is implemented, and not so much to the DE itself.
Anyways, just my 2c. Not trying to deride XFCE, just questioning the rationality of the some of the arguments used in it’s favor. If advocating XFCE, I suspect it would better to have a balanced approach discussing it’s key advantages to the user, rather than implying it will save resources. That will just lead to a new user to wondering why their older system still crawls to a halt when OOo2 or Firefox launches in XFCE, just as it did in Gnome or KDE.
Elsewhere,
I agree with your assessment, for the most part. It does go against the whole “Choice Is Good!” mantra, however.
Mixing apps which make use of different library frameworks comes with a cost. I just saw a *substantial* benefit in the responsiveness of my most heavily loaded XDMCP/NX server. (And sar -W, which was getting slightly worrisome, gave much prettier results.) What did I do? I dumped a frequently used app which wanted to bring in all its own shared libraries, and replaced it, completely, with an equivalent app which used the libraries built into our current DE framework.
If you want to make the best use of your memory… look at the actual apps that are likely to be in use simultaneously… and pick your DE accordingly.
The DSL guys provide impresssive functionality, using just a few megabytes, by paying close attention to what shared memory buys you.
Edited 2008-02-20 21:27 UTC
If by that you mean that choice leads to complexity and sometimes redundancy in the various frameworks and libraries required to support different apps, then I would agree that is a drawback. But I do ultimately believe that the inherent advantages of choice in terms of the the freedom and flexibility to choose your apps to match your needs, requirements and simply preference, outweigh that drawback.
And I’ll bet that DE is either Gnome or KDE, because they’re the only DEs with a wide application base that uses those integrated libraries.
So your decision makes sense, in fact if memory serves, you swapped FF for Epiphany, no?
And hence the reason I find all the arguments rationalizing a light-weight DE against a “richer” DE for older, under-powered hardware to be inherently flawed. They simply lack any sort of a versatile native application pool that would extend the efficiency of that environment by leveraging it’s framework. Everything will ultimately fall back to GTK or Qt anyways, and more often than not will pull in dependencies from Gnome or KDE, to boot.
It’s even worse with apps like FF or OOo2 that are non-native; that’s why I didn’t quite get the rational of all the gushing over gOS for using E17 due to it’s lightweight nature, but still using apps like FF, RhythmBox and OOo2 as part of the application core. Somewhat of a conflict. If you really wanted efficiency, seems to me that a stripped down Gnome DE with epiphany, abiword, gnumeric etc. or KDE with konq and koffice etc. would ultimately be more effective with constrained resources.
Still, people will and should balance effectiveness and requirements. Alternate DE’s like XFCE and E17 offer different advantages in terms of interface and design, and people will still insist on FF regardless of how little memory they have in their systems. That’s the real world.
I just don’t like the whole “lightweight” vs “bloat” thing, I find it misleading. And I still suspect that any differences people perceive in performance with XFCE vs Gnome vs KDE vs anything else, particularly when it comes to application usage, is more dependent on the packaging/config of the DE, and the underlying platform. Likely also why people will argue back and forth about the relative merits, much like I do…
Absolutely agree. That’s also why I brought up the point of KDE 3.5 running on a Nokia internet tablet, since it highlights the difference an optimized platform makes, versus a generic all-purpose distro. I wouldn’t even attempt to install KDE on a 128MB *buntu or openSUSE install, for instance.
But, hey, maybe it would be worth trying on DSL, just for the heck of it…
Well, I have to say that saying XFCE should not use Mono because it generates files with a Windows-related extension is, well, silly.
I was especially surprised to see that this is the first thing mentioned in the article.
In fact, I was expecting the article to mention some thing regarding enabling extension through a scripting mechanism of sorts, and work more on the framework, helping 3rd party developers to develop applications/applets for XFCE.
I just took a look at this guy’s resume on his website and it seems to me this guy works at a Microsoft partner… gee, I wonder why he’d be so anti-Mono?
Also, for being 37 – he’s pretty immature (try reading some of his flame-fest comments against people like Jon Palmieri from Red Hat on the ndesk-dbus blog post)