If Or When Will X12 Actually Materialize?

[jrch2k8]

How the heck would you use a server with no display adapter card with remote X if graphics weren't fully drawn on client-side?

using for example the software rasterizer from gallium rendering in offscreen and sending the pseudo processed info or the full rendered frame through the client in the network xorg to just end the render or render the frame on the screen. in this case theorically you dont need a gpu, so it possible.

another method could be if you can send the raw requirememnts to an networked xorg, so the other xorg do the render onscreen wich whatever hardware you have, ofc this would need some sort of initialization protocol to at least inform the base xorg server wich screen size you want and what proportion and wich feature your hardware support(for example if your crd can use exa and composite/xrender). in that case you would need the chance to send glx commands too with shaders.

if you want to render in more than 1 computer, would be nice to overhaul the damage extension so you can save band just sending the modifications to the orginal frame. that is in case of using multi input and each user having a different desktop. muticast could help too if you only wanna work in 1 pc and watch only in many pc's so that way you avoid multiple renders

[blacknova]

How the heck would you use a server with no display adapter card with remote X if graphics weren't fully drawn on client-side?

It always possible to use Xvfb.

[nanonyme]

I personally think the UI components of the toolkits themselves should be network-transparent, not drawn client-side

How the heck would you use a server with no display adapter card with remote X if graphics weren't fully drawn on client-side?

[nanonyme]

This can't be true, because X existed for more than a year before Windows 1.0 was even born. (And before X, there was W.)

Well, yeah. X has been around for half eternity. (in the form of Xfree86 and possibly others I don't know of) X.org is relatively new though.

[Akdor 1154]

I think X's network transparency is vastly underutilized.
I personally think the UI components of the toolkits themselves should be network-transparent, not drawn client-side: my app logic talks to my UI toolkit over the network; the toolkit is running in the server on the display. This way my network has to transmit "draw a button x pixels by y pixels and theme it however" as opposed to "here's a bitmap, put it on the screen" or the idyllic "here's a set of primitives, draw them". From my somewhat limited understanding this seems to be closer to the original philosophy of X's network transparency.
Wouldn't it be nice if the world was chocolate?

[Remco]

Even the Windows world has kept the same basic API around for longer than X has been around, despite changes in the rendering system.

This can't be true, because X existed for more than a year before Windows 1.0 was even born. (And before X, there was W.)

[RealNC]

Umm. Nooo.... Mozilla Firefox is it's own thing regardless of what platform it's running on. It does not integrate any better into Windows or OS X as it does for Gnome.

Where'd you get that? I'm using Firefox on W7 and it looks perfect. On Gnome, it looks decent. On KDE, it looks like ass.

[KellyClowers]

Umm. Nooo.... Mozilla Firefox is it's own thing regardless of what platform it's running on. It does not integrate any better into Windows or OS X as it does for Gnome.

Firefox uses GTK and XUL. XUL (and all HTML content as well) is rendered with Cairo since Gecko 1.9.0 (FF3)

[siride]

People must have forgotten about X Toolkit Intrinsics. It's basically what everyone here is proposing (common toolkit with policy and themes implemented by GTK/Qt/etc). It was only used by Motif and maybe Athena widgets. Obviously, it failed.

People must remember that X is equivalent to GDI on Windows. The toolkits + the window manager is equivalent to USER on Windows (basic window management and input demultiplexing are done in USER on Windows, but X on Linux, so that is a key difference). Since Windows presents a little bit more of a unified API and only one toolkit that comes with the system, it appears as though it works differently from X. It doesn't really. And Linux could have chosen to have one toolkit and then this entire discussion would be moot.

I really think the one-piece-at-a-time folks have it right. The overall structure of X is fine. Cruft from the protocol should be removed. Newer, but standard, features should be moved into the core protocol. Xlib should go away. And so on. A total rewrite would be stupid. Even the Windows world has kept the same basic API around for longer than X has been around, despite changes in the rendering system. GDI and USER are still here, even though there is also DWM and WPF. The best path is to provide a way forward and push new software and toolkits to be based on the new features and deprecate the old.

The only thing X really needs right now is man-power. Unfortunately, it seems like it's not top priority. It'd be nice if Canonical, for example, hired a few devs to work just on X. But I doubt that's going to happen. They can barely contribute to the kernel as it is.

[drag]

Which would not be the case if X provided for that stuff, like any other platform does.

Umm. Nooo.... Mozilla Firefox is it's own thing regardless of what platform it's running on. It does not integrate any better into Windows or OS X as it does for Gnome.