Tweet
Originally posted by cb88
View Post
-
No, it doesn't. -
I know Firefox still has some X11 code in it, and I imagine a fair number of other large projects do as well. That's code that could probably be ported if there was a reason to do so, but no one is going to do it until it's absolutely necessary. But clearly the toolkits are the main hurdle - port them and everything else should be pretty close.Originally posted by drag View PostComment
-
Well Firefox is it's own toolkit. It does not use GTK or QT or anything like that. It is it's own rendering engine and all that stuff on it's own.
This is one of the reasons why it'll never really integrate properly into a Gnome or KDE environment... it's always just going to emulate their look-n-feel.Comment
-
Which would not be the case if X provided for that stuff, like any other platform does.Originally posted by drag View PostComment
-
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.Originally posted by RealNC View PostComment
-
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.Comment
-
Firefox uses GTK and XUL. XUL (and all HTML content as well) is rendered with Cairo since Gecko 1.9.0 (FF3)Originally posted by drag View PostComment
-
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.Originally posted by drag View PostComment
-
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.)Originally posted by siride View PostComment
-
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?
Comment
Comment