makeittotop/x11.txt

## x11.txt
Windows gives you a single implementation of a single desktop on top of a single implementation of a single API / framework, all done by Microsoft.

On Unix systems, you get an API / framework (X11 / X Window System) for which exist multiple implementations (Xorg, Xfree86), on top of which you get various "higher level" API / frameworks (GTK+, Qt, ...) because raw X11 is so primitive, on top of which you get various desktops (Gnome, KDE, ...), all done by different people.

Moreover, the X11 system has been designed from the ground up with remote GUIs in mind - i.e., a lokal machine displaying the GUI of a remotely running application - which introduces the concepts of a "X Server" and "X Client".

Then there is a nomenclature that "feels" the wrong way around for newcomers: Your local machine is running the "X Server" providing the "display a GUI" service, while the remote machine is the "X Client" making use of the services on your machine to display the GUI.

Yes, "X11" is merely a protocol, and Xorg / XFree86 are two implementations. At its basic level, X11 is only about drawing lines and dots, which is not terribly useful if you want to do a GUI.

On top of the X11 protocol, people implemented many things, and it is pretty difficult to do a 1:1 comparison with Windows because Microsoft never bothered to really keep things separate. Also I am not a GUI-type developer, i.e. my actual experience with either system is minimal.

At the bottom, a "window manager" provides a window (handling borders, close / minimize / maximize buttons, resizing etc.), and offers the "real estate" within the window to the widget toolset. There are many window managers, some mimicking other systems (Windows, MacOS, AmigaOS, whatever), and they are mostly interchangeable transparent to the remaining system.

The "widget toolset" offers you buttons, sliders, text fields etc. on which to build your GUI. This is what you (as an application developer) actually get to "see", API wise, and what decides most of the "look & feel" of your application.

A "desktop" builds a number of applications on top of a certain widget toolset / window manager combination, in order to provide a consistent look & feel. You don't have to bother with these unless you actually want to develop the desktop itself.

The desktop "Gnome" uses the widget toolset "GTK+" on top of the window manager "Metacity".

The desktop "KDE" uses the widget toolset "Qt" on top of the window manager "KWin".

Note that especially those two, GTK+ and Qt, have evolved far beyond simple "widget toolsets" into "application development frameworks". If you want to develop GUI apps for Linux, effectively you have to pick which one of those two you want to use. There are more choices, if you want a more "lightweight" app (not needing the big library dependencies), but today most systems have GTK+ and Qt libs already installed anyway.

It's perfectly possible to use Qt apps on a Gnome desktop or GTK+ apps on a KDE desktop (it wasn't always like that), so you have to worry little about compatibility. Given a choice between two apps of comparable functionality, people will usually prefer the app using the "native" widgets of their desktop of choice, but I wouldn't worry about that.

Other, more important bullet points in the choice of "widget toolset": Licensing terms, support for your language of choice, cross-platform compatibility.

http://superuser.com/questions/145031/moving-from-windows-to-linux-understanding-x-window-system-x-server-xorg

On your computer your are running an X server that among other things watches a port for incoming connections. Also the X server sets up a view window where all the X application. windows will be displayed, this is called a root window. It is possible to have more than one root window. The X application you want to run on a remote computer has been compiled with libraries that allow it to communicate with the X server and tell it what to display in the root window. These applications are called X clients. When an X client is run it looks for an X server port to connect to and start issuing commands to display information. When an X server gets a connection on its port there is a small amount of security that the client has to be checked on. Usually this check is to see if the clients host is on a list of allowed client hosts. Once the check and connection is established the X server reads commands from the X client and starts building a window in the root window for the client. The servers job is not only to display graphics it also sends mouse clicks and key presses to the connected clients, in this way you have all the functionality you need to make a working GUI.

In the following paragraphs I will give several examples of how to use X using UNIX based X servers such as Xfree86. For other OSes refer to the user manual of your X server to find how to do similar things. First lets load an X server under Linux and see some of the details inside (further details of how to get this far are at Xfree86):

$ startx

This starts the server and by default starts a single xterm. An xterm is just a simple X client to display text in, usually a login shell. Assuming you are running bash you can look at your environment variables (EV) by typing "set". Environment variables store useful information for programs defaults or system state. If you look at your EV you will see a variable called "DISPLAY" this variable stores the address for X clients to connect to. These addresses are in the form:

hostname:displaynumber.screennumber

A typical example would be:

snake.cs.uidaho.edu:0.0

I said earlier that it is possible to have more than one X server running at a time. In this case the displayname would be something like

snake.cs.uidaho.edu:1.0

or

snake.cs.uidaho.edu:0.1

depending on how its done.

When the X clients start the look at the DISPLAY EV to see where to connect to by default. One way to do remote displaying would be to set this EV to a remote X server.

$ export DISPLAY=mymachine.mynet.uidaho.edu:0.0

Then you can run your cool X application and its display will be on mymachine.mynet.uidaho.edu.

$ xclock

Another way to do remote display is by a command line option that all X applications have: "-display [displayname]". To run your cool X application:

$ xclock -display mymachine.mynet.uidaho.edu:0.0

This does the exact same as before.

The previous demonstrations rely on whether your X server is allowing connections from remote hosts. The following command allows connections from all hosts (run on machine that the X server is running on (mymachine.mynet.uidaho.edu)):

$ xhost +

To allow connections from single hosts at a time:

$ xhost +myremote.myothernet.uidaho.edu

ssh is a neat remote login tool that in addition to having secure encrypted transmissions auto forwards your X DISPLAY EV if your are running it under an X Server. ssh allows a easy, no hassle, way to do all of the stuff we have discussed so far. The ssh documentation has more detailed information on how to get this working.

http://www.hungry.com/~jamie/xexport.html
	Windows gives you a single implementation of a single desktop on top of a single implementation of a single API / framework, all done by Microsoft.

	On Unix systems, you get an API / framework (X11 / X Window System) for which exist multiple implementations (Xorg, Xfree86), on top of which you get various "higher level" API / frameworks (GTK+, Qt, ...) because raw X11 is so primitive, on top of which you get various desktops (Gnome, KDE, ...), all done by different people.

	Moreover, the X11 system has been designed from the ground up with remote GUIs in mind - i.e., a lokal machine displaying the GUI of a remotely running application - which introduces the concepts of a "X Server" and "X Client".

	Then there is a nomenclature that "feels" the wrong way around for newcomers: Your local machine is running the "X Server" providing the "display a GUI" service, while the remote machine is the "X Client" making use of the services on your machine to display the GUI.

	Yes, "X11" is merely a protocol, and Xorg / XFree86 are two implementations. At its basic level, X11 is only about drawing lines and dots, which is not terribly useful if you want to do a GUI.

	On top of the X11 protocol, people implemented many things, and it is pretty difficult to do a 1:1 comparison with Windows because Microsoft never bothered to really keep things separate. Also I am not a GUI-type developer, i.e. my actual experience with either system is minimal.

	At the bottom, a "window manager" provides a window (handling borders, close / minimize / maximize buttons, resizing etc.), and offers the "real estate" within the window to the widget toolset. There are many window managers, some mimicking other systems (Windows, MacOS, AmigaOS, whatever), and they are mostly interchangeable transparent to the remaining system.

	The "widget toolset" offers you buttons, sliders, text fields etc. on which to build your GUI. This is what you (as an application developer) actually get to "see", API wise, and what decides most of the "look & feel" of your application.

	A "desktop" builds a number of applications on top of a certain widget toolset / window manager combination, in order to provide a consistent look & feel. You don't have to bother with these unless you actually want to develop the desktop itself.

	The desktop "Gnome" uses the widget toolset "GTK+" on top of the window manager "Metacity".

	The desktop "KDE" uses the widget toolset "Qt" on top of the window manager "KWin".

	Note that especially those two, GTK+ and Qt, have evolved far beyond simple "widget toolsets" into "application development frameworks". If you want to develop GUI apps for Linux, effectively you have to pick which one of those two you want to use. There are more choices, if you want a more "lightweight" app (not needing the big library dependencies), but today most systems have GTK+ and Qt libs already installed anyway.

	It's perfectly possible to use Qt apps on a Gnome desktop or GTK+ apps on a KDE desktop (it wasn't always like that), so you have to worry little about compatibility. Given a choice between two apps of comparable functionality, people will usually prefer the app using the "native" widgets of their desktop of choice, but I wouldn't worry about that.

	Other, more important bullet points in the choice of "widget toolset": Licensing terms, support for your language of choice, cross-platform compatibility.

	http://superuser.com/questions/145031/moving-from-windows-to-linux-understanding-x-window-system-x-server-xorg

	On your computer your are running an X server that among other things watches a port for incoming connections. Also the X server sets up a view window where all the X application. windows will be displayed, this is called a root window. It is possible to have more than one root window. The X application you want to run on a remote computer has been compiled with libraries that allow it to communicate with the X server and tell it what to display in the root window. These applications are called X clients. When an X client is run it looks for an X server port to connect to and start issuing commands to display information. When an X server gets a connection on its port there is a small amount of security that the client has to be checked on. Usually this check is to see if the clients host is on a list of allowed client hosts. Once the check and connection is established the X server reads commands from the X client and starts building a window in the root window for the client. The servers job is not only to display graphics it also sends mouse clicks and key presses to the connected clients, in this way you have all the functionality you need to make a working GUI.

	In the following paragraphs I will give several examples of how to use X using UNIX based X servers such as Xfree86. For other OSes refer to the user manual of your X server to find how to do similar things. First lets load an X server under Linux and see some of the details inside (further details of how to get this far are at Xfree86):

	$ startx

	This starts the server and by default starts a single xterm. An xterm is just a simple X client to display text in, usually a login shell. Assuming you are running bash you can look at your environment variables (EV) by typing "set". Environment variables store useful information for programs defaults or system state. If you look at your EV you will see a variable called "DISPLAY" this variable stores the address for X clients to connect to. These addresses are in the form:

	hostname:displaynumber.screennumber

	A typical example would be:

	snake.cs.uidaho.edu:0.0

	I said earlier that it is possible to have more than one X server running at a time. In this case the displayname would be something like

	snake.cs.uidaho.edu:1.0

	or

	snake.cs.uidaho.edu:0.1

	depending on how its done.

	When the X clients start the look at the DISPLAY EV to see where to connect to by default. One way to do remote displaying would be to set this EV to a remote X server.

	$ export DISPLAY=mymachine.mynet.uidaho.edu:0.0

	Then you can run your cool X application and its display will be on mymachine.mynet.uidaho.edu.

	$ xclock

	Another way to do remote display is by a command line option that all X applications have: "-display [displayname]". To run your cool X application:

	$ xclock -display mymachine.mynet.uidaho.edu:0.0

	This does the exact same as before.

	The previous demonstrations rely on whether your X server is allowing connections from remote hosts. The following command allows connections from all hosts (run on machine that the X server is running on (mymachine.mynet.uidaho.edu)):

	$ xhost +

	To allow connections from single hosts at a time:

	$ xhost +myremote.myothernet.uidaho.edu

	ssh is a neat remote login tool that in addition to having secure encrypted transmissions auto forwards your X DISPLAY EV if your are running it under an X Server. ssh allows a easy, no hassle, way to do all of the stuff we have discussed so far. The ssh documentation has more detailed information on how to get this working.

	http://www.hungry.com/~jamie/xexport.html