Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Apple didn't use X for the window system

developers.slashdot.org

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Why Apple didn't use X for the window system

#31

Post by nailer »

nuclear_eclipse wrote: post #20
michaelneale wrote: post #15

Earlier quoted context omitted.

Actually that makes more sense. It also makes sense with their view on antialiasing fonts (eg look at iphone DPI, it is close to print DPI).

Actually, there are other devices, like the Openmoko Neo 1973 and Neo Freerunner, which have much higher DPI screens. The iPhone has a resolution of 480x320, at 3.5", for 160dpi; the Neos have a 2.8" 640x480 resolution screen, at 280dpi. It's really nice to look at and read text on. :)

The Neo has a 280 DPI screen?

That's awesome - I don't think I've ever seen a display that close to print quality. Its a pity the styling and software don't seem very consumer friendly.

Re: Why Apple didn't use X for the window system

#32

Post by tx »

nailer wrote: post #30
orib wrote: post #23

Earlier quoted context omitted.

Hm, I can't think of a good overview off the top of my head (maybe I should sit down and write a good one sometime), but the way it works is: An application will typically use a GUI toolkit like GTK or QT to do it's UI. This library will use Xlib[1] (or XCB[2] in some cases) to do it's event handling. Event handling in X consists of handling button clicks, sending messages to and from the window manager, cut and past…

Would it be possible or useful to create an X extension for higher lever (ie, toolkit) primitives for remoting? Ie, an app can send 'list box widget in GTK' to the display server?

Like this? http://www.gtk-server.org/

Re: Why Apple didn't use X for the window system

#33

Post by tx »

orib wrote: post #23
tx wrote: post #10

Earlier quoted context omitted.

Wow, nice explanation - thank you. Since you seem to know this stuff, where can you send me for a nice introduction to Linux drawing/windowing stack? I've done some searches and tried to read up on this, but it looks like a bunch of loosely-related libraries that I can't compose a solid "picture of everything" from. I'm coming from years of Windows lower-level UI coding (Win32/GDI/GDI+) and I wanted to look into Gnom…

Hm, I can't think of a good overview off the top of my head (maybe I should sit down and write a good one sometime), but the way it works is: An application will typically use a GUI toolkit like GTK or QT to do it's UI. This library will use Xlib[1] (or XCB[2] in some cases) to do it's event handling. Event handling in X consists of handling button clicks, sending messages to and from the window manager, cut and past…

Saved to a text file. Thank you for taking the time!

Re: Why Apple didn't use X for the window system

#34

Post by orib »

nailer wrote: post #30
orib wrote: post #23

Earlier quoted context omitted.

Hm, I can't think of a good overview off the top of my head (maybe I should sit down and write a good one sometime), but the way it works is: An application will typically use a GUI toolkit like GTK or QT to do it's UI. This library will use Xlib[1] (or XCB[2] in some cases) to do it's event handling. Event handling in X consists of handling button clicks, sending messages to and from the window manager, cut and past…

Would it be possible or useful to create an X extension for higher lever (ie, toolkit) primitives for remoting? Ie, an app can send 'list box widget in GTK' to the display server?

Possible, although it would be rather difficult to do well in a flexible manner, and would be unusable by every app that currently exists. More or less, it would be a replacement of the entire X event handling model, entire X drawing model, etc.

And it would make writing apps more difficult -- very few of them use entirely stock widgets, and it would be nearly impossible to securely and performantly implement new widgets on this system.

Plus, it's diametrically opposed to the X "Mechanism, not policy" mantra.

I wouldn't expect anything like this to take off, but it's been tried in the Y window system, and more interestingly -- and more dead-in-the-water -- in the NEWS window system.

Re: Why Apple didn't use X for the window system

#35

Post by nailer »

tx wrote: post #32
nailer wrote: post #30

Earlier quoted context omitted.

Would it be possible or useful to create an X extension for higher lever (ie, toolkit) primitives for remoting? Ie, an app can send 'list box widget in GTK' to the display server?

Like this? http://www.gtk-server.org/

No, that's a tool for making GTK applications in various scripting languages.

Re: Why Apple didn't use X for the window system

#36

Post by nailer »

orib wrote: post #34
nailer wrote: post #30

Earlier quoted context omitted.

Would it be possible or useful to create an X extension for higher lever (ie, toolkit) primitives for remoting? Ie, an app can send 'list box widget in GTK' to the display server?

Possible, although it would be rather difficult to do well in a flexible manner, and would be unusable by every app that currently exists. More or less, it would be a replacement of the entire X event handling model, entire X drawing model, etc. And it would make writing apps more difficult -- very few of them use entirely stock widgets, and it would be nearly impossible to securely and performantly implement new wid…

Why would it have to replace the existing drawing model? I'm thinking of a way for an app to ask the server if it can render a particular set of high level primitives, if the server responds that it can, the apps sends those instead.

That would allow existing apps and existing display servers, new apps and older display server, and old apps and newer display servers to work fine.

If both the app (at the toolkit level) and the display server are recent, however, remoting is massively sped up.

Post reply on HN