PureBasic Forums - English

Hi,

this question probably shows my limited "PB on Tux" knowledge, but here it goes anyway:

For an appliance (a graphical application that doesn't need a proper windowing system) I reckon it would suffice to install GTK and not install X. Can I still deploy PureBasic compiled applications for such a setup?

If you don't have X you only have a console, not graphical modes.

Hi Trond,

thanks for your answer! My understanding was that one could have GTK without X (and thus only use PB screens), as X is built atop GTK... Also, SDL sits atop GTK and doesn't need X, that's why I assumed I could do away with X for PB apps that only need non-windowed graphical screen buffers.

Apparently I'm wrong here? Am I mixing up GTK with XLIB?

EDIT:

yes I am mixing up things, as GTK is a toolkit for building graphical user interfaces. What I'm after is the minimum Linux configuration that is needed to run SDL. I suppose that means installing XLIB and some frame buffer software.

So I need to rephrase my question: SDL without X is feasible, but will PB apps run on such a minimal sysem?

Hi dell_jockey!

I think PureBasic applications will most likely not run on a system with only X and SDL. You can however make command-line interface applications or fullscreen games work with such a configuration as everything else that has something to do with a user interface (window, gadget, etc) requires GTK.

I guess this diagram will help you a bit more to understand how these things work (this diagram takes only GUI applications into account, not CLI applications):


As you can see, both GTK and SDL require X and it is possible that an application requires both of them as shown in the diagram. As you see, the hardware is accessed through the X server, but in case the application does not have a graphical user interface (GUI) but has a command-line interface (CLI) then it will most likely access the hardware directly or through a layer or hypervisor.

I do not know much about this area myself, so do not count on it that my information is correct. I make mistakes too ^O^

SDL can actually run on a framebuffer device instead of X, but it probably requires special care.

Trond wrote:SDL can actually run on a framebuffer device instead of X, but it probably requires special care.

http://en.wikipedia.org/wiki/Linux_framebuffer wrote:Nowadays several Linux programs such as MPlayer, and libraries such as GGI, SDL, GTK+ and Qtopia can use the framebuffer immediately, avoiding the overhead of an X server. This is particularly popular in embedded systems.

I did not know that GTK applications can also use the framebuffer. I did know that SDL can be used with just the framebuffer without X, but the last time I tried to achieve this I got pretty bad results. I have a copy of an ancient DOS game emulator called "dossdllinux" (DOS-SDL-Linux) which uses SDL in framebuffer mode. I have only gotten some demos to work with it, but no real games like Lemmings for instance.

PB's GUI libs link directly with gtk with the X backend iirc, so if you want to use the
framebuffer you can't use the PB libraries.

freak wrote:PB's GUI libs link directly with gtk with the X backend iirc, so if you want to use the
framebuffer you can't use the PB libraries.

Thanks Freak,

my app will open a graphical screen (full screen, native resolution, no window) - but will open NO windows nor any other GUI gadgets offered by the PB libraries. It will be using sprites (2D & 3D) as well as the 2D drawing library. The application development will take place on another machine (of course with X installed) but the app proper should be deployed on a Linux that is as small as possible.

What would be the minimum Linux system that can run such PB applications? Would I really need to install X-Windows?

thanks again!

just discovered SDL.PB in the PB 4.1 compiler Linux examples. Isn't that exactly what I need? It's a console app that creates a double buffered graphics screen by calling SDL directly... Still opens a window though, but that is easily alleviated by using the #SDL_FULLSCREEN constant. I'll have to look into this...