What I see as the main complaint, is that there are many things in X that are duplicated elsewhere. Network support through plain X is not used anymore, xrender replaces other things in X11, randr replaces more, etc.
Announcement
Collapse
No announcement yet.
If Or When Will X12 Actually Materialize?
Collapse
X
-
From a programmer's point of view, X is not nice to work with. When I write something in the win32 API, or Cocoa, or the older Carbon, and then come to X it looks so alien. There are no widgets, to start with; one has to decide between Gtk and Qt. There's no "native X" look&feel.
If I can write native GUIs for win32 and Cocoa/Carbon apps, why can't I write native GUIs for X apps? I can understand why 23 years back X might have not wanted to provide a theme-able look&feel and let Motif do the work. But now it's 2010 and look at what happened to Motif... And look at what happens to people who run Gtk apps on KDE, or run 32-bit apps in 64-bit Gtk. Or everything of that vice versa.
IMO, toolkits should be there to make it easier to write GUIs and access the low level system widgets, not to implement that stuff from scratch. Because if they do (and they do) there's fragmentation which results in applications not following a common GUI.
And I don't think Wayland addresses this either.
Comment
-
There's a chicken-and-egg problem here - framework developers and specific user groups want the ability to implement competing desktop solutions, but end users and app developers want the kind of "clarity", maturity and polish that normally only comes with a dictatorial "this is the only way" approach to managing the "product".
Today we have lots of competing solutions for everything, all surprisingly good but very few are sufficiently polished that users can even agree on which solution should be the standard. Depending on who you are and who you ask, this fragmentation is either the greatest strength of open source OSes or the greatest weakness.
Once we see agreement on that last question (is fragmentation the solution or the problem ?), everything else will fall into placeTest signature
Comment
-
Originally posted by bridgman View PostOnce we see agreement on that last question (is fragmentation the solution or the problem ?), everything else will fall into place
there are so much "antagonizing" "products" in oss that makes it painful
how many web browsers or mail clients do we need
but maybe it isn't as important in apps as it is in infrastructure (ie classic drivers vs gallium drivers this multimedia framework vs that multimedia framework etc etc)
Comment
-
Originally posted by bridgman View PostThere's a chicken-and-egg problem here - framework developers and specific user groups want the ability to implement competing desktop solutions, but end users and app developers want the kind of "clarity", maturity and polish that normally only comes with a dictatorial "this is the only way" approach to managing the "product".
Now, when you run KDE instead, and fire up a Gtk app, it would use KDE's X theme. There you go, Gtk apps using Oxygen, because Oxygen would be implemented as an X theme.
All the other systems can do that. Why not X?
Comment
-
Originally posted by RealNC View PostNow, when you run KDE instead, and fire up a Gtk app, it would use KDE's X theme. There you go, Gtk apps using Oxygen, because Oxygen would be implemented as an X theme.
Comment
-
Originally posted by RealNC View PostIMO, toolkits should be there to make it easier to write GUIs and access the low level system widgets, not to implement that stuff from scratch. Because if they do (and they do) there's fragmentation which results in applications not following a common GUI.
The odd thing is that when I went from Sunview/Xview programming to Windows, I couldn't understand how anyone could stomach writing Windows software when the API was so low-level and convoluted... having to deal with processing individual messages rather than object-oriented callbacks to event functions? How primitive.
Comment
-
I think X is fine where it is right now, as a lower level than GUI toolkits. You don't need to shoehorn a(nother) widget engine into X to merge the widget engines of GTK+ and Qt. You need to actually merge the widget engines of GTK+ and Qt. And that won't happen for a long long time.
Comment
Comment