[Guitarix-developer] guitarix/libgxw brainstorming thread

[pete <psh...@gm...>]

these are just some ideas for libgxw / guitarix that might be worthing
thinking about.

Image cache
-----------
if we roll our own image cache instead of using the gtk icon backend,
we would gain more flexibility. in particular we would be able to cache
scaled and recoloured images. (i previously suggested that adding
scaling support would be trivial, i was wrong. since we don't cache
anything outselves, we would currently need to rescale every time we
draw inside the render loop)


Animation object
----------------

if we break out the animation handling into it's own object, and keep
some convenience functions there, adding animation support to other
widgets would be simpler and achievable without so much code
duplication. perhaps subclass GdkPixbuf.


Widget names
------------

use widget names to assign themes instead of subclasses and the stock
id. these could be set on creation to create arbitrary new style
groups.


Expose plugins and layers
-------------------------

if we created a simple plugin api for expose handlers then load one or
perhaps more of these (in layers, effectively) then the appearance of
the widget would be governed by these plugins. a similar system is in
use in gtk (theme engines)
we could specify which plugins to use via the gtkrc in much the same
way. i suggested this for phat a while ago but quickly abandoned the
idea as i thought we would need to implement a complex markup language,
but it occurs to me now that each plugin could take it's configuration
options from the gtkrc, again just like the custom theme engine options.

for example, lets say we implemented a knob widget with these render
"layers".
each to be drawn consecutively, with the output from the last, fed to
the next. the plugins to use would be assigned by the gtkrc and the
plugin options provided inline in the gtkrc and parsed by the expose
plugins own parser function. this is then a kind of meta widget that
draws nothing by default unless directed to do so by the contents of the
gtkrc.

now, say we had an animation render plugin and a simple vector plugin
(cairo) we could write a gtkrc that would load these two plugins in the
first and second render layers. the first (vector in this case) would
draw some dial marks around the knob, then the second would draw an
animation on top, before the final composited image is drawn to the
window by the meta knob, completing the render loop.

clearly the vector markup could be arbitrarily complex, but since these
are plugins, there's nothing stopping us from writing simple vector
plugins that take either none or very little input in the form of markup
instructions, but fulfil a specific task. EG: panpot stereo index marks,
a positive range of index marks or a circular gauge. a sort of library
of useful rendering components that could be combined as needed.

third party applications making use of the libgxw and users themselves
could then write their own expose plugins and attendant themes without
having to touch libgxw code (or even the third party code itself really)
the end result is a hybrid widget that can make use of different drawing
methods at once, bypassing some of the traditional limitations of each
when used alone.
(pixmap, vector, potentially even 3D rendered)

clearly this is an ambitious idea. whether it's enough to abstract the
expose handler only is something i've not sat down and worked out yet.
there may also be show stopping problems with this idea that have yet to
occur to me.


gx_head
-------

firstly, i'm not going to try and impose my UI preferences here.
obviously these suggestions do reflect those preferences, but they are
just that, suggestions :)

perhaps use glade or gtkbuilder for the layout?

put the entire gx_head window in a scrolled window. default to the full
size with no scrollbars visible. this will allow the app to at least be
usable with smaller screen resolutions. perhaps a "small" theme would
be useful here too.

combine the mono and stereo racks into a single pane. re-task the left
hand pane as a preset and effect browser.

include a mandatory mono output panel in this new global plugins pane.
require that all plugins that precede it are mono. any mono
plugins placed after it are automatically initialised as stereo plugins.
(with an optional warning that this is happening)
perhaps this could be further enhanced so that mono plugins are only
forced to stereo if either their input or output is stereo.

include an indicator on the plugin to show whether the plugin is mono,
stereo or "forced stereo".

make the main "head" window somewhat smaller with smaller widgets and
include a button bar with some common options that are currently only
present in the menu.

include a master output knob control. i had no idea i could do this via
the red indicator on the VU meter until i read it on the forums so i
don't think it's intuitive enough.

there we go. i'll add more ideas as they come to me.

pete.