"NUPUL" writes:

> On Feb 21, 5:45 pm, Andre Majorel wrote:
>
>> Not all GUIs involve widgets. If you need graphical output
>> and/or mouse input but not buttons, menus and so forth, direct
>> Xlib programming is a viable alternative.
>
> Could you please give me an example of such a "graphical output" that
> you mentioned above? Along with the possible "mouse input, menus etc.?

The last X program I wrote is a CPU load graph. All it does is
display a scrolling graph of the CPU load. There is absolutely no
need to invoke the full bloat of a toolkit to do this. In fact, it
takes less code in total than just the setup of Gtk widgets would.

>> and, if you are creating your own widget, even more.
>
> When would one want to create their own widget, given that good and
> mature toolkits are easily available?

You might be writing a toolkit. They don't grow on trees, you know.

--
Måns Rullgård
mans@mansr.com

"NUPUL" writes:

> Most of these calls are handled by the existing toolkits today.
> Like for example: I had written a desktop manager (for Linux) using
> Qt. I studied and went through a lot of X to find out how to do event
> processing, window management (bring to front, push to bottom etc).
> For every thing there was a solution in Qt!

Qt is a cross platform toolkit.
For that reason they need to develop APIs for ALL the X functions,
not just the ones they are adding function to.

On Feb 22, 8:13 pm, "NUPUL" wrote:
> Browser quirk caused me to write another message:
>
> > The last X program I wrote is a CPU load graph. All it does is
> > display a scrolling graph of the CPU load. There is absolutely no
> > need to invoke the full bloat of a toolkit to do this. In fact, it
> > takes less code in total than just the setup of Gtk widgets would.
>
> Any more such examples that you all have developed?
>

A screensaver rendering into the root x window.

Don't forget to run valgrind on a qt app and then another one on an
xlib app
to get an idea about reliability vs functionality for toolkits
built on top of x.

"NUPUL" writes:

> Browser quirk caused me to write another message:
>
>> The last X program I wrote is a CPU load graph. All it does is
>> display a scrolling graph of the CPU load. There is absolutely no
>> need to invoke the full bloat of a toolkit to do this. In fact, it
>> takes less code in total than just the setup of Gtk widgets would.
>
> Any more such examples that you all have developed?

I've written a memory usage monitor, a battery monitor, and a CPU
frequency monitor, all using the same mini-library I made for drawing
little graphs. I guess these really count as a single app.

I also wrote a very basic "system tray" app to display icons as
requested by other apps using the usual protocol. The aforementioned
system monitoring apps can use this protocol, BTW.

You said you were aware of Xv, but I'll anyway mention that I've
written a video player using it.

--
Måns Rullgård
mans@mansr.com

On 2007-02-22, NUPUL wrote:
> On Feb 21, 5:45 pm, Andre Majorel wrote:
>
>> Not all GUIs involve widgets. If you need graphical output
>> and/or mouse input but not buttons, menus and so forth, direct
>> Xlib programming is a viable alternative.
>
> Could you please give me an example of such a "graphical output" that
> you mentioned above? Along with the possible "mouse input, menus etc.?

- An oscilloscope.

- A graphical file viewer (maps bits and bytes into colours to
find images in binaries or spot patterns in data).

- A MIDI controller that presents virtual rotary encoders and
sends MIDI CC messages when you position the pointer over the
zone and spin the wheel).

- A utility to piece images together (set the offsets
interactively).

- A utility thats lets you move the mouse pointer over a log
scale and outputs a sine at the frequency under the pointer.

- A simple image viewer.

- An terminal emulator.

- A video test pattern generator.

None of these require menus or buttons.

>> One famous application that uses straight Xlib is Xv. A number
>> of video games and emulators are written in straight Xlib,
>> although SDL seems to be the default choice these days.
>
> I have heard about this but I really don't know "how" does X fit into
> the emulator scene? I mean one would usually code using OpenGL/Mesa
> Libraries, right?

Why ? Machines old enough to be emulated in real time on a
desktop PC tend not to have any 3D capabilities.

> so where do I use X directly?

To emulate a raster display, you emulate the CRTC of the
hardware to be emulated, except that instead of driving the red,
green and blue guns and sync inputs of a CRT, you update a
shared memory XImage, which you then XShmPutImage() into a
Window.

>> I don't know if all toolkits allow you to do shared XImages,
>> shared Pixmaps, planes operations, complex vector graphics etc.
>
> I get your point. Other than pure " 2D image processing" one
> could use these operations for gaming too, right?

You would certainly use shared XImages and/or Pixmaps. You could
use real-time palette tweaking (although PseudoColor displays
are uncommon now). You might use plane operations.

> Do you know of any such applications/games? If so, what part
> of the game is coded using X?

All of it. xasteroids does vector graphics in pure Xlib.
(XDrawLine() calls probably). Nighthawk and xkobo do bitmap
graphics in pure Xlib. I seem to recall xkobo uses a huge
Pixmap. See also rocksndiamonds, mirrormagic...

> Programmers usually say that they would use Assembly language
> programming to speed up certain parts of the code? Could one
> draw such a correlation with X?

Kind of. Xlib is lower level than the toolkits but more
flexible, and might give you opportunities to better exploit
your hardware.

Those who use Xlib instead of a toolkit do it for their own
reasons. For me, using a toolkit would not remove the need for
the graphical output code, which is Xlib code anyway. But it
would require additional setup code and a dependency on a
library. All this for no tangible benefit if I don't need a
menus-icons-buttons interface.

--
André Majorel
(Counterfeit: pafexyb@addressee.com qiq@barnstorm.com)
First rule of Usenet : if we don't have an answer, it's not a
good question.

On 2007-03-01, NUPUL wrote:

> Excellent Andre!!! Thanks a million! your discussion threw more light
> on the answer(s) I was seeking. You carefully chose to answer all the
> cross questions I put forth and gave me a far better understanding of
> the applications of X.

Glad to be of help.

> Another question, do you code in X, professionally? - not a
> compulsion to answer, just got curious

No, as a hobby only. Although I might, as my current employer
happens to use an in-house toolkit, but I don't work on that
part of the software.

One more word to help put things into perspective ; I originally
learned toolkits (Motif and Tk), not Xlib. I got into Xlib
because it bothered me to read references to "Pixmaps" and such
in the toolkits doc and not knowing what that was. I'm more
comfortable when I understand the underlying mechanisms.

--
André Majorel
(Counterfeit: iruhykeb@lose.com loj@addressee.com)
First rule of Usenet : if we don't have an answer, it's not a
good question.