Re: The concept from MUI (Amiga)

["D.Adler" <plex flynet de>]

Raster wrote:
> ->
> ->  This means many widgets will be build on top of a bunch of styles. So
> ->  the visual configuration
> ->  will be that each style has a specific configuration window for his
> ->  style, and the user
> ->  will set the values very fast to new widgets that are build on these
> ->  styles.
> 
> good ideas (eg if you have a wood grain texture it just inherits the
> same texture positioning et.c in the child widget).

This also means, Frames, Buttons, Notebook, Toggle-Switches ... all they
have
a Borderstyle. This Borderstyle has two main differences - textured
themes or
drawing styles (like in postscript you could implement a
zig-zag-comic-style
border as your personal buttons for example) -
I donīt know how to make it real "border"-sensitiv to events. Any ideas
?
perhaps the shape-extension could help ? (i donīt know at the moment)

So widgets are a set of styles or specific graphical "hard-coded" stuff
like
sound-equilizers. So the configuration goes :

1. choose a specific widget-class out of the list (button,
toggle-button, tooltip...)
   2. list of styles that are implemented in this widget-class,
choose...
      3. configuration of the style (code is in the style-class)

and every tool should get a signal to rebuild on the top of the new
configuration.

and thats what the standards are since 1993 on amiga :) and it shouldnīt
be forgotten,
it even more should be conserved to linux :)

> 
> ->  The next step is to give normal users the ability to change the look ( &
> ->  feel ?)
> ->  with a visual tool. This should take a central position in the whole
> ->  concept.
> ->  Every new widget should have a "config callback"-like section
> ->  implemented.
> ->  This means, a programmer writes a new widget with this section,
> ->  describing
> ->  the possible configurations, and the user can configure the look
> ->  and feel. Think of a "cd-player" widget. You install it, and the next
> ->  step
> ->  you will do is, calling GTK-MagicConfig (example name :) ) and select
> ->  the new
> ->  widget-class and you get a specific config-screen for this widget, done
> ->  by the
> ->  widget-programmer.
> ->
> ->  After configuring, every gtk-application should look new.
> ->
> ->  Another thing to do, is that all tools should check a central
> ->  configuration file.
> ->  (for example .gtkrc in $home) so that new installed tools will always
> ->  look like
> ->  the user configured his GTK to default. But any specific tool should be
> ->  reconfigurable to
> ->  another look.
> 
> Yup.. thats the idea.. the theme/settings are "global"

ofcourse, you as the user once decided to tell how your applications
should look like,
and after that every gtk-tool (gnome-tool) will present its
user-interface in this style


> 
> ->  I hope to help with this project, especially bringing more power in GTK.
> 
> Well what needs to be done is 1. all drawing functions extracted out of
> all widgets in gtk into a separate library (.so) - this means per
> widget we'll probably need:
> 
> _int
> _destroy
> _draw
> 
> functions - per widget (lets not discuss the init function that gets
> claled in gtk_init - we can assume thats obvious). on dynamic theme
> change all widgets have a destroy fucntion called (this onyl destroys
> the theme/drawing paramns) then new functions are loaded into the table
> and  init and draw is called again. - but thats dunamic.. lets just
> leave that alone for now.

i just wanted to start writting a new widget called button2 as a
test-bed to implement the
first real styles and to have it seperated

> 
> all gtk widgets need their drawing code cleaned up so there is only 1
> drawing function and it is the onyl drawer called for a widget (unlike
> the current case). then we need to take all gtk's currrent drawing code
> and put it into a nice fat .so and thta is the "gefault gtk" theme - we
> then need to build as you suggest above a new .so that provides extra
> functions.... this can be bult out of the "default" gtk .so drawer
> theme. This si a reaosn I'm working on Imlib so it's ready to be put to
> this functionality.

hmm... i thought more about implementing a complete set of different
draw-styles
into one .so and the current look of the buttons e.g. are exactly one
specific style 
(for example the default theme) - so you havenīt got many .so for each
style, more
you have a real tool-kit for the visual experience - the themes support
will be completely
done in the borderstyle-configuration , there you will have a
config-frame where you can
load for each corner a specific pixmap (tiled, streched,
aspectratio-streched) or
you select a drawing-style ... 

Ofcourse, styles must be modularizable, so that i can extend GTK later
on with a little .so
that holds new widgets and styles that doesnīt exist.

> 
> ->  Iīm coding in C/C++ on Linux/Intel.
> 
> Well we need people to actually code stuff. I will get to this pronto
> once imlib stuff is settled. If you wish to start I'd be glad to help
> and work with you.. it is going to be a mammoth task to extract all the
> drawing code... and thats not accounting for being able to rearange
> widgets like scrollbar arrows etc.

I know, well if you are interessted, captain bifat/tek is actually
coding the render.library
and guigfx.library on amiga in assembler/c - it is a fantastic thing, it
makes all the
renderstuff as fast as possible, with dithering , texture-mapping as
fast as
ever possible on 68060 - we thought about porting the assembler 68060
code to c, but he
has no time at the moment and it could be very tricky - if you are
interessted in techniques
he used for his libraries contact him (at our homesite
http://tek.flynet.de)
the intension for this was the same like your imlib, therefore many
tools running now with this,
think of a 3d-cube-pictureviewer where you drag-n-drop picture-icons
that are loaded via datatypes
as textures on the cube in realtime, with fully-sizesensitivity to the
window.

Ok, raster, i hope we can this huge project starting. 
I will get more detailed in gtk in the next days, and i will think about
the implementation 
of styles... perhaps you have any ideas


-- 
so long,
plex/tek