Subject: Re: [linux-audio-dev] ladspa GUI proposal
From: Karl JH Millar (kmillar_AT_MIT.EDU)
Date: Tue May 30 2000 - 20:50:33 EEST
To clarify a few points:
The intention of my proposal is certainly not to make plugin GUI writers use
Xlib entirely in place of a real widget set. That, as Paul points out, would
be horrible beyond belief. (I called Xlib a toolkit by mistake, which I think
caused confusion.)
What I'm thinking, is for there to exist an agreed upon set of widgets
available for plugins to use, and that this set should be sufficient for most
plugins (ie provide sliders knobs, buttons, geometry management etc). This set
of widgets would then make up a simple, portable toolkit, which is easy to
use. If a plugin desires or needs to go
*beyond* this and needs to create their own widgets, or customise the look
of existing widgets, then we provide a structure based on Xlib where this can
be done so that it's not tied to a particular toolkit. That need not be worse
than writing a widget for a specific toolkit. (After all, gtk+ widgets are
written using gdk, which is not *that* much nicer than Xlib.)
The main disadvantages of this scheme then are:
- we need to come up with a reasonable set of base widgets
- customised widgets only work under X11. Ordinary ones work under
anything.
- we need to define an interface between the plugin's Xlib using
functions, and the host
- it would be hard for people to add pre-existing toolkit widgets
into a plugin (although for some toolkits it is possible via
a bit of hackery)
- custom widgets won't follow all the conventions of the host toolkit
The advantages on the other hand include:
- toolkit independance
- easy to use for the majority of cases
- allows host control or chrome at the host's choosing
- allows arbitrary widgets to be created and used (eg eq curve editing,
oscilloscopes)
- allows pixmap usage if desired
- could be implemented either via XML or a C api
Does this sound more palatable?
Karl.
(Warning: The rest is a moderately off-topic rant on why I don't like heavy use
of pixmaps in applications in general, in response to Paul's question. It's
strictly personal opinion of course, and should be freely ignored.)
The main reasons I dislike pixmaps is because of their inflexibility. The
colours and size of a pixmap cannot be easily altered. As a result, they tend
to be either too big or too small depending on your resolution, or get scaled
and become blocky. There's not much chance of a pixmap solution working well
with a user's preferences for anything; colours, shapes, sizes, fonts etc.
XMMS is a good example of these problems. It uses a pixmap titlebar, instead
of the window manager's one, and so the buttons on it are different shapes,
positions and functionality from *everything else* on my screen. The shapes
I could change, but not the other two. Similarly, at normal size,
everything is illegibly small on my system. At double size, it's blocky.
The default colour scheme looks terrible on my screen, and I'm stuck with it
unless I download a new skin. It even clobbers my (8-bit) colourmap.
With a non-pixmap solution, it becomes possible for the user to specify
colours, sizes, fonts etc, allowing the user to ensure that everything looks
good if the defaults don't. Pixmaps don't allow that. To be fair, some effort
needs to be put in to ensure a Xlib solution allows this too, but it is at
least possible. A good toolkit of course fixes these problems naturally.
This archive was generated by hypermail 2b28 : Tue May 30 2000 - 21:15:25 EEST