Jump to content
xisto Community
Sign in to follow this  
truefusion

Understanding Desktop Environments In Linux Part 1?

Recommended Posts

As some of you might know, i have started making my own desktop environment for systems that use the X window system (a.k.a X11, X.org)—meaning you would even be able to use it under the Mac OS. Obtaining documentation for making your own desktop environment for X, however, especially with the toolkit of your choice, isn't easy, at least not without browsing through source code of already available desktop environments out there. Being the kind of person who prefers to skim through documentation as far as it will allow him to get the job done or started or have something working as quick as possible, i couldn't dive into, for example, KDE's source code and expect to come out of it knowing how to make my own environment so quickly. Luckily i came across simpler desktop environments that use the toolkit i wanted to use—Qt4. For the sake of making things easier for others who would like to make their own desktop environment, or window manager, i write this out.

 

The basics are quite simple, though. For my current purpose i don't need to make a display manager for loading my desktop environment—thankfully; i can use GDM or KDM, et cetera. What a display manager basically does is it runs a program specified within a desktop file (which can be located in a few locations, but i place the desktop file at /usr/share/xsessions). The program it runs, in turn, runs any other program it needs to form a complete desktop environment—that is, along side any system programs. These programs are known as "clients." The clients communicate with the X server; this is known as a client-server relationship. Naturally, your program does not initially have that relationship, so you have to tell the X server to redirect the event signals to your program. X event signals inform your program about what is going on with the X server—that is, based on the signals you chose to be directed to your program.

 

X is written in C, therefore using pass-by-reference. To select which events you want your program to be informed of, you use the XSelectInput function. For window creation, the important event mask is SubstructureRedirectMask. You want your program to pay attention to the event type MapRequest. From MapRequest you're going to want the member window from the struct. This member holds the window ID which is key for any window management, because you're going to need the window ID in order to reparent the window with the XReparentWindow function. This function allows you to make a GUI widget the parent of that window.

 

I chose a GUI toolkit for my desktop environment to tremendously ease the process of designing my own desktop environment. The GUI toolkit does all the drawing for me, including the text. Indeed, the X window system, though providing the functions to draw on the screen, does not provide the conveniences that a toolkit does. If i were to use the X window system alone for my desktop environment, in order to draw text, for example, i would have to draw it line by line. I chose the Qt GUI library because i find it to be the best and most convenient one. I use the x11EventFilter method to pay attention to what events the X server is informing my program about. Meaning if you want to make your own desktop environment using the Qt GUI library, you need to subclass QApplication.

 

Currently my desktop environment takes up about 3 megabytes without a wallpaper; with the common default_blue.jpg wallpaper, it takes up about 15 megabytes. Working with windows, that is, clients, and managing them is a bit annoying. For example, whenever you resize the window (i.e. the parent widget of the client), the client program doesn't resize with it. Consider the window as a viewport with an invisible scrollarea. To put it more simply, that is, in HTML and CSS terms: let's say you have a DIV element whose ID is "parent" with another DIV element within it whose ID is "client":

<div id="window">
<div id="client"></div>
</div>

Also assume that the following CSS code is applied to these elements:

#parent {overflow: hidden;width: 500px;height: 500px;border: 2px solid black;}#client {height: 700px;width: 700px;}
Anyone who knows HTML and CSS should already know how this looks like. Well, this is what i was talking about. Whenever you resize the parent element, you also have to resize the client element while considering the borders and any padding in order to make things look perfect. You can specify the top and left coordinates of your client within your widget using XReparentWindow. However, that is merely like having "padding: 3px 0 0 3px;" for the parent element up there. Therefore in order to achieve the desired appearance, you use either XResizeWindow or XMoveResizeWindow functions. Of course, unlike HTML, you do not know the ID of the window, therefore you have to figure out a way to keep track of all the window IDs—but that is not as hard as it sounds.

 

Anyway, that is all for now.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.