AltME groups: search

The worst thing we can do is to let the option there, while not acting 
upon the override. So - if we REALLY want button's size to be fixed, 
the option really has to be removed, and it has to fail on GUI parse 
...

From Max: "I don't want to post stuff from other engines here since 
its not a comparison game, but I've used many APIs from prbably 20 
different dev platforms, and everytime I use one which has an "unwielding" 
ideology where you can't modify things to make them do what you want... 
as a user, I get frustrated and I just look for something else to 
do and/or work on."


And I say - Amen. Set it into stone, and you might wonder in the 
end, why you have no following. It is exactly the same reason most 
ppl are not able to understand, that no matter how logical it is 
to have the skin done as a last, R3 GUI did not get any following, 
because of the first look experience simply get's users not interested 
at all. And it was said here not jus by me. You can protest, but 
that is all you can do about it.

view [button "ok" options [max-size: 200x200]] - does not work. Simply 
imo max-size is not part of the options block, only the init-size 
is ... And - I want it being part of the options, so that I can set 
it inlined, or in options [] block. If not there, it is more complex 
hack we wanted to avoid imo ...

I thought about the possibility of VID aproach - having button, and 
btn style, one of them could resize. But my experience is, that those 
two did not mix well together, mainly because the visual difference. 
 And if I adapt the resizable one to look the same as non-resizable 
one, I don't need the latter ...

Nothing in R3GUI is one sized. There is max-size (and min-size) limit 
and we can debate if the max-size is big enough or not, but you cannot 
say that big red button is not possible in R3GUI, because that's 
simply not true.

aha, that is another thing to understand. When I looked into button 
source, I found there 'options. I thought that those options describe, 
what parameters I can set inlined. And it may be correct. But - now 
we have layout level word 'options, which is completly different 
thing :-(

To have it aligned, we would have to have:

view [button "big" facets [init-size: 100x100 max-size: 100x100]]

Or just reverse the meaning in the style:

options: [
		init-size: 130x24
		text-body: "Button"
		text-style: 'button
		max-size: 230x24
		min-size: 80x24
]

facets: [
		text-body: [string! block!]
		area-color: [tuple!]
		init-size: [pair!]
		wide: [percent!]
]


Simply calling style attributes 'options, and inlined settable parameters 
calling 'facets ....

discrepancy in the naming

 - you're right, most of the names are from old R3GUI and may not 
 be descriptive enough. I hope we can change it with your help. OPTIONS 
 in layout is used to override FACETS which may seem confusing.

exactly. But the tricky part is as follows - I like having 'options 
in the dialect level, and I am kind of used to have to call style 
attributes a 'facets ..... I would have to think for a while, if 
we can accept following convetions:


- options - used to set style properties, either in the style itself, 
or in the layout dialect

- facets - special purpose properties, which can be used inline in 
the layout level


I think that it would work for me, and that we would have it aligned 
nicely that way. I am just not sure Carl or other guys are ready 
to give-up on facets name being a general attribute/property of the 
style :-)

Henrik - don't even try the old crap on me again :-( The reason why 
Carl started new GUI was because of Gab's GUI was not all that easy.


Henrik - I believe you will fail explain technical reason, why it 
prevents proper skinning


An exact failure in understanding why face hacking is not welcome. 
Gab's GUI was not easy due to a number of layers needed to describe 
the look and feel separately, as well as requiring you to handle 
GOBs manually. But it supported applying proper meaning of styles, 
because Gabriele had the same goal as me. Carls does too and RM Asset's 
does this even more. We just have to take advantage of it.


Have you never had to fix someone's MS Word document, so that TOC 
generation, links, indexes, headlines, etc. could be understood by 
Word, because they had resorted to manipulating the words directly 
with colors and style, instead of using Word's style system? This 
is exactly the same problem. You will be teaching beginners that 
their layouts won't scale properly for exactly the same reasons. 
Many people therefore never really learn to create correctly formatted 
Word documents.

Henrik - what is the difference in not not providing option to set 
a button size, yet like Rebolek showed us, it can be done in the 
options block? I mean - what is the difference for the skinning system? 
And also - button is a rather promitive widget, we don't allow its 
sizing, yet more complex styles as panels can be sized, skinned most 
probably too?

I don't want to hack styles in the R2 way, going style/path way. 
I can see, that those layers are wisely designed, but not allowing 
any size button is imo oversight, and it does not imo break the rules 
you describe in your MS Word TOC example. User is simply not hacking 
it. All I wanted was to "export" max-size, not the init-size.

The right way to do big button is to use stylize and make your own 
big button. You definitely not want to go thru your code at some 
later date and change all 100x100 to 200x200 for example.

that's rather easy, but not easy enough. Still a different concept. 
You guys act like button is a text, and it is not :-) If I will have 
whole screen of the same buttons, I might use stylize, e.g. for the 
calculator widget, as an example, becuase constantly repeat button 
30x30 is not convenient for me. But it still does not mean, that 
ocassionally wanting to have button a bit differently sized does 
a damage. Do you think users are crazy and will make each button 
differently sized, just because they can? :-) (Well, as for MS Word 
files, some users are able to create completly twisted texts, bu 
still - that is a text, difficult to restyle ... while we are talking 
GUI here.

Yes, CSS allows this using STYLE, and it gets painful, when you start 
doing that, riddling HTML with CSS code. The reasons are the same 
here by avoiding to apply proper meaning to the HTML code, when using 
STYLE.

So, I had a look at BUTTON source and button has init-size in options, 
so this is bug and [button "BIG" 100x100] should work. I will fix 
it.

I would like that the finished doc style supports images, tables 
and enough features to allow direct rendering of MakeDoc documents. 
This should simplify creating a documentation system, where we don't 
need to rely on browsers, when using browser-less platforms.

I think that basic DOC style can be really simple and that it just 
will parse makedoc format to R3GUI layout.

Hah to defining large subprojects and expecting someone else to do 
them

Henrik - there's no why imo yet :-) From my POV it is very preliminary, 
and I would orientiate myself to:

- adapting existing styles to new R3 GUI engine

- adding styles most commercial guis will need - table, tree, tabs

- be sure all styles behave in a platform compatible way (especially 
area)
- reskinning/respacing the elements

- add support for ctrl-tab at low level to switch between the tabs
- fix all hard R3 crashes

later:

- add support for accelerator keys, but visually, and in the code 
(requires rich-text, most probably autogenerated, to underline the 
letter, but it could be done a different way to - e.g. displaying 
boxes with accelerator keys upon the styles and Alt key press)

- improve the text quality, that is NOT ACCEPTABLE for the 21st century!

even later:

- add some funky styles as Doc to make documentations, wikis, etc. 
:-)
- HW acceleration support where possible.

I just have to make my notes to the "button size" thread:


- "We can't easily make 50x50 button for e.g.?" - you can, just respect 
the fact, that every face has got a Max-size, and if you want to 
make something bigger, you need to specify the Max-size

- "you have init-size as an option, yet it is ignored,or totally 
twisted" - it is a resizing rule, that you can resize everything 
only to the Max-size limit; of course, you can make the Max-size 
bigger, but, if you forget, nobody can be cleverer than you are knowing, 
what is the Max-size you want to use

- '   view [button "ok" options [max-size: 200x200]]' - of course 
it works, allowing you to resize the button as specified

- 'So, I had a look at BUTTON source and button has init-size in 
options, so this is bug and [button "BIG" 100x100] should work. I 
will fix it.' - only over my dead body, the basic resizing rule is 
to respect the Max-size

Now there is init-size, and my opinion is, that it is confusing, 
if the init-size is possible, yet it does nothing obvious. In such 
a case, I prefer to error-out at layout level, not allowing even 
init-size being specified inline ...

But current behaviour, where you can write [button "text" 100x100] 
and button hapilly ignores that value is unacceptable IMO.

So my proposal is:
remove init-size [pair!] from Options

add [init-width [number!]] and use it for changing the init-size/x 
value only

Brianh - that was EXACTLY my idea, and it contradicts nothing ...

No, also it is on the style-maker to define what should be done with 
the inline pair! so it depends always on the style implementation 
and not as generic rule.

I do not expect that every user that will write [button "text" 100x100] 
has studied source or documentation to understand how resizing works 
and what max-size mean, they probably just want to have their button's 
size to be 100x100.

So either the code should set all size to 100x100 or it should throw 
error and not allow setting size like this at all.

While Cyphre and I are fighting for that same user a few minutes 
later when they need to make a change :)

And skipped over what I wrote earlier, and later.

and the winner is?

and because Ladislav doesn't like #2, we should probably go with 
#1.

To be fair, we could say, that if I specify button 5x5, what to do 
then? Should min-size be set to min(init-size, min-size)? What if 
user is an idiot, and sets the size to -5x-5? :-)

I still don't understand the difference between these two:
button 50x50 options [max-size: 50x50]
and
button options [init-size: 50x50 max-size: 50x50]

Guys, I just read through all this and I'm confused a bit why it's 
so complicated.

Bolek ,ok, then let's remove all the inline pairs! and tell the 'average 
user' there are no sizes. Do you think it will be better for him?

definitely better than setting size to 50x50 and having button whose 
size is not 50x50

If I write: button 50x50 and don't violate min-size, max-size OK. 
If I violate one, we can throw an error: "Hey, please explicitly 
override the master-mind of the style-creator for min-size / max-size. 
And know what you do.

min / max-size are IMO for style writers first. And can be overrided, 
with a not so easy syntax, by programmers.

I am OK with min-size and max-size being a little harder limits, 
if the reason they are in the style is because of hard visual limits 
(size of contents and such). The limits on the size of button seem 
a little arbitrary at the moment though. Then again, I keep reading 
articles about applicatons and web sites not working on different 
form factors because of hardcoded limits in their layouts, when their 
styles should be adaptable to match the form factor. This is why 
we are trying to cut down on this stuff in the layout dialect.

I surely don't want min/max limits to be removed - they are imo usefull, 
and needed for resizing model to work ... I wanted to solve the case 
when you specify init-size out of bounds ... Robert's solution looks 
ok to me ....

Think of the layout dialect as HTML with no formatting, and all of 
the formatting in the CSS. Does that make sense?

Cyphre - you misinterpret me a bit - on one hand, yes, I think those 
are usefull to have for occassional GUI hackers, for the fun factor. 
If user is an idiot, and wants to define each button differently, 
so be it - there is analogy with inline CSS style. But if we allow 
it, the behaviour should deliver it ...

Robert - the problem was with the demo - I ported button, specifying 
50x50, but it gets not used, as the max size is 24 on Y axis. So 
I was confused, and though that something does not work. The result 
is in agreement with how the system is implemented, but anyway - 
we will get "huh, what?" and ppl being confused, if we don't adress 
it somehow ...

And if min-size: 1x1 and max-size: 21177172727x217722172727

if min-size: 1x1 and max-size: 21177172727x217722172727

 ....then your button will have tendency to resize to monstruous sizes 
 in the layout.

I agree with Robert - style defines init-size, max-size, min-size. 
Just predefine max size to cover at least fullHD resolution, and 
be it :-) The button will still be properly sized by init-size, if 
user does not override it?

I thought there is a strategy to the sizing, and that styles somehow 
have some sizing tendencies ... I remember some spacers, etc., but 
dunno how new resizing is implemented ...

Anything else is exotic and should be explicitly overriden by programmer.

There was also one proposal, to rename options/facets:


- the naming is reversed - in style, you use options for inline parameters, 
whereas in a layout, you use options to set facets


- I understand Carl and maybe others would not like to give up on 
facets being a name for properties/attributes, but ....


- I proposed to rename it, so that options in a layout = options 
in a style, and for inlined style definition we could use facets, 
or inlined name.

What do you think about it?

And IMO this approach fits with Henrik's wish to restrict things 
(which would be through the default values) to save you time and 
hassles. If you override it, well do it, and take the whole responsibility 
on your own.

It seems that buttons can be freely sized within their limits. So 
the question is what are the default limits and why?

Would it not be better to focus on flow and how a style will fit 
in a cell, rather than impose the size of the button on the button 
itself? We are used to assigning size to the button directly instead 
of posing restrictions on its surroundings, because that concept 
did not exist in VID.

Brian, correct. Pekr, either you as user will understand and agree 
the rules or you need to lear a bit more and become 'style tweaker'.

Pekr, there is talk, you report bugs and there is response. That's 
the effect I wanted to see.

They are important to discuss and you will not get every wish granted, 
but it's only a matter of seeing the big picture of things.

So, instead of on an individual control basis (like old Delphi) sizing 
is done on a grid model (like new Delphi), the change coming about 
for the same reason Delphi changed that: Ease of development and 
maintainability?

Half the computers I use are connected to 2 screens: the main one 
and an HDTV. Ususally not the same resolution. And some of the connections 
are occasional rather than persistent.

Regarding the relations between Init-size, Min-size and Max-size:


1) it is possible (using resizing) to specify any size at any time

2) the size specified is used for resizing, but, the Min-size and 
Max-size values (specified either by the style designer, or, eventually 
overridden by the user) are always respected, not triggering any 
error, if the user tried to resize "out of bounds"; instead, the 
limits are just used to keep the size "in bounds"
3) only the ones not knowing the resizing rules may be surprised

In my opinion, using a style, the user "automatically" agrees to 
the Min-size and Max-size as specified by the style designer, unless 
he adjusts the values as he sees fit.

The problem is that a user doesn't see what he is agreeing to, as 
it is elsewhere in the style. *All* users will be surprised because 
they initially don't know the resizing rules, and not getting hints 
is not a good way to learn them

when a concept of default size is there, that is usually what you 
want the pair to be.  when it goes beyon min or max bounds, usually 
you want to push these to at least match the default size...   the 
developper is expressly asking for an adjustment to the default.


the thing is that when a widget is in an auto-resizing layout, asking 
for 100x100 might not actually give you that size, because all the 
widgets are subject to the layout in which they are displayed.  in 
row/columns, you will be subject to equalizing other lateral sizes 
in the list and may be given more space in the longitudinal size, 
such that in fact, your button may be larger than what you asked 
for.


the only way to force a 100x100 button is for the gui to support 
static sizing within a dynamic layout, or support max-size and set 
it to the exact same as default size effectively making it a static 
sized button.

You can write preprocessor that will convert every [button "text" 
100x100] into [button "text" [min-size: 100x100 init-size: 100x100 
max-size: 100x100] and that's all. But there's strong opposition 
to having this directly in dialect.

You can write preprocessor that will convert every [button 

text" 100x100] into [button "text" [min-size: 100x100 init-size: 
100x100 max-size: 100x100] and that's all. But there's strong opposition 
to having this directly in dialect." - it is certainly possible to 
have such "statically sized" style, but that is not what the majority 
of users would need

Glass, for example,  just makes you get *at least* that space and 
won't change the resizing model of the style on its own... you have 
to ask it manually to become static by using other switches.

and frames use pairs for margins.

maybe it can be done using some kind of option, for example [button 
"test" 100x100 #and-i-really-mean-it]

in GLayount, max-size is sort of automatic.  there are two sizing 
values, one for filling, one for stretching. 


its very effective in making sure that only things which benefit 
from extra size, actually get it, and makes everything neatly aligned 
with virtually no need for any manual sizing control in the layout.

There currently is only one Frame resizing model (which works in 
X or Y).   though in fact, one can tweak the frame's default decisions 
in substyles.


this has been done in the scrollframe which uses a sub frame dynamically 
and renders a bitmap then uses the bitmap in the display.

when I say static size in GLass, it just means that it doesn't fill 
the space.   things still align and stack up automatically within 
the frame.

Proper alignment of elements along font baselines sounds like it 
_could_ have a deeper impact and requires some planning.

I agree that precise use of the baseline should be doable.  its the 
only way to properly handle multi-font display.  it would also be 
nice to be able to inspect the font so that we can measure the different 
metrics of a font.


x-height, descent, ascent, cap height, linegap (leading), H space 
width, etc.


On the Amiga, I used to align text with these values in code and 
it seemed to be much better.

Panel resizing user poll:

Background information:


For resizing purposes, every graphic element (including panels) has:

INIT-SIZE, MIN-SIZE and MAX-SIZE dimensions:


* INIT-SIZE is the size that is being resized (magnified or minified),

* MIN-SIZE is the smallest possible size of the element after resize,

* MAX-SIZE is the largest possible size of the element after resize.


Until now, we used auto-sized panels, for which we always (after 
every content change, like insertion of a button, etc.) recomputed 
their INIT-SIZE, MIN-SIZE and MAX-SIZE based on the sizes of the 
elements the panel contained.


Currently it looks, that there are many reasons, why it may be better 
to *not automatically recompute* INIT-SIZE, MIN-SIZE and MAX-SIZE 
after at least some of the possible change types.


Therefore, we introduced a non-auto-sized panel, which auto-computes 
INIT-SIZE, MIN-SIZE and MAX-SIZE on-demand only.

Our questions:


* After inserting a button (or other contents), what do you think 
should be the default action - recompute all the above values, or 
not recompute any of the above values?

* How to specify a non-default behaviour? Cyphre came with a proposal 
to use a /UPDATE refinement accepting a WHAT block, so, e.g. /UPDATE 
[MIN-SIZE MAX-SIZE] is required to update just the specified dimensions. 
Would you find a different alternative more convenient?

The outcome of the case not recalculating INIT-SIZE, MIN-SIZE and 
MAX-SIZE would be, that the panel would try to occupy the same space 
as before the change. That may be what the user wanted, if he had 
a specific idea, how large the panel should be, regardless of the 
contents he might add into it later.


The outcome of recalculating INIT-SIZE, MIN-SIZE and MAX-SIZE (on 
the other hand) is, that the panel dimensions are auto-changed after 
almost every change. It looks especially "ugly" in case dividers 
are used to change panel dimensions, since if you change the X dimension, 
and later the Y dimension, due to INIT-SIZE recalculation, your former 
change may become totally ignored.

%trunk/r3-gui/source/panel-make.r3 and %panel-sizing.r3 committed. 
Changes:

- SPACING initialization moved to the INIT-PANEL function

ok, so let's think what does it mean? Because - most of the time, 
I use maximized windows, so:


1) for maximized window, if there is an area - let's think above 
message pane in Altme for e.g., if I insert new button there, there 
is no place to enlarge the panel to, so what happens? Do panel scrollers 
appear? And if so - am I kept at the beginning (top-left) of the 
panel, or am I scrolled to the location of last inserted element? 
Please note, that those concept are relevant for grid/table navigation, 
etc., it is just similar


2) if the window is not maximized, and panel is about to be resized 
- is window enlarged automatically?



So PANEL ENLARGEMENT preferred behaviour (note - say nothing about 
auto or manual update preference though):


If I would be for the auto-update, what I would probably hate would 
be if the size/position (let's think of always centered window) of 
the window would be automatically moved.

PANEL SHRINKING:


So - what should happen, if you remove elements? The same as above 
apply? Does the whole window shrinks? Or just scrollers get eventually 
removed, or the panel is simply smaller, whereas the window remains 
to be sized as-is?


As you can see, I need an answer to above questions too. It is all 
about what is the most pleasan vs unnerving to use. And it relates 
to what happens to Window, not to panel, that is just secondary question, 
if it stretches automatically ....

I can see following possibilities:

PANEL ENLARGEMENT:

- panel is not enlarged, it adds scroller

- panel is enlarged, but it does not affect window - window adds 
scrollers

- panel causes enlargement of the window (hence window moves, and 
we should be carefull, because new size of the window does not need 
to fit to the screen - it is a special case)

PANEL SHRINKS (content removed):

- panel just stays as is, eventually removes scrollers

- panel shrinks, to fit its content, but window remains of the same 
size

- panel shrinks to fit the content, window shrinks to fit the panel

All above plus the combination of auto, vs manual

example: if a (maximized) window contains two panels, and you enlarge 
the init-size of one of them, leaving the other as-is, the proportions 
change, and the panel with enlarged init-size will become greater

if the window is not maximized, and panel is about to be resized 
- is window enlarged automatically?

 - that depends - if the window INIT-SIZE does not change, its actual 
 size does not change as well

As you can see, I need an answer to above questions too. It is all 
about what is the most pleasan vs unnerving to use.

 - frankly, you can at least try the examples provided and see what 
 happens now; and, eventually, present your observations here

I still miss simple style to group things. I always wanted a panel, 
with border, gradient, etc., but then also exactly the same style, 
but with zero visuals ...


IIRC, in Carl's GUI, it was panel vs group - except the fact, that 
it group used opposite coordinate system - very unwise btw


In RMA's GUI, if I am not mistaken, group is internally completly 
different - it is here for those users, used to VID2 - you have to 
use RETURN keyword, it does not align in grid cells, etc.


So - how do I easily define inline style, which removes panel visuals? 
I don't want to create new style for such a simple and usefull thing. 
And I start to think, that 'group style is here just to confuse users 
...

Per, look at TIGHT, it's variant of PANEL that serves some of purposes 
you want and it's done using just redefining some facets, so you 
can make your PANEL variant based on it.

Pekr: looks, that you will get more examples from Cyphre, who promised 
to pack some and make them available. So, I am afraid, that at the 
time being, you only have the examples from the gui-panels.html text 
available.

Yes, it can be compared, events are handled by event-handler and 
on-* actors are called in appropriate face(s).

In JQuery, it's called bind() and unbiind()

GrahamC: the event does not necessarily have to be "consumed". In 
REBOL, we simply have events, and you can always return just the 
same event when processed by our handler. Remember insert-event-func 
from R2? You could create transparent event filters ...

We need the ability to create events, and we should also be sure, 
that we are able to obtain modern events, as e.g. above mentioned 
FF4 can now handle multi-touch native Windows 7 event. And we are 
not even receiving such things as ctrl tab for tab handling. What 
I still don't understand is - the system port? Is that port still 
available in R3? And what was it good for? It would be e.g. nice, 
if by opening the system port, you would insert such a listener to 
the OS event model, registering for particular events. Well, that 
might be slow, if you are not carefull, but that way you might be 
able to receive any system event possible .... but not sure it is 
even possible :-)

Yes. I haven't got use for it yet, so I tested it only briefly. But 
I was able to create event!, send it to another face and process 
it.

Graham - why should it be? I expect it being just a structure/object, 
you fill in the data, and it gets inserted into the event queue, 
then your objects react accordingly, like if the event would be generated 
by normal action.

and a way to record macros?

is there a way to enter characters into a field ?  Like the DEL, 
and Backspace ?

I am going to work on it a bit today, and tomorrow, then I can release 
what I have ...

I am really nervous about things like removing the easy ability of 
changing the color of something easily, and if it will unnerve me 
in the future, I will fork it ... :-)

Any hints how the material system work? How do I "destylize" panel 
for e.g.? Let's say I want panel functionality, but without the visuals 
(if I enclose everything in panel, there's too many borders and gradients 
around, and I would like to have more relaxed design). Let's say 
I would like to create derived style, called panel-, panel-less, 
pure-panel, whatever. I can see following draw code:

draw: [
			plain: []
			gradient: [
				clip margin-box/top-left margin-box/bottom-right
				pen none
				line-width 0
				grad-pen linear 1x1 0 gob-size/y 90 area-fill
				box (margin-box/top-left + 1) (margin-box/bottom-right - 1) 1
			]
		] 

And following on-make code:

			on-make: [
				make-material face get-facet face 'material
				set-material face 'up
				all [
					get-facet face 'area-fill
					set-facet face 'draw-mode 'gradient
				]
				make-panel face 'panel
			] 

What I am supposed to do, to change the disign?

Then other styles would derive from it and add the necessary frame.

tables - nice, and good to know ...

I a sense, this is very disappointing, as we have no more the possibility 
to use the Carl's gui, and the RMA 's version seems far from being 
usable !

It's available, take it and help us to port more styles. Again, this 
was said several times. If you don't want to, than you have to wait.

We are not going to change our strategy, in this we are very stable 
and predictable.

So far, Petr's feedback helped us a lot and we know the GUI is not 
perfect yet. Nevertheless the more people help us the faster we will 
be.

Robert - I can't see any subsystems ready, other than proper resizing 
(which is really nice), and focusing system. How can you say 2-3 
styles are enough to judge the design? I would not call non-working 
styles being an eye-candy :-) This is all about architecture -  when 
porting demo, I meet the case when I am able to easily change e.g. 
color of the scroller with Carl's GUI, which does not seems to be 
a case with RMA's GUI, or I just don't know how to do it. As I did 
not want to bether you here with such simple stupid thing, I tried 
to study material-system myself. But - I can tell one thing - if 
those things are not simple on the surface, it is either - missing 
docs, or very wrong architecture.


You should really remember, why Carl decided to rework the GUI - 
to be the pleasure to use, kind like of Amiga AMOS Basic, yet still 
allowing more complicated designs. If that aspect will not be pursued, 
ppl will not like the GUI. And what is the system good for, if not 
liked to be used by ppl?


OK, at this point, with 2-3 styles in focus, I might postpone port 
of the demo, no? As the demo is surely done with more than 2-3 styles 
:-) I will soon finish it to the state, when clicking the left side 
list items will not crash the demo. Non working stuff will be commented 
out. Then others might try to get more complicated set-ups running 
...