Freedesktop.org on KDE/Gnome, New Goals 340
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."
GNOME _still_ isn't integrated (Score:3, Interesting)
Most of a 'desktop environment' important details are underneath, not the pretty GUI. ( though the importance of having a CONSISTANT GUI shouldn't be dismissed. )
They should have had mechanisms in place from DAY ONE for shared information and intercommunications.. not something that was seemingly tacked-on later.. Integration of the desktop must be done on the fonctionnality level, not on the software level.
KDE is much closer to this, as they PLANNED ahead, and didn't just wing-it since it was 'pretty'. See here [kdedevelopers.org] for example.
The problem with GNOME is that they use GTK+ object-oriented style, but don't borrow the most important aspect of (early, anyhow) GTK... cleanliness and simplicity! Without that, the GTK-inspired GNOME macro, er object, system is COMPLETELY INCOHERENT and to put it completely blunt: SHIT.
Not to mention the fact that the numerous API libraries do not work well together and stability will _never_ be achieved since one package will _always_ depend on something that is considered beta or unstable.
Don't even get me started on the various ad-hoc configuration mechanisms and the nightmare that is CORBA and Bonobo.
Sorry to sound harsh, but it was a complaint of mine from day one of GNOME, it just wasn't professional.. They worried more about a smelly foot in the menu then making it solid and consistent.. Now they are finding out the price to be paid if they want to stick around and be more then a cute plaything...
But I'm not really sure what to think of it, honestly. That they'd have to involve money to have things that SHOULD be simple get done.
Re:one new goal (Score:5, Interesting)
UI environment becoming interdependent. (Score:3, Interesting)
My predication is that we will be spending the next 15 years reconciling this fundamental misstep.
Re:So I can copy and paste now? (Score:5, Interesting)
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 [jwz.org] and here [tronche.com].
When you actually try to use the X clipboard for something more that transferring plain text, the results are terrible. Read this [slashdot.org], this [slashdot.org] and this [slashdot.org] Slashdot comment. Shocking.
Re:Don't forget the users! (Score:5, Interesting)
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.
Plead (rant?) for (Score:5, Interesting)
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!
Please, please, please don't loose X's best aspect (Score:5, Interesting)
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.
Re:GUI toolkit libraries (Score:5, Interesting)
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.
Re:GUI toolkit libraries (Score:2, Interesting)
Qt won't adopt GTK+ because Qt developers are in love with the well-designed elegance/ease of development in the Qt toolkit, and they see all other toolkits as inferior from a development perspective (and I have to say they have a point). GTK+ programmers won't touch Qt because the Qt libraries are GPL'd instead of LGPL'd. And frankly, they're right too. Development libraries should not be GPL'd, and this should have been settled long ago.
A full Linux "desktop merge" won't happen. Give it up. Linux is about choice, and as long as that's true, there will be multiple toolkits. The best you can hope for is well-documented and well-implemented methods of interoperability between the toolkits.
That said, even with major interoperability improvements, you still can't get past the fact that Qt and GTK2 apps will look wildly different from one another. Even with look-alike theming, Qt uses "natural language" button order (Yes or No) and GTK2 uses "flowchart" button order (No or Yes). The divergence is huge compared to the toolkits on other platforms, and most users won't stand for having their apps behave so differently on something like button order. So basically Qt and GTK2 are likely to duplicate each other's efforts into the foreseeable future, just to give users a good, consistent UI. That isn't necessarily a bad thing, but it's definitely the only option.
Re:one new goal (Score:3, Interesting)
What does clone() do? It creates a new thread, which is not obvious at all.
connect() connects a socket, which isn't too bad a name. But the problem is the name gives no indication of what you're connecting. You'd only know you're connecting a socket and not say a pipe by looking it up.
This becomes a problem when you're trying to learn how to do something new. You can't easily figure out what functions you need to do a task.
Things would be much simplier with function names like SocketCreate, SocketConnect, etc. You would at least be able to search for function names beginning with Socket to find what you need. Win32 at least comes close to this goal with names like ReadFile, WriteFile, etc. Too bad the help viewer in Visual Studio doesn't support regexp searches on the index.
Re:So I can copy and paste now? (Score:3, Interesting)
While I agree that the copy-paste support of most X application is terrible, I think it is important to state that it is the applications that are lacking, not X. As you write, the architecture is there for copy and paste, also for copying things other than text, it is just that most (all?) applications do not support it.
The reason is simple: if X lacked the support for this, then we would have a cache22 problem trying to get it implemented both in applications and X. However, since X does have the necessary infrastructure - even for "negotiating" when copying between applications so it can fall back on text - all that is needed is for the application developers to get their acts together.
If I was in charge of the Peren's "UserLinux" distribution, I would try to institute a rule that I wouldn't include any desktop application until it supported copy-paste decently and correctly...
Re:Developers get to play too (Score:3, Interesting)
The big fast 3D-accelerated cards tend to come with a lot of RAM on-board. This could be used by a tech-savvy developer to justify a new graphics card to a not-so-savvy manager, and incidentally a new monitor too, a digital flatscreen one, to plug into the new graphics card, so I can still have 2 screens... And it wouldn't suck dead bunnies through thin straws when playing an FPS along with everyone else...
It's about greed, lust for the latest toy, and justification or lack thereof. It's not about what is sufficient, what will do, or the quality of the graphics output... You're obviously very pure of spirit... (this is not an insult! Thought I'd point that out since we seem to operate on different wavelengths!)
Simon.
Re:We're not just talking Windows (Score:3, Interesting)
And do you know who made Word a decent-looking program?
Apple
The first GUI version of Microsoft Word was developed according to Macintosh user interface guidelines. After seeing how well that worked, Microsoft ported it to the IBM-compatible platform.
Re:one new goal (Score:3, Interesting)
- DirectDraw is more complicated than SDL for simple things. Let's go through how to make a double-buffered surface that you can directly draw to.
In SDL:
- Call the SDL init function
- Set the video mode
- Lock the primary surface and draw!
In DirectDraw:
- Create the DirectDraw COM object
- Set the cooperative level
- Set the video mode
- Create a primary surface
- Create a secondary surface attached to the primary surface
- Now lock the primary surface and draw...
Not only does the DirectDraw model have twice as many steps, but each DirectDraw call has many more parameters (many of them optional) and has the annoying Win32-ism of requiring you to fill out large structures full of extra parameters to pass to each call. All in all, the code for the DirectDraw version is four or five times longer. Some of this stuff isn't just boiler-plate. In particular, many calls require five or ten lines of setup code before hand to fill out structures that are passed as parameters. Of course, DirectX is very powerful. For example, you can render Direct3D graphics to arbitrary DirectDraw surfaces (like p-buffers in GLX). Last time I used SDL, you couldn't do this with SDL surfaces and OpenGL. SDL also lacks anything comparable to DirectMusic, and SDL Input doesn't have the sheer flexibility of DirectInput.
As for Win32 vs POSIX:
- Hungarian notation, hungarion notation, hungarian notation.
- Parameters, parameters everwhere! The most complex POSIX calls have half a dozen parameters. The most complex Win32 calls have nearly a dozen direct parameters, plus dozens more parameters passed via structures.
- Win32 uses different functions for related things. In POSIX, mmap() can do everything from map a file to map graphics memory. In Win32, you have seperate APIs for that.
- What POSIX does with one function, Win32 will usually use three or four. Compare {CreateFileMapping, OpenFileMapping, MapViewOfFileEx, UnmapViewOfFile, FlushViewOfFile, CloseHandle} to {mmap(), munmap()}
- Featuritis. Win32 tries to do too much in each call. The WinNT security model is a pain to program. Overall, most of the APIs hare *highly* over-designed.
Re:Pfft. (Score:2, Interesting)
Re:one new goal (Score:2, Interesting)
And don't forget how for every complex Win32 call, there's a nearly-identical function taking 4 fewer arguments and missing "Ex" from the end of its name.