AltME groups: search

Gabriele, that was my question too.  Currently If you have 'busy 
loop', no matter what technique you are using, you need to 'idle' 
at some point to give CPU some free time. Currently I don't know 
of a way how to do it in R3 as the CPU is getting high even on very 
long(in terms of CPU time) idle delays.

try this:

screen: system/view/screen-gob
event-port: system/view/event-port: open event://
event-queue: system/ports/system/state
push-event: func [event][append event-queue event]
push-event time-event: make event! [type: 'time port: event-port]
process-timers: does [
	push-event time-event
	forskip timers 2 [
		case [
			not integer? timers/1 []
			positive? timers/1 [timers/1: timers/1 - 1]
			zero? timers/1 [timers/1: do :timers/2]
		]
	]
]
event-port/awake: func [event][
	switch/default event/type [
		time [process-timers]
		close [halt]
	][
		print [event/type event/offset now/time/precise]
	]
]
timers: [
	1000 [print ["1000 ticks" now/time/precise] 1000]
	4500 [print ["4500 ticks" now/time/precise] 4500]
]
show append screen make gob! [
	offset: 50x50
	size: 100x100
	flags: [resize]
]
do-events

Ah, so you are inserting the events system port not event port. That 
was the difference.

I tried it here...works here in case the event loop doesn't contain 
any time consuming code(ie. is almost 'empty' as in your example).

But when I add some 'load'  into the loop then receiving of other 
event types is going to be rapidly limited/blocked when comparing 
to the FOREVER loop.

Either I'm doing something wrong or inserting events from the awake 
handler somehow blocks the whole flow.

AGG does a lot of computation, basically having access to this data 
in a consistent way.  also not having to use composed/reduced blocks 
all the time.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  

getting intersections between complex shapes like splines and polygons, 
xformed.
bounding boxes of things, calculated points of displayed letters.


if there where a unified method which just keeps the persistent data 
and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.

...also not having to use composed/reduced blocks all the time.


If you had look at the concept demo I posted above there is no sigle 
forced compose or reduce(ofcourse except the possible internal native 
parser processing) applied on the DRAW block using this method.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  
getting intersections between complex shapes 
like splines and polygons, xformed.
bounding boxes of things, calculated 
points of displayed letters.


Agreed, being able te get calculated coordinates of bsplines was 
planned addition, though not yet implemented.

Not sure about the intersections. I think you would need to use external/third-party 
code for that.
Bounding boxes, yes that is/was also planned.

But these ale more like helper functions which doesn't need to have 
any 'draw elements' access. It's enough to provide whole/partial 
draw block to get proper results.


if there where a unified method which just keeps the persistent data...


The DRAW dialect block is the persistent data IMO. And you can build 
any other dialect/system over it.

Don't be fooled by the result you are seeing. The internal structure 
of the data is almost identical as described in the DRAW block but 
in different format.

All the calculations are done on-the-fly using diferent parts of 
the pipeline setup. For example:


coordinates(almost same as in DRAW definition)->curve_converter->trasformer->rasterizer->renderer


there is not any persistent storage between 'coordinates' and 'rasterize' 
phases (that would be memory overkill to store all the approximated 
curves etc.)..the result is directly rasterized on the fly.

So in fact there is no static 'list of vertices or whateve' of the 
resulted image, everything is dynamic from the time you pass your 
DRAW definition to the engine.


...and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.
 

See the concept demo. I'm using one single DRAW block for all the 
objects and I can access/manipulate them without any complex code. 
There are no limits.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.


ok, so show me example of the form you would like to use for drawing. 
Is there any existing system which uses your expected behaviour?

as I said, I will wait for the hostkit with view to be released before 
spending to much time on this... I really don't have time to go in 
depth with this... and I'm not even trying to convince anyone.  just 
replying to questions and I feel its being taken too seriously for 
now.   its possible, the better approach will be to have access to 
some of the AGG internals via the extensions and wrap these into 
generic objects, for example.


its still just an idea.  there is no point to going into details. 
 I need to see the view host kit first.

yep  I agree, I just don't have the time to go in-depth.  too much 
stuff to do right now.

Maxim, no problem, I have not much time either now so feel free to 
clarify any time later.

I was just wondering what you are looking for to satisfy your needs.

And of course, you cannot request functionality of big complex 3D 
systems which are usually fat high-level layers over  low level graphics 
libraries.

You should think about the DRAW at the level of graphic library api, 
not application layer.

So I more awaited comparison with OpenGL, DIrectX, Cairo, Qt , Java2d 
 and so on. Anyway, I'm curious about your  examples....

Also I don't understand what is so wrong on using dialect as an interface 
when Rebol should be the case where working with blocks, dialects 
etc. should be a plus.

For example If you prefer interface based on function calls over 
dialect the I'd like to know what benefits you see in that approach 
etc.

Gabriele, i don't think so. (regarding the definition on wikipedia).
Actually, I used a technic very similar to what's done in R2.

In R2 the event engine throw tons of time events aswell. But the 
filtering (regarding which face as a rate property) is automatic 
(more or less).

Steeve, but were you succesfull to use this technique in real world 
case? I tried to use it for the DRAW demo but it doesn't work well.

Try: do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes-2.r


-try to move mouse over the window..you should see quick 'MOVE'  
events  eing logged in the console

-if you select any object using the mouse the loop is starting to 
do something usefull and from that time I could get only about 3 
MOVE events per second which is very slow. To me it looks like the 
event port blocks during execution of the code inside the WAKE handler.

But if I use the same code inside FOREVER+WAIT cycle the events are 
comming much more frequently.

The problem with FOREVER+WAIT in R3 though is it eats up 100% of 
CPU time(as opposed in R2) and I don't know why. Probably a question 
for Carl.

Henrik, in your last try, if you skip some time events  then the 
animation slow down but it's eating only 50% of my cpu (a small celeron).

tick: 0
...
handler: func [event] [
	switch event/type [
		time [
			++ tick
			if all [picked-obj tick > 30] [ 
				tick: 0
...

Rebol is slow for such animations

but it's true that time events will not be faster than a forever 
loop.
It was already true with R2

As I said the problem is not in the demo itselt...it is in the timing/loop 
code.

You can  easily to see it if you put some code(doesnt have to be 
related to draw or even graphics) in your small example you posted 
previously. You will see the same slowndown which means: don't put 
time consuming code into the AWAKE handler. But where to put it if 
you generate time events in that place? :)

Btw i think the throwing of time events can be optimized by modifying, 
the system handler:

>> ? :system/ports/system/awake
make function! [[
    sport "System port (State block holds events)"
    ports "Port list (Copy of block passed to WAIT)"
    /local event port waked
][
    waked: sport/data
    loop 8 [
        if not event: take sport/state [break]
        port: event/port
        if wake-up port event [
            if not find waked port [append waked port]
        ]
    ]
    if not block? ports [return none]
    forall ports [
        if find waked first ports [return true]
    ]
    false

instead of pushing back, 8 times, the time event (the worst case), 
we could push it only one time

(Using time events)

Cyphre, By reducing the number of objets to draw (10 objects) I have 
a really smouth animation taking less than 2% of UC when an object 
is rotating, and growing to 20% maximum when the object is actually 
moving.
Meaning your clipping technic has a  low effect on perfs.

and with 50 objects, i have 30% to 50% CPU usage.
Time events are not so bad.

http://sites.google.com/site/rebolish/test-1/draw-shapes-22.r

Steeve,

clipping: I disagree here,you cannot compare the clipping effect 
by increasing/reducing number of renedered objects. The only valid 
test is to to compare rendering of same number of objects with and 
without the clipping being enabled. Note that the perfomance slowdown 
you are reporting when adding more objects doesn't have to be related 
to clipping.


regarding your new version..sorry, I'm still not convinced. It looks 
to me you just replicated the same busy loop as when I use FOREVER+WAIT 
technique. You are simulating kind of 'wait' using the tick skipping 
but the result is same when looking at the CPU usage.

I still wonder why we need to 'wait' too much in R3 unless CPU load 
starts dropping down.

When I have time,I'll try to create some test script which can be 
indentically used in R2 and R3 to see if there is really any difference.

Steeve: a busy loop means that the CPU is busy looping. That is what 
happens in your example. There is no "sleep" time between time events. 
That is not true with actual time events, which fire at a defined 
interval, and allow the CPU to sleep between them.

Gabriele, you can't be more wrong. There is obviously sleep times 
in my example.

I reported that the CPU usage is variyng a lot depending what time 
events are triggering. There's no need to argue again facts. Obviously, 
less CPU usage means the CPU is sleeping somewhere.

Steeve, ah, I see, you are basically processing your fake time events 
whenever other events happen (eg. mouse moves). But if that's the 
case, then there is absolutely no point in using those fake time 
events. Also, there is no guarantee you are going to get events...

Specifically:
	// Nothing, so wait for period of time
	delta = (REBCNT)OS_Delta_Time(base, 0)/1000 + res;
	if (delta >= millisec) return 0;
	millisec -= delta;  // account for time lost above
	req.length = millisec;

Gregg, time to curecode it, I suppose. I get the same here.

This http://www.rebol.net/wiki/Template:GUI_TOC leads to this http://www.rebol.com/r3/docs/gui/gui.html
and this message


So, you found this page from the sitemap? Sneaky.

This GUI section 
is under construction (on a different server). It's not meant for 
publication yet. To be transferred here as they move into final draft 
stage.

Many of these links don't yet exist. They are being filled 
in at this time. Also, the image links are not yet setup.

So, no I didn't.

Not the problem, try this instead, it should return around the same 
time, not the case.


>> repeat i 6 [print [n: 10 ** i "x" j: 0.1 ** i tab "=" dt [loop 
n[wait j]]]]
10.0 x 0.1			= 0:00:01.000137
100.0 x 0.01			= 0:00:01.00159
1000.0 x 0.001		= 0:00:01.023774
10000.0 x 0.0001		= 0:00:00.044802 (strange)
100000.0 x 0.00001		= 0:00:00.459103 (here too)
1000000.0 x 0.000001	= 0:00:05.503772

we change one thing at a time.

Yes, I can write something up ... I already did with Marketing related 
documents (waste of time :-), but it will just collect basic requirements, 
I am not able to outline, how should it be done ...

 AGG group about a bug in TRANSLATE

. henrik not a news that bu exist since 3 years i submited it long 
time ago when i was implementing matrix translation in AGG when i 
was writing SVG renderer. So far no one seemed to care about that...

( and on tooltip using AGG some cool effect can be done there ... 
 ( like a progressive fade away in time) )

it's a pain every time you need an advanced widget to have to do 
it from scratch  you then spend alot of time  designing widgets instead 
of inputing fonctionalities to your software

the second categories countains the set of high level widget wich 
include a lot of time of  developement and though about how to give 
them flexibilities and extensibilities  not to end with a list-view 
widget that is able to display nothing but text like in R2.  Those 
widgets and widget set should be able to evolve in time and ofcourse 
without impling a redistribution of the complete R3 view stuff.exe

for example in viva-rebol.r project advanced side widgets take 95% 
of the source code lines writen ( and i compressed some of them) 
OK viva-rebol involve a new way to deal with text in an extensive 
and heavy way okay but still a hudge part of this project are nothing 
but one time used widget and that's a true waste!

One problem with tabbed views is that you can only see one tab at 
a time ... so if you have multiple screens, you can't use them.

Screenshots will be available when there is something to show. Worked 
out a few bugs regarding tab navigation yesterday and there is work 
being done on the basis for a grid system that will be used for tables, 
dropdowns, menus, etc. Someone has been added to the list of developers, 
as I don't have much time right now to do GUI work. He may speak 
up if he wants to. :-)

I studied KHTML back when I thought we were going to build a new 
AWeb around it. it was incredibly much simpler than Gecko at the 
time. Don't know about webkit, though.

gram for tab panels they shopuld be able to stick together in line 
when needed and show one content at a time  and able to be extracted 
from the line to exists in their own lonely window like it's done 
in most of webbrowser now inh days

We want to be able to automaticall store all this run-time state 
information with one call.

you have no idea how much time i've spent looking for that. thx

Let me refine what I said earlier - the idea would be to use some 
dialect that would create all the necessary bits using REBOL (JS, 
CSS, DOM elements) to be rendered by the embedded WebKit renderer. 
If, at the same time, people could run 'standard' HTML5 code in this 
same container (with integration to the hosting REBOL runtime), the 
whole would still be perceived as one integrated environment with 
HTML5 possibly being simplified into REBOL over time.

Remark is my solution for web stuff..  its basically what you describe 
above.   One engine to manage all aspects of a web application.  
Using rebol dialects compiled in real-time, you can build any data. 
 but the Dialects can be embeded within any other file, using a twist 
on the html friendly <tag> notation.

when we'll have a webkit REBOL plugin, then I (and hopefull others) 
will be able to do a real-time web dev software using the remark 
framework.

exactly - it's there right now, as opposed to VID 3.4 which is only 
going to be fully available some time from now (in a more polished 
form)

IT seems god, but in the same time, i'm not sure I like this "clipping 
area" of events thing.

A "silly" idea : could use one gob for the drawing, and another one 
in front of it clipped to the "usable" size for the event tracking 
!?

Also you can have more gobs in one style. But you do not need it, 
most of the time.

resizing: no, Carl does not like RebGUI resizing model, nor some 
look-alikes. Neither do I. That is why Cyphre and I had to try two 
distinct prototypes not being fully content with any of them (the 
second one being able to deliver some nice pictures already). Tomorrow, 
it is time to try yet another resizing model, this time adhering 
to Carl's original idea more, than his own implementation, so the 
system is going to be quite advanced (it took a lot of time to fine-tune 
some algorithm details, we almost gave up).

I want resizing for the desktop, and scaling for devices like Android-based 
phones where you can't necessarily know the resolution/size ahead 
of time.

Hello guys, just few notes from my side regarding the layout sematics 
and min/max-size etc:
-the layout will be still as simple as in the current R3GUI

-most of the time only 'style maker' will need to handle min/max/init 
size of the specific style

-by default layout elements have to be organized either in PANEL 
or GROUP structures (though it is possible create your super special 
style for circular layouts or whatever ;))

-at the PANEL/GROUP layout level there will be only three kinds of 
elements:
1) style with absolute size (in any axis)
2) style with elastic size (in any axis)

3) optional RETURN keyword used for line breaking to create variable 
number of rows/cols(default ehaviour is to set fixed number of cols/rows 
for GROUP/PANEL)

-to achieve more complex layout user can redefine min/max sizes according 
his needs

Script: "Resizing prototype" Version: none Date: 25-Jun-2010/16:08:26+2:0
building GOBS 0:00:00.256341
updating gobs 0:00:00.417243
resizing gobs 0:00:00.288457
number of resized GOBs: 6364
resizing time: 0:00:00.283141
rendering time: 0:00:00.693365
resizing time: 0:00:00.315615
rendering time: 0:00:00.726654
resizing time: 0:00:00.289055
rendering time: 0:00:00.676646

AGG interface is speeded up. Current gain about 280% faster. As you 
can see the drawing time is about 3 times the resizing time. These 
numbers should become more equal.

handler: func [event] [
			switch event/type [
				down [
				]
				up [
				]
				move [
				]
				resize [
					print [
						"resizing time:"
						dt [
							do-resize win event/offset
							;reflect the window gob boundaries
							win/parent/size: win/size
						]
					]
					print ["rendering time:" dt [show win/parent]]
				]
				close [
					quit
				]
			]
			none
		]

cache are always a good thing for repetitive task if you draw use 
is to draw 1 square or 1 circle or 1 line of texte will you don't 
need a cache buuuuuuut

if you do  a document rendering like area-tc with alot of  time the 
same calls over and over again then you see the obvious optimisation 
brought by a cash

6 am i got a heavy day yesterday and i take some time before going 
to work to be tuned ....

Not sure, there is one state at a time.

ok it's too early to speak english for me i need a coffee and a proper 
wakeup

i'm leaving i will try to get around at a more suitable time for 
me ...

The DLL is the plain Rebol interpreter. All the sourrindings, named 
host-kit, that you need to make use of Rebol on a particular platform 
is in the EXE. The EXE loads the DLL at init time.

some refinements to the resizing model, by ladislav and cyphre as 
well as some documentation, so I can learn how it works. no new demos 
at this time.

Fighting at too many fronts at the same time is not a good idea.

Rebol's run time memory far exceeds any savings we might get from 
a small library

an extension linkin agg and  opengl would be awsome and crazy at 
same time
that's sad the developpement stopped

I imagine we could have multiple graphics libraries loaded at the 
same time ...

and yes it was started with RebGUI, mainly because that was the standard 
GUI system to use at the time.

Resizing news: the latest state is, that there are two "container 
styles", the first one being a group - a layout in which graphic 
objects are arranged into either rows or columns, not necessarily 
into *both rows and columns* at the same time, the second one is 
a panel - a layout in which graphic objects are arranged into both 
rows and columns at the same time.

It may be the time to discuss the style name, I just do not know 
what is the best forum for it

Neither of the pictures represents the Panel style now. The Panel 
style would have "regular" rows as well as "regular" columns at the 
same time.

in group the objects are organized into either rows or columns (internally 
lines all the time), i.e. XY is misleading

I think it should be possible to make a style like that, if you really 
want it. (Most of the time, you don't want it, but when you do, you 
do.)

Most of the time when a programmer thinks that they want to specify 
colors, they are wrong.

I agree, most of the time the programmer doesn't want to think about 
it, and it's best to get the colour from a theme. BUT, WHEN YOU WANT 
A BUTTON ALWAYS RED, YOU WANT IT ALWAYS RED!!!!

Yes, I agree this is the best way 99.9% of the time. And this separation 
of specification has all been discussed before.

Anton, you are free to do that, but it will break the philosophy 
of how styles work together. I think this point is not properly understood, 
but it will move the GUI to the next level, where you spend zero 
time thinking about colors or theme, can properly divide UI design 
between a graphical designer and one producing programs.

I remember that the solution we came up with during the initial design 
phase was to have colors in the layout dialect be specified functionally, 
like window-background and such. This was not implemented at the 
time (we never got around to it). Was it forgotten?

You could bake the colour in at style init time, and then you will 
have the same render speed.

With a meterials system you could bake a whole theme in at app init 
time, then have the styles bake the applicable colors into the styles 
at style init time.

it's not just looks. deep semantics that are used to make the GUI 
function properly relies on functional styles rather than appearance 
of styles. if you have a red button, the GUI won't know of its importance. 
but if you have an OK-BUTTON, you can tell how important it is, when 
it should be focused and what you are allowed to do with it. automating 
this can cut off hundreds of hours of development and testing time, 
because you don't have to pay attention to those details. the UI 
system does that for you.

I was taught proper document design back at the Lotus AmiPro days 
- much better than Word at that time, and it pushed you to use styles. 
So - I hate inline styling. But - how does it apply to the GUI?

On naming, I think PANEL is too general and doesn't describe the 
layout behavior. I could live with it though. 


I agree that TABLE should be saved as that is the common term for 
the spreadsheet model. GRID was used for that for a long time, and 
still is sometimes, but GRID could also be good when thought of as 
a canonical grid layout. GRID-LAY, CANON-LAY, or TABLET aren't too 
inspiring either.

I don't want the engine any more complex than necessary, but I also 
don't want to put the onus on the app developer (that is, me :-) 
to implement logic that is needed 95% of the time.

and more complexity you will add to your engine more unexpected problems 
you will face...


 Like what we experienced in area-tc... suddently our perffectly working 
 engine under wnidows XP shows strong bugs in rendering just by arriving 
 on windows7. After 6 month in searching the why  and not finding 
 any cause to that rendering jam I by chance tryed the ultimate thing 
 no programer does i retro versionned back like 10  version below 
 the rendering engine and there suddently i found that rendering problems 
 disapeared by miracle...


I spend 10 times more time searching why the rendering was defective 
on windows 7 than doing area-tc and viva-rebol.r.  And that's too 
what  completly killed my mood. What else can i do than try to make 
this community know my experience with extensive text processing 
in draw with R2 to not have the same conceptual lacks repeated in 
R3.


And clearly  in R2 the text commands in AGG/draw were not suited 
for docuement rendering... That  doesn't means AGG can't do it ... 
that means at that time the dialect draw wasn't designed to exploit 
 intensivly text rendering. I always said before runnning you have 
to learn to crawl, then to stand up, then to walk. for me the way 
i  saw the realisation of a rendering engine text oriented for draw 
dialect was first step changing the color of  choosen elements in 
the text, then changing the font spécificity anytime anywhere in 
the document then being able to do strong text manipulations like 
moving by drag and drop paragraphs, inserting multimedia content 
in the document, scaling paragraphs etc... 

ROBERT: 

In fact that depends what  the rich text engine aims ... for example 
read only rendering is pretty different of  real time editing wisiwyg 
engine... The complexity betwin both approach is like 1 to 100...

Robert I know that you aim to get a WisiWyg editor for makedoc Pro 
format (wich in a time i tryed to provide in a totally deferent rendering 
technology)

But I know, not the time for such arguing

shadwolf for the 56743892th time, the font rendering is not properly 
utilized from AGG yet,

Actually, when I looked at the katakana showed here, i felt something 
weird (yeah, back in the time, I learned them)
I couldn't remember the 5th one.
then, I checked (http://fr.wikipedia.org/wiki/Katakana)
Eh ! Right in the spot. (Wi) is not used anymore.

Hey guys, don't be so picky ;) about the test text strings. I only 
cut'n'pasted random chars from some of these pages http://www.alanwood.net/unicode/#links
that's all.

I personally don't plan to spend time on all the 'unicode normalization' 
and other tricky stuff and details. It seems there is enough linguistic 
experts even for tibetan script! So I'll kindly left that part as 
an exercise to the comunity :-P

The question model is which is more efficient to use, both at development 
time and runtime. Letters will be tough either way (likely more for 
bottom-up), but graphics will be simpler bottom-up until display 
time.

Maxim, do you not get that I am agreeing with you? I am just disagreeing 
that it should be bottom-up all the time :)

I never said it should be all the time... it can easily be a switch 
on each gob.

Complexity is the enemy here. We don't want to add too many options, 
because processing them has overhead in mental, development time 
and runtime. Pick a coordinate system.

if each type does something different then everything becomes complex, 
except for one if condition in the run-time.

the way I see it the direction would be managed at the same place 
and time any origin check is performed.

at the same place and time any origin check is performed
 - That is the added complexity, the origin checks.

As for native code, instead of coordinate system, I would maybe more 
like to see some experiments as compound rasterizer, or other low-level 
optimisations (when time permits)

Robert absolutly not and more i spend time here less i want to participate 
in anything .... that's how you motivate contributions...

Pekr  WHAT HAVE YOU DONE THE PAST MONTH TO TRY TO GET ME CONVINCED 
TO PARTICIPATE IN THIS PROJECT ?


Any time I try get a serrious conversation here about  where are 
we going or how things are done i get cheap lame excuses and I'm 
tired of it ! 


I stated a long ago the current phylosophy in communautary contributions 
don't fit with me (it was in may 2005)  you can't sit on 2 chairs 
at same time and expect to be stable.


You can't say rebol is a commercial trade marked business  and don't 
pay  the contributors and give them credits for their contributions 
.

You can't say a part of it is commercial an other part is free that's 
ethically not right. 

That's my way to see it ...


Then i won't participate to a project where the all mighty god fater 
can come out of nowhere and trash my month of hard work in a blink 
of an eye without any justification.


I won't participate in a team with people that don't want to share 
knowledge.


I won't participate in a team where people can take in hostage the 
whole project to get  money for themselves. 


I won't participate in a project where i can't  do any proposal with 
being insulted...

Did I made myself clear ?

why compiling things that don't work ? Ok so i should have understoud 
it more like rich-text widget is done now and it compiles well so 
on next release at that time you will be able to experience it. We 
are impatient to get your comments on this new module.

Cyphre, you GUI update inside a network looks similar to what I did 
... but which didn't work!  Ok, time for me to try again.

shadwolf, yes. that's because no time has been spent on skinning.

because pretty or ugly: it will not help to speed up development 
time for a large program from months to weeks. having a proper GUI 
architecture saves money in the end. money! :-)

As soon as this is done, it's released and you all can start writing 
styles like made. At this time it's ensured that it all will fit 
together.

i can make a basic list of gobs i want 
treeview
menu bar
tab panel
menu popup

list  (for text images other gobs ?.... with resizable columns auto 
sort etc...)
checkbox /groups

radio button/ groups  ( in a group with many radio button only 1 
radio button can be activated at a time that's the difference with 
a checkbox group)
status bar
tools bar 
splitter bar (to separate elements and dynanmically resize time)

being able to have docking system  being able of having subwindows 
in the main windows then you can arrange the child windows easyly 
(one on top full, cascade, tiles etc...)


the graphical style should be pure enough to have an attractive look 
and a one eye shot notice and recognize style without looking kidish 
or like in 1979 first intent of  graphical interface made by Xeros 
labs in palo alto ....