If Or When Will X12 Actually Materialize?

[some-guy]

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.

[RealNC]

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.

[KellyClowers]

well i agree in the part of keep the network transparent part, but no the actual code. maybe something between vnc and freenx ...

Isn't NX just protocol-specific compression and security on the standard X protocol?

[RealNC]

Isn't NX just protocol-specific compression and security on the standard X protocol?

It is. People sometimes confuse it with VNC.

[bridgman]

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 place

[89c51]

Once we see agreement on that last question (is fragmentation the solution or the problem ?), everything else will fall into place

if you have limited resources then its a problem if you ask me

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)

[RealNC]

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".

The problem I described is more basic though. Gnome for example would, if X would allow for that, implement its look by simply providing an X theme. All the Gnome apps (written with Gtk) would use X, and the X theme would provide the looks.

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?

[RealNC]

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.

Or any X app, for that matter, even X apps using the X API directly without any toolkit in between.

[movieman]

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.

But that _forces_ applications to 'follow a common GUI', which is even worse; particularly if one of those apps is running on my laptop with a 3GHz quad-core CPU and 6GB of RAM while the other is running on an ARM with 32MB of RAM.

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.

[Remco]

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.