I would love for someone to make Linux into something the average computer user would be comfortable using, but I just don't think it'll ever happen.
Why the pessimism? Anything more substantial than, "look at it today, it'll never get there" (people said the same about the server) or "open source can't make usable software" (seems to be proven not true lately)?
Sounds silly, but when all you've ever known is the Windows GUI, the idea of editing a text file to make things run sounds scary, no, make that IS scary.
I've long wished that Apache had a credible GUI for Windows, but so far have yet to see one.
Well, it's publically documented and no patent concerns (or rather, no patents are being excised on it). There are multiple implementations of both flash renderers and flash authoring environments. It's not that proprietary.
expensive-to-author format
swish is pretty cheap, either $40 for the full thing or $20 for the "lite" version. And of course, nothing stops anybody from producing an open source version of Macromedia Flash.
The plugin's a pain in the ass even on Windows or Macintosh- you're always having to upgrade it, or you've got the wrong particular "flavor".
But the vast majority of the world uses IE, in which upgrades and installs are pretty seamless. Sure, it's a pain in the ass on Linux, or in Mozilla.
On the general "I hate flash, too many adverts use it and people always use it for site navigation" thing, I think the same argument could be applied to say animated GIFs, or images in general, or hell rich text - I can hear the naysayers being presented with the web for the first time saying "Rich text with images is rarely useful, it normally just gets in the way of the content. Just give me plain text and I'll be happy".
Re:Solution is a more flexible "finder" api
on
A Better Finder?
·
· Score: 1
X/XFree is a graphics abstraction layer, not a component embedding model. They do completely different things.
Low end/high end divide
on
A Better Finder?
·
· Score: 3, Informative
It's an interesting article, although most of the points related to OO (spatial) vs navigational browsing have already been hashed out on the Nautilus list, which I read sometimes - I think if you want a view of both sides of the argument, that might be a good place to go now, especially as the issue isn't as clear cut as this article makes it out to be.
In particular, the navigational model has a few things going for it. Firstly, people have already been forced into it by the spread of the web. One of the most, if not THE most popular apps in usage today is the web browser. The web is clearly a navigational model, the browser is a viewport onto a small segment of the whole, with links between them. Clicking a link does not open a new window, and there is no enforced relationship between the website and the window. The concept of the "path" is forced onto the user via URLs, and the current path is constantly shown in a prominant place.
In the OO model of course, you are only allowed to have one window showing a folder at any point - opening it from somewhere else simply raises the window to the top.
Nonetheless, I have yet to find people who consider web browsers to be seriously confusing. The "spatial" model ties in with the physical world, but we deal just as much with the navigational model in the the real world as well, think TV/radio channels for instance.
I think he also misses the fact that mental modelling is not an absolute - it can and must fit in with other considerations. The OO model may well be more spatial and perhaps more natural, but it has other problems as well, like the fact that you can easily end up with many small windows open at once. In the absence of any equivalent to the taskbar, such a thing always irritated me in MacOS 9. When you do have a taskbar of course, OO browsing simply fills it up very quickly making it useless.
Not even virtual desktops can solve that problem. Virtual desktops of course have questionable usability in the first place, but in fact I've NEVER met anybody who disliked them, not even really green newbies. Virtual desktops make OO browsing even harder, because you can only have 1 window open at once for any given folder, if you open one, windows start jumping around from different desktops (unless you want to lock them together or place the window on multiple desktops at once - yuck!).
As an example of where breaking reality might be faster than sticking religiously to an OO model, imagine for a moment you have X-Men style super powers. You want to retrieve a piece of paper, that is in a box, in drawer, in a cupboard. Which is faster, opening the cupboard, pulling out the drawer, taking out and opening the box, getting the piece of paper and then putting it all away again, or using X-Ray vision to find the paper with the power of your mind, then kinetically pull it through the walls of the cupboard to sit in front of you?
A poor analogy, I'll admit, but what usability reviews often miss is that in return for some breakage of the mental model, you can get large increases in efficiency. Virtual desktops might well be unnatural, but once you get used to them you don't want to go back, no matter what your skill level is - perhaps people who'd never seen them before would get confused, but for everybody else the usability is enhanced, not decreased.
I guess I should qualify that this doesn't mean I'm in the "lots of crack preferences" camp a la Mosfet and the gang, I mean each feature should be weighed carefully for its cost in usability loss to newbies vs the increase in usability once you have understood the system.
Re:Solution is a more flexible "finder" api
on
A Better Finder?
·
· Score: 1
Perhaps OSX can take a page from the X world and to think of the interface more as a component and less as an integral part of the OS (skin the OS if you will).
I think you're a bit confused, X has nothing to do with component embedding (or very little). Windows for instance is the master of this, has been for years, no X there. I think I understand what you're talking about though.
If the powers that be at Apple sat down and thought of a way to provide hooks into the gui (as well as the most important thing, to make sure that functionality is separated from the gui), then doing these types of things could be much simpler as well as providing a viable market for alternative interfaces.
I would guess the reason Apple don't do this is because:
a) They don't want people to use alternative interfaces (branding). They will anyway, that's just the nature of users, but Apple don't want to go out of their way to make it easy for people.
b) Component embedding using something like Bonobo/ActiveX/KParts is added overhead, and as you may have noticed, people aren't too impressed with the speed of MacOS anyway. That doesn't mean component models HAVE to be slow, they don't, but they add extra complexity for little user visible gain. One of the reasons Nautilus and Konqueror use the navigational model is AFAIK because window creation times are too high, partly because of their use of component tech. ROX on the other hand, which does not, opens new windows nearly instantly, but sacrifices some flexibility in order to do so (imo).
c) MacOS X isn't too hot on component technologies. Apple used to have OpenDoc which was the closest equivalent to ActiveX/Bonobo/KParts, but they dropped it. I think there's something called distributed objects, inherited from NeXTStep, but as you might expect that's rather tied into Cocoa as far as I know, and I think it only does object remoting rather than GUI merging, structured storage and all the other gizmos B/Ax/KP bring to the party.
Basically, I wouldn't expect to see that happen in MacOS X any time soon. Although a cool demonstration of the platforms component tech, the true value of those features are debatable anyway, see the recent AbiWord in Nautilus thread for a discussion of the pros/cons of being able to treat the filing system as a set of embeddable components.
Yes, for experienced users. The command line is deadly for anybody else though - even for people with lots of experience it's all too easy to accidentally delete files, overwrite them with junk because you're going so fast the slightest mental slip and you're dead.
GUIs like the Finder are slower for most operations, but they give users a safety net that is usually appreciated.
Re:I don't agree with the article
on
A Better Finder?
·
· Score: 4, Insightful
Still, sometimes it seems like OS X is held to a far higher standard with regard to UI than other products. I mean, correct me if I'm wrong, but I don't think Linux (any flavor) or Windows (any flavor) has recieved nearly the same amount of scrutiny and criticism with regard to UI.
I can't speak for Windows but Linux does for sure, in the past 12 months I must have seen more "usability reviews" of various parts of the Linux desktop than I've had hot meals. Most of them are worthless, but in general the noise over usability has had an effect, go see the effort and elbow grease being put into GNOME (especially) and KDE now for instance. The Nautilus team have been hard at work doing what is basically just polish and optimization (just as well, it really needed it!) lately for instance.
Why is that? Is it simply because Apple brags about it so much?
Well, when you look at the Mac value proposition, basically it boils down to their user interface. They can't sell on price or speed or number of apps, nor do they have the "nobody got fired for buying Foo" mentality on their side. Their no 1 selling point is that Macs are supposedly easier and more efficient to work with.
As such, people talk about that, it's the one thing that makes Apple unique. Personally, although they still do better than most companies, I think their reputation for UI expertise has taken a bit of a battering with the Jobsian era - go read some reviews of MacOS X from former OS 9 users, who point out some of the more laughable usability errors in OS X. These days, I think they're trading a lot on reputation, people think "Macs are easy!" and because ease of use is so subjective, they rarely get challenged on that point. That's what makes articles like this one so fascinating.
Re:I may sound really stupid, but....
on
A Better Finder?
·
· Score: 3, Informative
The finder, for those who might not have used a Mac (ie quite a lot of people I should imagine), works something like this:
Basically, it is like Explorer in Windows, or Nautilus in GNOME. It runs all the time, you cannot quit it. I think it draws the desktop. The finders default mode is column based, this is rather different to traditional file managers. Each folder "level" in the heirarchy gets a new column, starting from left to right. Clicking a folder shows a new column with the contents and a vertical scrollbar on the right. You click and scroll your way through the hard disk, rather than interacting with a tree, like in Explorer/Konqueror.
This is quite a bit different from the one in MacOS 9. My knowledge of that OS is a little rusty these days, but I think it was traditionally what is called an "object oriented" file browser, see ROX on Linux for an example. Win95 took this approach by default (in the very first releases). In this model, each window shows one folder, clicking a folder opens a new window. There is no concept of a "file manager" as such, it's an integral part of the desktop. There is no concept of pathing - although MacOS 9 did indeed have a path separator, virtually nobody knows what it is (a : character).
Normally OO browsers have a spring loaded folders implementation to make the large number of windows that can be generated with this approach more manageable, unfortunately this technique is patented by Apple which one reason why Nautilus hasn't moved to it, the GNOME guys have been thinking of possible ways around this patent, as well as other browsing metaphors.
Anyway, I digress. Basically, IIRC people have several issues with the OS X Finder beyond its design, namely that it's slow (perhaps why it doesn't use lots of new windows??) and not multithreaded, so a blocking connection or blocked device will freeze it. Window resizes are also very slow, but that's more an issue with OS X in general.
It also pretty much abandoned the OO model in favour of a navigational one, the usability merits of which are hotly debated. You can still have OO style windows of course if you want them, but I don't think that's what new users see. The first releases didn't even have spring loaded folders, pretty essential for the OO model.
Other than that, I think the Finder is really quite a nice program, though I never used it heavily. The column system is OK, it's not fantastic or anything but gets the job done. The tree widget it uses is incredibly feeble, so it's just as well. The fact that you can drag any object into the toolbars is also a nice touch, think iconic bookmarks.
You know, slashdot has very specific reasons for not caching web pages, ranging from bandwidth usage to the fact that a page might update in the middle of a slashdotting.
Shifting the bandwidth usage onto Sourceforge, in particular, seems a bit dumb - they are run by the same company. If Slashdot can't financially justify caching, what makes you think SourceForge can.
Oh, and I'd note that ars technica is not one that's going to get slashdotted anytime soon:)
http://www.konqueror.org http://www.apple.com/safari Seriously. Do you work for Opera Software or something? Your other post was also a plug for Opera. Opera is proprietary software, which I'll never use since I value my freedom.
So why did you include a link to Safari, which is likewise proprietary software?
Heh, I seem to recall reading that the Windows 2000 bug database was "full up", so every time they wanted to file a new bug, they just throw away an old one.
Is that the right fortune 500, or is this bug tracker just popular with the big corps?
3) Power. RPM, by itself, is pretty dumb. RPM and RedHat are the reasons why people like to bitch about the complexity of software installation on Linux. In RedHat, if you want to install a program, you have to manually recurse the dependency tree of the packages. In Portage, you just request the installation of one package, and everything else is handled automatically.
Look, I'm as game for a good packaging flamewar as much as the next guy, but be fair. If you subscribe to RHN you can use up2date to do what emerge does (but for binaries of course). You're also assuming that every piece of software in the world is available via portage, which clearly isn't the case.
Our packaging problems go a lot deeper than RPM, believe me. You don't know the half of it:(
IMHO, something I've long thought about regarding LSB is that there should be a Package Management specification. Much like the way IEEE defines specifications for things, ANSI, ISO, and so on.
Well, there is. It's just not very useful, because it says you can only have one dependancy. D'oh.
Wishful thinking I guess.
Perhaps. But you're not the only one thinking wishfully about this. The main packaging dudes from Redhat, Debian and yes, even Gentoo, are talking about it.
The list has gone a bit dead lately. Alain seems to have disappeared:( Hopefully it'll pick up again soon. It'd be nice to have standards for packaging metadata (which solves a lot of our current woes with packaging).
Actually compressing things gives a speed boost, because the bottleneck is getting the data off the CD, so reducing the transfer off the disk is a good idea, and modern computers stomp all over gzip.
The program they use to do that is called cloop (compressed loopback). It's cute:)
Yes man, yes! I was going to write something about that, but you beat me to it. It doesn't compensate for anything, it just makes the writing feel odd and jerky. Using "his" or "them" for a gender neutral pronoun is widely accepted practice, if people concentrated more on the message and not the form, we wouldn't have to play games like this.
Well yes, but emacs has been doing that for years. It's all defined in Lisp, so you can extend, rewrite, and customise virtually everything. I think it's more powerful than the Eclipse plugin method, certainly lighter weight.
Unfortunately emacs doesn't seem to have power IDE features these days. eTags just isn't as good as drop down code completion for instance.
I still prefer xemacs though, simply because it fills the screen with what you're actually working on, rather than cramping it into a tiny window and surrounding it with code browsers and stuff.
Of course, that's all well and good, but last time I tried to use Eclipse, you couldn't even edit the default keybindings.
I really like the idea of a decent IDE for Linux, but at the moment I'm torn between XEmacs and Eclipse, and XEmacs wins, simply because I spend most of the time editing text, not browsing object trees or whatever. What I'd love to see is for Eclipse to be able to embed the emacs editing engine. I don't think it's going to happen though.
The problem is that GTK can't depend on GConf, so it reads its font configuration from a text file. When you're running GNOME though, users and developers want to take advantage of the general coolness of gconf, so they communicate via a hacked up X protocol called XSETTINGS, hence the fact that gconf controls the GTK font size (and KDE could do so as well if it wanted to).
That problem won't go away until there's a neutral, acceptable to all configuration system that GTK can depend on.
One issue I think a lot of posters here are missing is that fontconfig and the rest are already deployed and working, whereas STSF isn't even completely implemented yet.
That means STSF doesn't have to be just a little bit better, it has to be VASTLY better to justify ripping out a brand new font architecture. Nobody is convinced it is.
Other people seem to be of the belief that having 2 competing font systems is ok. It's not - this is two competing interfaces, NOT implementations. Well, STSF can apparently emulate Xft, but you don't get any advantages that way, so what's the point?
So STSF had better be pretty amazing to justify it. Sure, Sun can go and use it if they like, but it'd require major b0rkage of GTK, and those patches would probably not make it back into the trunk, so they'd have basically forked GTK. Not good.
I think most people aren't sure what STSF does.... it doesn't render fonts, it isn't a collection of fonts, so it'll make little difference to how the desktop looks. It is more comparable to Pango, as it performs internationlized text rendering and reflow/layout.
Slashdot Mirror
Why the pessimism? Anything more substantial than, "look at it today, it'll never get there" (people said the same about the server) or "open source can't make usable software" (seems to be proven not true lately)?
Sounds silly, but when all you've ever known is the Windows GUI, the idea of editing a text file to make things run sounds scary, no, make that IS scary.
I've long wished that Apache had a credible GUI for Windows, but so far have yet to see one.
Well, it's publically documented and no patent concerns (or rather, no patents are being excised on it). There are multiple implementations of both flash renderers and flash authoring environments. It's not that proprietary.
expensive-to-author format
swish is pretty cheap, either $40 for the full thing or $20 for the "lite" version. And of course, nothing stops anybody from producing an open source version of Macromedia Flash.
The plugin's a pain in the ass even on Windows or Macintosh- you're always having to upgrade it, or you've got the wrong particular "flavor".
But the vast majority of the world uses IE, in which upgrades and installs are pretty seamless. Sure, it's a pain in the ass on Linux, or in Mozilla.
On the general "I hate flash, too many adverts use it and people always use it for site navigation" thing, I think the same argument could be applied to say animated GIFs, or images in general, or hell rich text - I can hear the naysayers being presented with the web for the first time saying "Rich text with images is rarely useful, it normally just gets in the way of the content. Just give me plain text and I'll be happy".
X/XFree is a graphics abstraction layer, not a component embedding model. They do completely different things.
In particular, the navigational model has a few things going for it. Firstly, people have already been forced into it by the spread of the web. One of the most, if not THE most popular apps in usage today is the web browser. The web is clearly a navigational model, the browser is a viewport onto a small segment of the whole, with links between them. Clicking a link does not open a new window, and there is no enforced relationship between the website and the window. The concept of the "path" is forced onto the user via URLs, and the current path is constantly shown in a prominant place.
In the OO model of course, you are only allowed to have one window showing a folder at any point - opening it from somewhere else simply raises the window to the top.
Nonetheless, I have yet to find people who consider web browsers to be seriously confusing. The "spatial" model ties in with the physical world, but we deal just as much with the navigational model in the the real world as well, think TV/radio channels for instance.
I think he also misses the fact that mental modelling is not an absolute - it can and must fit in with other considerations. The OO model may well be more spatial and perhaps more natural, but it has other problems as well, like the fact that you can easily end up with many small windows open at once. In the absence of any equivalent to the taskbar, such a thing always irritated me in MacOS 9. When you do have a taskbar of course, OO browsing simply fills it up very quickly making it useless.
Not even virtual desktops can solve that problem. Virtual desktops of course have questionable usability in the first place, but in fact I've NEVER met anybody who disliked them, not even really green newbies. Virtual desktops make OO browsing even harder, because you can only have 1 window open at once for any given folder, if you open one, windows start jumping around from different desktops (unless you want to lock them together or place the window on multiple desktops at once - yuck!).
As an example of where breaking reality might be faster than sticking religiously to an OO model, imagine for a moment you have X-Men style super powers. You want to retrieve a piece of paper, that is in a box, in drawer, in a cupboard. Which is faster, opening the cupboard, pulling out the drawer, taking out and opening the box, getting the piece of paper and then putting it all away again, or using X-Ray vision to find the paper with the power of your mind, then kinetically pull it through the walls of the cupboard to sit in front of you?
A poor analogy, I'll admit, but what usability reviews often miss is that in return for some breakage of the mental model, you can get large increases in efficiency. Virtual desktops might well be unnatural, but once you get used to them you don't want to go back, no matter what your skill level is - perhaps people who'd never seen them before would get confused, but for everybody else the usability is enhanced, not decreased.
I guess I should qualify that this doesn't mean I'm in the "lots of crack preferences" camp a la Mosfet and the gang, I mean each feature should be weighed carefully for its cost in usability loss to newbies vs the increase in usability once you have understood the system.
I think you're a bit confused, X has nothing to do with component embedding (or very little). Windows for instance is the master of this, has been for years, no X there. I think I understand what you're talking about though.
I would guess the reason Apple don't do this is because:
a) They don't want people to use alternative interfaces (branding). They will anyway, that's just the nature of users, but Apple don't want to go out of their way to make it easy for people.
b) Component embedding using something like Bonobo/ActiveX/KParts is added overhead, and as you may have noticed, people aren't too impressed with the speed of MacOS anyway. That doesn't mean component models HAVE to be slow, they don't, but they add extra complexity for little user visible gain. One of the reasons Nautilus and Konqueror use the navigational model is AFAIK because window creation times are too high, partly because of their use of component tech. ROX on the other hand, which does not, opens new windows nearly instantly, but sacrifices some flexibility in order to do so (imo).
c) MacOS X isn't too hot on component technologies. Apple used to have OpenDoc which was the closest equivalent to ActiveX/Bonobo/KParts, but they dropped it. I think there's something called distributed objects, inherited from NeXTStep, but as you might expect that's rather tied into Cocoa as far as I know, and I think it only does object remoting rather than GUI merging, structured storage and all the other gizmos B/Ax/KP bring to the party.
Basically, I wouldn't expect to see that happen in MacOS X any time soon. Although a cool demonstration of the platforms component tech, the true value of those features are debatable anyway, see the recent AbiWord in Nautilus thread for a discussion of the pros/cons of being able to treat the filing system as a set of embeddable components.
GUIs like the Finder are slower for most operations, but they give users a safety net that is usually appreciated.
I can't speak for Windows but Linux does for sure, in the past 12 months I must have seen more "usability reviews" of various parts of the Linux desktop than I've had hot meals. Most of them are worthless, but in general the noise over usability has had an effect, go see the effort and elbow grease being put into GNOME (especially) and KDE now for instance. The Nautilus team have been hard at work doing what is basically just polish and optimization (just as well, it really needed it!) lately for instance.
Well, when you look at the Mac value proposition, basically it boils down to their user interface. They can't sell on price or speed or number of apps, nor do they have the "nobody got fired for buying Foo" mentality on their side. Their no 1 selling point is that Macs are supposedly easier and more efficient to work with.
As such, people talk about that, it's the one thing that makes Apple unique. Personally, although they still do better than most companies, I think their reputation for UI expertise has taken a bit of a battering with the Jobsian era - go read some reviews of MacOS X from former OS 9 users, who point out some of the more laughable usability errors in OS X. These days, I think they're trading a lot on reputation, people think "Macs are easy!" and because ease of use is so subjective, they rarely get challenged on that point. That's what makes articles like this one so fascinating.
Basically, it is like Explorer in Windows, or Nautilus in GNOME. It runs all the time, you cannot quit it. I think it draws the desktop. The finders default mode is column based, this is rather different to traditional file managers. Each folder "level" in the heirarchy gets a new column, starting from left to right. Clicking a folder shows a new column with the contents and a vertical scrollbar on the right. You click and scroll your way through the hard disk, rather than interacting with a tree, like in Explorer/Konqueror.
This is quite a bit different from the one in MacOS 9. My knowledge of that OS is a little rusty these days, but I think it was traditionally what is called an "object oriented" file browser, see ROX on Linux for an example. Win95 took this approach by default (in the very first releases). In this model, each window shows one folder, clicking a folder opens a new window. There is no concept of a "file manager" as such, it's an integral part of the desktop. There is no concept of pathing - although MacOS 9 did indeed have a path separator, virtually nobody knows what it is (a : character).
Normally OO browsers have a spring loaded folders implementation to make the large number of windows that can be generated with this approach more manageable, unfortunately this technique is patented by Apple which one reason why Nautilus hasn't moved to it, the GNOME guys have been thinking of possible ways around this patent, as well as other browsing metaphors.
Anyway, I digress. Basically, IIRC people have several issues with the OS X Finder beyond its design, namely that it's slow (perhaps why it doesn't use lots of new windows??) and not multithreaded, so a blocking connection or blocked device will freeze it. Window resizes are also very slow, but that's more an issue with OS X in general.
It also pretty much abandoned the OO model in favour of a navigational one, the usability merits of which are hotly debated. You can still have OO style windows of course if you want them, but I don't think that's what new users see. The first releases didn't even have spring loaded folders, pretty essential for the OO model.
Other than that, I think the Finder is really quite a nice program, though I never used it heavily. The column system is OK, it's not fantastic or anything but gets the job done. The tree widget it uses is incredibly feeble, so it's just as well. The fact that you can drag any object into the toolbars is also a nice touch, think iconic bookmarks.
You know, slashdot has very specific reasons for not caching web pages, ranging from bandwidth usage to the fact that a page might update in the middle of a slashdotting.
Shifting the bandwidth usage onto Sourceforge, in particular, seems a bit dumb - they are run by the same company. If Slashdot can't financially justify caching, what makes you think SourceForge can.
Oh, and I'd note that ars technica is not one that's going to get slashdotted anytime soon :)
Lots of things :/ autopackage is a small part of the solution, we are involved in other things as well.
So why did you include a link to Safari, which is likewise proprietary software?
Is that the right fortune 500, or is this bug tracker just popular with the big corps?
Look, I'm as game for a good packaging flamewar as much as the next guy, but be fair. If you subscribe to RHN you can use up2date to do what emerge does (but for binaries of course). You're also assuming that every piece of software in the world is available via portage, which clearly isn't the case.
Our packaging problems go a lot deeper than RPM, believe me. You don't know the half of it :(
Well, there is. It's just not very useful, because it says you can only have one dependancy. D'oh.
Wishful thinking I guess.
Perhaps. But you're not the only one thinking wishfully about this. The main packaging dudes from Redhat, Debian and yes, even Gentoo, are talking about it.
The list has gone a bit dead lately. Alain seems to have disappeared :( Hopefully it'll pick up again soon. It'd be nice to have standards for packaging metadata (which solves a lot of our current woes with packaging).
The program they use to do that is called cloop (compressed loopback). It's cute :)
I did, about a month or two ago. They said they had no plans at this time. (sigh)
Yes man, yes! I was going to write something about that, but you beat me to it. It doesn't compensate for anything, it just makes the writing feel odd and jerky. Using "his" or "them" for a gender neutral pronoun is widely accepted practice, if people concentrated more on the message and not the form, we wouldn't have to play games like this.
Unfortunately emacs doesn't seem to have power IDE features these days. eTags just isn't as good as drop down code completion for instance.
I still prefer xemacs though, simply because it fills the screen with what you're actually working on, rather than cramping it into a tiny window and surrounding it with code browsers and stuff.
I really like the idea of a decent IDE for Linux, but at the moment I'm torn between XEmacs and Eclipse, and XEmacs wins, simply because I spend most of the time editing text, not browsing object trees or whatever. What I'd love to see is for Eclipse to be able to embed the emacs editing engine. I don't think it's going to happen though.
You're confusing user interface with machine interface. The same word is used to describe two different concepts, confusing I agree.
That problem won't go away until there's a neutral, acceptable to all configuration system that GTK can depend on.
That means STSF doesn't have to be just a little bit better, it has to be VASTLY better to justify ripping out a brand new font architecture. Nobody is convinced it is.
Other people seem to be of the belief that having 2 competing font systems is ok. It's not - this is two competing interfaces, NOT implementations. Well, STSF can apparently emulate Xft, but you don't get any advantages that way, so what's the point?
So STSF had better be pretty amazing to justify it. Sure, Sun can go and use it if they like, but it'd require major b0rkage of GTK, and those patches would probably not make it back into the trunk, so they'd have basically forked GTK. Not good.
I think most people aren't sure what STSF does.... it doesn't render fonts, it isn't a collection of fonts, so it'll make little difference to how the desktop looks. It is more comparable to Pango, as it performs internationlized text rendering and reflow/layout.
Not that it'd matter performance wise anyway. Bonobo/ORBit is many times faster than DCOP.