Re: The concept from MUI (Amiga)

[raster redhat com]

On 17 Feb, D.Adler shouted:
->  Hi GNOME people,
->  
->  i have decided to join GNOME. I am very interessting in making a very
->  flexible
->  and good GUI. Therefore I started Nirvana some month ago, but I will
->  drop it
->  for now and try to implement ideas in GTK.
->  (http://tek.flynet.de/linuxsite/nirvana/phase1.html)
->  
->  I started configuring GTK with the rc-feature, and there i got the first
->  problem.
->  All borders for buttons and other widgets are very static. A border
->  doesn´t
->  have to mean only one draw style. I thought about the concept in Magic
->  User Interface


Good.. somone who knows what I'm getting at... :)

->  on the AmigaOS. There you have a set of 8 or more draw-styles and you
->  can equip it
->  on any widget. So my idea goes in direction of hierarchicaly designed
->  widgets and
->  their styles.
->  The gtk-rc is therefore not so flexible for that.
->  Themes like from Raster are also very cool, but it should not be the
->  only possiblility.
->  Here is a little Style-toolkit, i thought of...
->  
->  Colorstyle:
->   -
->     - RGB color
->     - Pixmap,
        ^^^^ tiled (integer tiled, stretched to fit)
        
->  (- Alpha-channel value to parent ;) )  
->  
->  Backgroundstyle:
->   -
->     - Colorstyle
->     - from_parent Flag
->  
->  Fontstyle:
->   - specific font
->   - different FontDraw-style (graved, shadowed, glowed...)
->   - Colorstyle

+fontrenderer (gdk supports it vaguely - just there is no other fotn
renderer apart form X right now - used for anti-aliased or color fonts)

->  Borderstyle:
->   -
->     - BorderDraw-style (normal, rounded, beleved ...)
->     - Foregroundcolor, Backgroundcolor for Draw-style
->   - imlib border (a la themes)
->   - Backgroundstyle
->  
->  Label:
->   - Fontstyle
->   - Backgroundstyle
->  
->  Button_with_label:
->   - Borderstyle
->   - Label
->  
->  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).

->  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"

->  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. 

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.

->  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.

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/