Slashdot Mirror
Freedesktop.org on KDE/Gnome, New Goals
fdo writes "OSNews has a long and juicy interview with the freedesktop.org developers regarding many aspects of their project, including interoperability between GNOME/KDE, the new X Server, the new Hardware Abstraction Layer library, accessibility, package management and in general, all things desktop."
POSIX rocks. It does in 130 API calls what Win32 does in hundreds more. Its actually one of the most sanely designed "standards" ever implemented. The only decent API Microsoft has ever designed was DirectX, and even that was just mediocre as far as these things go.
A deep unwavering belief is a sure sign you're missing something...
I Agree 100% that X clipboard copy-paste support is terrible and freedesktop should focus on that, instead of eye candy and breaking speed records.
I talk about exchange of non-ASCII data through clipboard (I want to emphasize that as I can see that many OSS types think that clipboard is for text only). I mean copying and pasting images, fragments of images (rectangular an irregular shares), with alpha channel; sound clips; video files; HTML with images copied to local application (not some lazy trick where HTML copied from Mozilla to OpenOffice has all HTML untouched and IMGs are still loaded from the network when you save that file and try to open it at home).
The X contains all necessary infrastructure, as explained here and here.
When you actually try to use the X clipboard for something more that transferring plain text, the results are terrible. Read this, this and this Slashdot comment. Shocking.
This is a problem across most open source projects. Indeed, most programmers know very little about HCI concerns, and it shows. Take, for example, Mozilla's UI blunders -- its numerous "managers" and the famed cipher editor (see also: commentary by Ben Goodger and comments by Blake Ross).
What's needed is not just the involvement of HCI people, but a commitment to accept the methods they bring to the table, and the results they produce. For example, if it's proven that a system like Mozilla's "Edit Ciphers" confuses more than helps, the project's drivers must be willing to listen, and get its code out of the main builds. If not, the HCI people can put as much time as they want into a product, only to burn out.
As often as I see stories like this and the tidal wave of resulting comments (and suggestions) it makes me a little frustrated that there is no on site that we can go to give 'Linux' feedback. I'd love to see the number 1 desktop complaint. We are absolutely brimming with comments (some I agree with, some I do not) and it seems like its all pretty wasted. We just end up rehashing our old opinions and Linux distro's keep doing what it is they think they need to do. Isn't that an unnecessary disconnect?
;-)
Give me a site with polls and commented stories! I think as a group we've at least got some interesting rants and I'd love for some of that feedback to be collected in some type of organised manner. Just imagine the flame wars!
Quack, quack.
I support a fork in Xfree86 because the regime that controls it has dropped the ball. There are many improvements that need to be made that have thusfar been prevented. At the same time I am very afraid that many of the things that were great about X will be lost in all of the commotion.
My greatest fear is that network transpancy will be lost because because everybody just wants to make X render faster on local hardware. Network transparency is what made X really great in the first place; without that, any replacement is totally worthless to me.
The second thing that made traditional X great was that it did not confuse its primary job as a graphical interpreter as being the window manager and middle ware. Each piece should separate, distinct, and intermatchable just like the ISO networking layers. Otherwise jobs will become so intertangled that the stack will no longer be cleanly configurable outside of a heterogenous stack of software. This is much like the situation with GNOME and KDE vs everything else is now -- great within them selves but not operable between them. The X server has a particular job to do and its new features should not try to take over what should be down by other parts of the stack
Don't just throw out the X Resource Database. Before QT and GTK came along breaking all of X tradition, the XRD was a great tool for configuring everything to behave they way that you want it to. Since these rouge widget sets have entered the scene, a vast majority of people have forgotten about what great tools these once were. I am not totally blind that XRD could use some modification but be sure to keep it in the spirit in which these tools were originally created (idea -- maybe using a structure built on an external DB like MySQL wouldn't be out of the question.)
X may be a very old technology like the first poster stated. Like unix tradition many things were very well thought out when it was created. All to often people are throwing away years of hard thought unix design for the latest fad with not even the faintest thought as to what they might be throwing away. No unix does not walk and talk just like the newer fancer interfaces of today -- there are good reasons for this. Some of these new wiper snappers are turning about and starting to do things the old fashion way because they found out that they were not so bad in the first place. Many of the things which at first seem archaic are actually built on much better paradigms then the newest fads. Advances in technology should be made in consideration of what was done before them. They should extend and enhance what has been done. They should not just throw everything out the window calling it old.
There are many things that need to be revamp in a new X server but please keep the good things in along with all of the improvements.
Bzzzt, wrong. Whether something is held in memory or not effects startup time more than responsiveness. The Win32 widget toolkit renders ridiculously fast because:
a) It's primitive and crude. For instance, it has NO layout management at all. Supporting internationalization is a pain in the arse. It uses UTF-16 rather than the somewhat more convenient (but more CPU intensive) UTF-8. Typically Windows desktops are not fully anti-aliased (yes yes, cleartype, not on by default) and when it is, Windows has better HW accel anyway.
b) Microsoft have a lot of people working on performance issues, and entire teams dedicated to optimization. We don't.
Only one GUI library would need to be loaded and everyone could use their favorite. It would certainly help for Windows ports as well. Thoughts?
No offence, but I think that's a bad idea. The thing to understand here is that wxWindows is a toolkit abstraction, and when you abstract things the differences between the underlying implementations are at the same time blurred but they also leak out. A wxWindows app doesn't feel integrated anywhere, and it struggles to hide the underlying differences between the real widget toolkits. Subtle details like focus semantics can break and cause wierd bugs in applications.
When you abstract something, you lose something. Unfortunately the quirks of history have meant we have lots of widget toolkits sitting on our desktop today. The real killer issues from this are integration, consistency and interoperability. Memory overhead is certainly not a big issue compared to these lot - I think you should perhaps do some profiling of applications and then you'd see that having 3/4 toolkits loaded at once is not the real problem, it's the performance quirks of those toolkits that are the issue.