OSDev.org

Hi!
I'd like to program graphics (putting pixels, drawing lines and circles, managing windows etc). It'd be neat to do it in a window in linux. X programming seems reasonable - is it? I had some tries with xcreateimage xputimage etc but somehow all it did was segfault:(
X programming with xlib - good idea? Maybe some other library (I want to be draw in a buffer and then put the whole buffer to screen)

Why not use a graphical toolkit like SDL?

There are lots of options for you man .. simply a huge list of options , well the toolkit you really want to use depends upon the kind of work you really want to do .....
eg X ( barebones),SDL , Allegro , Gtk ,svgalib , Fox , WxWigets , qt ,Tk .... the list is almost endless , you pick up the one of your choice for your work

Well, programming X directly might be OK as long as you are pixel-drawing. But there is a reason why there are so many toolkits for X - it's a nightmare to do anything complex on. (So it is said, I never coded for X.)

The same holds for SDL. It can only do blits and pixel accesses.

Wow, that's lots of libraries, thanks a lot, especially for SDL I checked it out it seems to be just what I wanted, the things I'm up to are drawing a line in a framebuffer, a circle, etc, no need for GTK widgets here

Oh, and somehow it seemed easier to find a programming introduction to SDL than to X on the net.

Adek336 wrote:no need for GTK widgets here

Take a look at gdk and so forth ... i do not think i will do justice leaving out gtk and others

Solor is correct , X was never inteneded to be used as such ...... { I think i read this in the book about X , by 3 mit programmer s-- i do not remember exactly , it has been a long time since i have worked with X }

Adek336 wrote:Hi!
I'd like to program graphics (putting pixels, drawing lines and circles, managing windows etc). It'd be neat to do it in a window in linux.

Install Windows, or use xmingw cross-compiler and run it using Wine.

X programming seems reasonable - is it

Short answer no. X itself is in no way reasonable. In fact X sucks so heavily that anything built on top of it simply cannot be reasonable. Do yourself a favor, and stay in text-mode or install Windows.

And now before anyone trolls me down: I did write half a toolkit (which wasn't released 'cos what's the point with half a toolkit) against raw X11 API, and it's simply impossible to write reliable code against an API that does it's best to make it impossible to do reasonable modern software architecture. The fact that Xlib itself is utter crap (just try running any X-app in valgrind) doesn't exactly help either.

PixelToaster my friend is what you need. It's a cross platform graphics library that doesn't nothing but set up a window/back-buffer for you to write your pixels too!

I think it also has some mouse/keyboard code in there aswell you can use.

mystran wrote: In fact X sucks so heavily that anything built on top of it simply cannot be reasonable. Do yourself a favor, and stay in text-mode or install Windows.

I'm very tempted to believe you -- but it seems like there are some nice X apps out there. I mean, all those IDEs that everyone uses -- and the Linspire desktop seemed very decent when I looked at it. I assume that people know what toolkits those are coded with?

bewing wrote: I'm very tempted to believe you -- but it seems like there are some nice X apps out there. I mean, all those IDEs that everyone uses -- and the Linspire desktop seemed very decent when I looked at it. I assume that people know what toolkits those are coded with?

There are two desktops, one known as KDE (based on proprietary Qt) and the other known as Gnome (built with GTK). The toolkits themselves are reasonable in some sense, but it is the low-level nature of X that makes things painful (like.. multiple threads anyone?). The toolkits do heavy amount of stuff to try to work around the problems with X. In a reasonable GUI system, you can send messages between threads, wait for events from several sources (like GUI itself, sockets, files, whatever) at the same time, and so on. In X the toolkit has to hack all of this together.

Also, in a system like Win32, you basically need a handle into a Window to put your GUI into, and you can pretty much build like you were a stand-alone application, even when you really are a library or a plugin or whatever. All you have to assume is that there's a message loop somewhere (and there's basically one way to write a message loop anyway so this isn't such a problem). In X11, it's up to the toolkits to provide this (very useful) functionality as well. So anything like OLE linkage, or simple audio plugin GUIs, or whatever, needs to be explicitly supported, instead of the GUI design doing it for you (like a sensible GUI would).

And yes, there are whole desktop's worth quite nice applications. I actually prefer the usability of Gnome over anything else. But from GUI programming stand-point, X11 still sucks. GTK hides it well enough that if all you want to do is simple dialog-style stuff, it's quite acceptable, but once you want to push towards truly modern GUI functionality (and especially interoperability), X isn't so great.

Hmmmm. OK. So, just for the sake of imagining, let's say there's some existing app -- let's call it ... ummmmmm ... "bochs". And let's say that it already has something that it calls a "VGA window" that runs on X, and is built with some toolkit that I don't know the name of. Just for the sake of argument, say it might also might be possible to write a "debugger window" that is also graphical.

And let's say that I have a debugger window already coded up for Win32. And I'm thinking of trying to translate it into X. So, you are saying that the first thing I need to know is what toolkit the VGA window is written on, because I'm going to have to be dependent on whatever form of event loop that the toolkit uses? And that if I'm unlucky that there might be some control that I cannot subclass, or superclass, or does not even exist in the X toolkit? Or some vital Win message that simply does not happen in X?

GUI Toolkits Compared

I have worked with few UI libraries during my college days (late night hackwork !). Although It has months since i really coded something in C/C++ . Here is my opinion on most of the UI frameworks ( choices available ) .

(a) Win32 API , GDI (user32.dll)
This was the most difficult to work with initially . I initially found it more difficult to work with than X , with strange typedef's and cumbersome hungarian Notation etc . But once you get the hang of it , its quite easy . But getting the hang of it may take some time . You may look at Charles Petzold programming Windows for more information.(Works only on Windows AFAIK , or may be Wine and ReactOS )


(b) MFC
MFC is quite friendly . You can make ui's pretty quickly and easily . But if you follow one of those "
teach yourself MFC in xx days " , you might get stuck at some point of time . You should start from the ground up without using the wizards provided and then later switch to wizards after you get more advanced . It also provides many features (Document View Architecture , to name a few ) and most developers usually do not properly utilize them . Works only on Windows AKIK , or may be Wine and ReactOS )

(c)GTK
The Gimp''s toolkit . It was initially made for the development of the GNU Image manipulation program or the GIMP . Its very easy to write ui's in GIMP and now you have glade available . The gimp website provides sufficent documentation and its pretty cool ! . The downside of gtk is that , its strong only in *nix platforms . The ui elements may look a touch different depending upon the platform .

(d)FOX
Its yet another cool framework which i have worked with. Its pretty impressive , ui elements look the same in all platforms . But the downside of fox is that it has a slightly steeper learning curve compared to Gtk , and it somewhat mimics MFC in its API .

(e)QT
QT is the best i guess in terms of quality and portability , but qt has a confusing license . Other than that its awesome .It competes with MFC in ease of use and beats it completely in portability . It boasts of a signal -- connect sort of thing , but there is nothing novel in it .

(f)svgalib
its pretty good as well . its easy to use , but need root privilleges ,its quite buggy as well

(g)Allegro
Easy to use multiplatform gaming framework

(h)SDL- Simple DirectMedia Layer
Same as Allegro

(i)Xlib
Honestly its initially easier to learn Xlib , than Win32 API . But it only provides barebones functionality . There is an autoritative X book by main authours themselfves. I havent coded in Xlib for the past 3 years , so forgot most of it . Also if you have experience programming Windows , programming X should not be too difficult .

There are others as well , but i will stop for the time being .......
Regards
Sandeep

I would also suggest the good old "forger's win32 tutorials" for Win32 basics, to get a hang of it..

But yeah. Win32 is loose, and takes some understanding, so you don't shoot yourself in the foot. Kinda like C.. but that's also it's advantage compared to many other toolkits. Even GTK, while technically C, goes for C++ like classes, while I like to think of Win32 as being more closer to something like Smalltalk maybe..

edit: I've also written code against plain Xlib, but where as with Win32 you got similar level to work with, but can easily wrap around it all, with Xlib you have to deal with annoying amounts of design about how you dispatch messages and such (which is why most toolkits force one model on you) because all the Xlib really does it talk to the (rather dump) X server.

The biggest pain though with X comes when you want to deal with textual I/O, specially in locales other than ASCII US..

@bewing :It is very difficult to reuse something written for Windows in X .You might have to start from the begining again. Xlib does not provide any controls that you can subclass or superclass . As mystran said , all it does talk to the X server . The term 'server' here is somewhat misleading .


@mystran : Win32 API does violate an important principle - put less burden on end users short term memory . I find myself refering the Win32.hlp file provided by Borland or msdn freqently , whenever i need to do something and it does reduce my productivity .

Quiz ?
How many parameters does CreateFont take ?

Regards
Sandeep