I was wondering, what do you people think of sdl’s use for applications,
not just games? I was doing some research on emulated guis and SDL seems
like a perfect base for this, yet I havn’t seen much use with SDL in the
application area.
I was wondering, what do you people think of sdl’s use for applications,
not just games? I was doing some research on emulated guis and SDL seems
like a perfect base for this, yet I havn’t seen much use with SDL in the
application area.
Well, just think of embedded devices, some kind of industrial
controlling terminals,
…
I’m just developing an app that will run on a 486/66 single board
computer with a
touch-display (~20cm x 15cm).
This device will capture and manage radiationdose-data from medical
devices.
And… 
It’s based on SDL… and a little bit on ParaGUI
There are many opportunities!
The main thing (imho) that detracts applications and GUI toolkits from SDL
is the fact that it doesn’t yet support multiple windows.
Any idea when that’s coming around, Sam?
Cheers,
MattOn Thu, Oct 12, 2000 at 03:54:00PM -0400, Garrett Banuk wrote:
I was wondering, what do you people think of sdl’s use for applications,
not just games? I was doing some research on emulated guis and SDL seems
like a perfect base for this, yet I havn’t seen much use with SDL in the
application area.
The main thing (imho) that detracts applications and GUI toolkits from SDL
is the fact that it doesn’t yet support multiple windows.
How many applications “REALLY” need more than one desktop window
(managed by the wm) ?
I think none
Alex
Now I know how you got your nick on IRC.
There are countless uses for multiple windows in real applications. Think
of every GTK application that uses multiple windows. Sure, you could make
them do things themselves, but then you get inconsistency and inflexibility
(I sure would prefer to have E manage my windows where I can tinker with
their properties). It’s as braindead as saying nobody will ever need any
more than 640K of memory. Yeah, there are badly hacked out solutions for
both.
Any real GUI application will require multiple windows that are managed by
the window manager for user flexibility, power and ease that it provides.
Even many games would benefit from this.
Until that’s possible, any application development of consequence will not
be feasible on SDL. Does anyone really care? That’s a different story.
Cheers,
MattOn Thu, Oct 12, 2000 at 08:52:09PM -0100, Alexander Pipelka wrote:
The main thing (imho) that detracts applications and GUI toolkits from SDL
is the fact that it doesn’t yet support multiple windows.How many applications “REALLY” need more than one desktop window
(managed by the wm) ?I think none
Alex
Hi Matt!
Thanks for the professional declaration your of opinon!
BUT…
If you need multiple windows use GTK, QT, or whatever …
I think SDL could be very suitable for small (or even
larger ) apps running in fullscreen mode!
BTW, how did you get your nick ‘solaris’. Any relation
to SUN ?
Because such a workstation you will need when you try to
run SDL multiwindow apps.
Just take a calculator and type in:
e.g:
1024x768x3 (or 4) per window
x e.g. 4 windows = ???
Quite a lot 
n/m
Alex> On Thu, Oct 12, 2000 at 08:52:09PM -0100, Alexander Pipelka wrote:
The main thing (imho) that detracts applications and GUI toolkits from SDL
is the fact that it doesn’t yet support multiple windows.How many applications “REALLY” need more than one desktop window
(managed by the wm) ?I think none
Alex
Now I know how you got your nick on IRC.
There are countless uses for multiple windows in real applications. Think
of every GTK application that uses multiple windows. Sure, you could make
them do things themselves, but then you get inconsistency and inflexibility
(I sure would prefer to have E manage my windows where I can tinker with
their properties). It’s as braindead as saying nobody will ever need any
more than 640K of memory. Yeah, there are badly hacked out solutions for
both.Any real GUI application will require multiple windows that are managed by
the window manager for user flexibility, power and ease that it provides.
Even many games would benefit from this.Until that’s possible, any application development of consequence will not
be feasible on SDL. Does anyone really care? That’s a different story.Cheers, Matt
Hi Matt!
Thanks for the professional declaration your of opinon!
BUT…
If you need multiple windows use GTK, QT, or whatever …I think SDL could be very suitable for small (or even
larger
The question was if there was anything stopping anybody from developing
applications, though.
SDL doesn’t just run in fullscreen mode.
And yes, GTK/QT are meant for application development - which really was my
point.
BTW, how did you get your nick ‘solaris’. Any relation
to SUN ?
Of course. I had to choose a nick for a BBS door game (Barren Realms
Elite). I didn’t want to use my ordinary naming conventions (which
approximately equated to random garbage), because everyone loathed me so
much that every game, they’d just slaughter anyoine with a random garbage
like name. I was working with Solaris at the time on an old sparc, it
stuck, and the rest is history.
Because such a workstation you will need when you try to
run SDL multiwindow apps.Just take a calculator and type in:
e.g:
1024x768x3 (or 4) per window
x e.g. 4 windows = ???Quite a lot
n/m
Um. The windows aren’t necessarily all fullscreen. Most of the use would
be for dialog boxes, property windows, etc.
That’s what multiple desktops are for, anyway, eh?
Cheers,
Matt
P.S. Die, braindead, die! (etc)On Thu, Oct 12, 2000 at 11:30:38PM -0100, Alexander Pipelka wrote:
Alexander Pipelka wrote:
The main thing (imho) that detracts applications and GUI toolkits from SDL
is the fact that it doesn’t yet support multiple windows.How many applications “REALLY” need more than one desktop window
(managed by the wm) ?I think none
Alex
Actually, the windowing does have at some advantages. One good one is
better network performance. Have you tried to run a full-screen SDL app
at 1024x768x16 via 10Mb ethernet? it’s a major dog. The reason? every
small screen update forces a full screen update across the net. Those
little embedded windows that gtk uses allow the X server to keep a lot
of that data on the client side.
That said, I think SDL for apps can be very useful. My (work) use of
SDL is similar to yours. It’s a data acquisition and control system.
-Ray
The main thing (imho) that detracts applications and GUI toolkits from SDL
is the fact that it doesn’t yet support multiple windows.Any idea when that’s coming around, Sam?
SDL is pretty poorly suited for windowed GUIs. The drawing model is wrong -
it uses the “direct framebuffer” model where you really would like to have
primitives for drawing and window management. SDL is usually a disaster
across a network, way inferior to any GUI toolkit (even Qt).
I don’t think this can be changed without bloating SDL.
It can still be used for applications where it isn’t intended to be used
in a windowed environment or across a network, like embedded or inherently
"full-screen" apps.
I can see only two real uses for multiple windows in SDL:
First, for game editors where you want to re-use the rendering engine from
the game, to avoid rewriting it for a GUI and so what you see in the editor
is exactly how the game would look like. You can use workarounds like
multiple SDL rendering processes with a single controlling editor process,
or just cram everything into one screen buffer.
Second, as an emulation of multi-screen support. A way to handle multiple
screens will be needed in the future. Right now such setups
are comparatively rare, but they could prove very nice for some kinds of
games (driving and flying games, strategic simulations etc).
Arcade machines with multiple screens have existed for over a decade,
and it is also useful for embedded applications like info kiosks and,
uhm, computer-assisted rocket engine performance tuning instruments
Hiya
SDL is pretty poorly suited for windowed GUIs. The drawing model is
wrong -
it uses the “direct framebuffer” model where you really would like to have
primitives for drawing and window management. SDL is usually a disaster
across a network, way inferior to any GUI toolkit (even Qt).
Can you explain ‘even Qt’?–
C-YA
Jon
P.S. Die, braindead, die! (etc)
/ACTION strangles solaris from behind :))
SDL is pretty poorly suited for windowed GUIs. The drawing model is
wrong -
it uses the “direct framebuffer” model where you really would like to have
primitives for drawing and window management. SDL is usually a disaster
across a network, way inferior to any GUI toolkit (even Qt).
VNC seems to work well enough, and that works on the pixel level.–
“Do not meddle in the affairs of wizards, for they are subtle and
quick to anger.” – J.R.R. Tolkein
I’d like to see the VNC protocol supported as an SDL video output.
Anyone up to the challenge? (I keep thinking about it, but I never seem
to find the time or the bravery
VNC is a very good pixel based thin client (you can get the client for
many many many OS’s), and having it as an SDL video output would
make creating thin client apps very easy indeed (and even games that
didn’t do too much graphical work).
For anyone interested the url is http://www.uk.research.att.com/vnc/
ttfn,
JohnOn Fri, Oct 13, 2000 at 06:50:21AM -0400, QuoteMstr wrote:
SDL is pretty poorly suited for windowed GUIs. The drawing model is
wrong -
it uses the “direct framebuffer” model where you really would like to have
primitives for drawing and window management. SDL is usually a disaster
across a network, way inferior to any GUI toolkit (even Qt).VNC seems to work well enough, and that works on the pixel level.
SDL is pretty poorly suited for windowed GUIs. The drawing model is
wrong -
it uses the “direct framebuffer” model where you really would like to
haveprimitives for drawing and window management. SDL is usually a
disasteracross a network, way inferior to any GUI toolkit (even Qt).
VNC seems to work well enough, and that works on the pixel level.
I’d like to see the VNC protocol supported as an SDL video output.
Anyone up to the challenge? (I keep thinking about it, but I never seem
to find the time or the braveryVNC is a very good pixel based thin client (you can get the client for
many many many OS’s), and having it as an SDL video output would
make creating thin client apps very easy indeed (and even games that
didn’t do too much graphical work).For anyone interested the url is http://www.uk.research.att.com/vnc/
ttfn,
JohnThere is an SDL implementation of the RFB protocol
(simple an SDL clientlib for VNC) available on my
homepage!
(other lib section)Everyone who is interested can take a look at it.
(curr. only available via CVS).Alexander Pipelka
Lead Programmer - BMS Austria
Checkout our OpenSource-Project "ParaGUI"
http://www.bms-austria.com/projects/paragui----- Original Message -----
From: johnm@victoriareal.co.uk (John Marshall)
To:
Sent: Friday, October 13, 2000 1:16 PM
Subject: Re: [SDL] SDL for applications?
On Fri, Oct 13, 2000 at 06:50:21AM -0400, QuoteMstr wrote:
I don’t suppose you’re working on a server side implementation of the
protocol for SDL too? That’s what I’m really after.
ttfn,
JohnOn Fri, Oct 13, 2000 at 01:40:24PM +0200, Alexander Pipelka wrote:
There is an SDL implementation of the RFB protocol
(simple an SDL clientlib for VNC) available on my
homepage!
(other lib section)
SDL is pretty poorly suited for windowed GUIs. The drawing model is
wrong -
it uses the “direct framebuffer” model where you really would like to have
primitives for drawing and window management. SDL is usually a disaster
across a network, way inferior to any GUI toolkit (even Qt).VNC seems to work well enough, and that works on the pixel level.
A lot of people like to run stuff over slower lines (think <=64kbps).
Sit back and think how many bits you need to blank a screen if you
a) have to transmit every pixel of it, b) if you can send a single
XClearWindow request.
Also ponder what bandwidth you need to scroll a terminal window rendered
by SDL
That’s what VNC is all about. It attempts to be smart about how it
transports pixel data, it doesn’t just send raw pixel info, and in
the case of a block fill VNC sends a simple instruction to clear an
area to that colour if the encoder sees that the block it needs to
transfer is uniform. Moving areas are also accelerated as instructions
to the client to move and area it already has to another position
(although I think that needs a bit more collusion between VNC and the
app).
You’re right that X will send far less data, but VNC has much thinner
client requirements at the cost of increased network data and server CPU
usage.
VNC over a modem (using X in 8-bit mode) is actually quite usable.
ttfn,
JohnOn Fri, Oct 13, 2000 at 02:13:17PM +0200, Mattias Engdeg?rd wrote:
VNC seems to work well enough, and that works on the pixel level.
A lot of people like to run stuff over slower lines (think <=64kbps).
Sit back and think how many bits you need to blank a screen if you
a) have to transmit every pixel of it, b) if you can send a single
XClearWindow request.Also ponder what bandwidth you need to scroll a terminal window rendered
by SDL
So in my oppinion SDL is a pretty good Library for game-development. If
you compare game-development with e.g. business-applications you see one
main difference: When games use just a very small set of “widgets”, e.g.
for Text-Input or lists, business-applications need often much more
spcialized widgets. Currently I am using the following approch, with 4
classes in a library I called SOG (Simple Open GUI based on SDL), which
is temporarily not in the state to be released, cos it is too unstable
and I think there has some work to be done, before anyone else should
use it
(1) A base class called SOG
(It is not needed yet, but I want it later to become some kind of a
container class)
(2) A class called SOG_EventQueue : public SOG (friend
SOG_App/SOG_Widget)
This class checks for SDL_events, but implements more functionability,
such as drag&drop events, doubleclicks, etc.
(3) A class called SOG_App : public SOG
This class does “the management”, so it provides the
mainEventQueue-Loop, sets up the display, cares for refreshing the
screen and updating rects, etc. (Yes it is Initializing SDL and SDL_ttf
and it closes them down
(4) A class called SOG_Widget : public SOG
This one contains two functions, to be overwritten : doPaint and onEvent
(); So you can make your widget just like you need it.
I know, that this won’t be a gui at all, but while playing around with
sdl, i found out, that I often need to make my objects like those above,
so I started developing those classes I need to be inherited by my
sprites, my background objects, etc… with SOG
Maybe someone has any ideas, what to implement and what to leave ?
I think it might be ready about next month for it first issue.
If anyone is interested in developing a GUI for SDL (I gave up the
approach, because of the problems, which where discussed on this topic
earlier.) he might want to use those SOG classes as a basement. So if
anyone likes to, just mail me
CyA
Sascha
What about having multiple windows inside of the one SDL window? The
only difference is that you don’t get to see your pretty desktop
background between the windows.
http://www.mongeese.orgOn Thu, 12 Oct 2000, Matt Busigin wrote:
On Thu, Oct 12, 2000 at 08:52:09PM -0100, Alexander Pipelka wrote:
The main thing (imho) that detracts applications and GUI toolkits from SDL
is the fact that it doesn’t yet support multiple windows.How many applications “REALLY” need more than one desktop window
(managed by the wm) ?I think none
Alex
Now I know how you got your nick on IRC.
There are countless uses for multiple windows in real applications. Think
of every GTK application that uses multiple windows. Sure, you could make
them do things themselves, but then you get inconsistency and inflexibility
(I sure would prefer to have E manage my windows where I can tinker with
their properties). It’s as braindead as saying nobody will ever need any
more than 640K of memory. Yeah, there are badly hacked out solutions for
both.Any real GUI application will require multiple windows that are managed by
the window manager for user flexibility, power and ease that it provides.
Even many games would benefit from this.Until that’s possible, any application development of consequence will not
be feasible on SDL. Does anyone really care? That’s a different story.Cheers, Matt
SDL is pretty poorly suited for windowed GUIs.
On the contrary, it depends on the platform.
Using OpenGL for 2d applications can make for
beautiful, hardware accelerated, windowed GUI's.
Raster, (of enlightenment fame), has hinted that
a future version of E may depend upon OpenGL support
to handle rendering. Then again, Raster does live
in the fantasy land of VA. But I think you might
beable to see where I'm going.
OpenGL draws your polygons = widgets, antialiased text,
etc, and all you have to do is worry about your event
loop, (which you'd have to do if you were writing
raw X without the Gtk or Qt anyways :)
SDL is usually a disaster
across a network, way inferior to any GUI toolkit (even Qt).
I don’t think this can be changed without bloating SDL.
This is purely a matter of RPC, the SDL needn't even
know about this. Write a client/server app, install
the SDL on the client machines, and do all the processing
on storage on your cluster of servers in the back room.
Don't use X to transfer windows of contents down the
pipe, send only the data needed by the client to draw it.
In the case of human data input, it is already on the
client.
But yes, running and SDL app over the network is bad
in traditional X style... but then again I wouldn't think
of running Quake like that :)
Second, as an emulation of multi-screen support.
It is handy when you actually have multiple screens too :)On Fri, Oct 13, 2000 at 11:23:37AM +0200, Mattias Engdeg?rd wrote: