World: r3wp

Dunno if I am clear about what do I mean, but maybe ability of getting 
focus to group-box should be enough, it it provides focus isolation 
described above ....

Robert

 1) Widget observations: all noted. LED is the read-only functional 
 equivalent of 'check used for things like system status displays, 
 etc

 2) Tabbing (basic version) is slated for 0.1.8, more advanced features 
 will have to wait until the base widget set is complete.

 3) DATA is a required structural element to ensure widget specific 
 initialization is performed by init *not* the display function.

 4) Implicit face usage has two big advantages: a) allows you to cut 
 and paste code between widgets; b) different widgets can share the 
 same code.

 5) RebGUI still lacks a few of the more complex list / table / menu 
 / treeview type widgets.

 6) Re: new projects. RebGUI is still ALPHA and the basic design may 
 fluctuate as the requirements of more complex widgets becomes clearer. 
 I wouldn't be building any commercial applications based on it quite 
 yet (not until it goes beta at least).

Pekr

 1) Also remember that VID was created against a much earlier version 
 of View, and that it is only recently that View functionality has 
 stabilized. One example of this is the extensive use of 'draw by 
 RebGUI compared to VID.

 2) Tabbing, like key mapping, is less of a technical issue than a 
 convention issue; but my aim is to be able to "drive" all RebGUI 
 widgets both with and without a mouse (although the priority is to 
 get the mouse behavior right first).

Once widgets get more complex, will they share any code, or will 
there be strict encapsulation, so that each style is fully self-contained?

I see a funny behaviour with the check widget. Left-clicking, as 
fast as I can, is no problem. Right-clicking fails sometimes. It 
seems, a fast double-click isn't noticed.

Nice job though! :-)

Pekr: code will be shared where it makes sense, and it will be made 
obvious (i.e. no hidden or subtle dependencies).


Geomol: It's a windows specific problem (probably trying to access 
a context menu or something first). I noticed this a while back when 
mapping left / right mouse clicks to zoom in / out ... works fine 
on Linux though.

in all cases REBGUI is a good enhancement yet to VID :)

it includes yet more usefull widgets and less memory usage than VID

but it's a 1 month alive project Ashley and Vincent have done most 
of the work alone so if ppl will give a hand and help ashley concretly 
by apporting code things could advance faster

apporting code to any project is hard I understand this but a first 
step (what I try to do ) is to apport yet existing bunch of code 
that are fitted to REBGUI Ashley takes then the role of merger and 
last adapter. I hope this free some time for him  to focus on work 
of the engine.

So do we want to use the global event system so that we can have 
modal and auto-closing dialogs or does someone know another way to 
accomplish it?

you can't at the same time search for yet existent widget try to 
adapt them and in the same time try to work on the enhancement of 
the engine ;)

Ah, come on!  Haven't you ever heard of multi-tasking? ;~>

Ammon messaging (LNS) but that means LNS yet is disponnible and to 
redo profundly the main system of exchange

event ;)

Multitasking in rebol yes we have Francois Jouen  that done a multitask 
system in REBOL script

Multi-tasking...  Was making a about your comment that you can only 
do one thing at once.

I, for example, am working on porting my drop-down style and at the 
same time working on adding a refinement to Display to handle modal 
auto-closing dialogs...

in the LNS big picture it's says that LNS is the base systeme for 
VIEW 2.0 etc so why not associate carl to the discution and see what 
he plan for View 2.0

My point is can we go very far taking abstraction of the RT plans 
?

or do we prefer by this work to convince people

that rebgui is good and if RT think it can even improve it . That 
could be good for them to retake it and improve changing it more 
profundly then substituate it in the VM since retake the VID and 
then rework it completly...

Well, from my POV...  Carl intended to have us build dialects that 
are better than VID.  There have been several attempts so far but 
none of them have made it far enough to actually be ready for mainstream 
usage.  I think that if we can actually produce a solid dialect that 
outperforms VID in enough areas then Carl will want to add it to 
the language or maybe even replace VID with it.

so we need to improve rebgui to dialectise it but I am affraid this 
apport a slower renderer and a more  consumtion

I'am very badd in dialects so I can't be of any use all my dialectal 
creation approche was learn thru makedoc it's good but not enought 
to imagine and write a vid like application

Global Event System: looks like 'menu has to use it, and I don't 
know if we have a real alternative. One thing I've added to 0.1.8 
is a 'keep function that lets you specify what widgets you wish to 
use and sets to none everything not used by those widgets ... so 
if more complex widgets require global events then so be it.


Contributed code: I prefer simple code (that may need to be enhanced) 
over complex code (that may have to be pruned).


Multi-tasking: The RebGUI engine is 90% where it needs to be so I'm 
spending most of my time on widget integration at the moment.


View 2.0: We have to work with what we have, although I have made 
a concession to the future [AGG] with regards to RebGUI's use of 
draw in preference to image + effects.


Dialectise RebGUI: It would be relatively easy to make the specification 
more VID-like by having each attribute specified with a distinct 
datatype (and moving duplicate datatypes such as an 'offset pair 
to a keyword such as 'at) but you pay a big price in code complexity 
and efficiency; and I'm not convinced that inferred attributes ("this 
is a 3-part tuple so it must be a color, while this is a 4-part tuple 
so it must be a span") make code legibility and maintenance any easier.


None of this is to say I can't be convinced otherwise, this is why 
RebGUI is still ALPHA. ;)

Contributed code: sure but yet existing amazing thing wasn't thinked 
to be added to RebGUI so If we want a good time average and retake 
yet existing widget. I think it can be seen as an omage to those 
ppl that spent lot of time try to implement this widgets. If we find 
a way to include them it's like we have a parternity and a real look 
over what exists in the rebol free community that"s a king of concretisation 
and that allow us to improve faster I don't think pruning ctx-menu 
is slower that redone the work from scratch ;). And As I say earlier 
that shows our consern and attention to what exists in rebol free 
community ;). Like "Thank you man you give us this widget now look 
what we can do with how it grow and how it became self dependent. 
If your still want to apport to it or have some ideas on it to share 
with us your very welcome" :)

Personally, I think it would be very cool to have a non-RT GUI dialect 
that was better than VID, but just as flexible.  I wrote VID in very 
short period of time, and it was disigned for more than what it is 
typically used for.  For example, VID is written in such a way that 
it makes it easy to write something like the Layout script -- because 
you can return to the original VID source code from the face itself.

In other words, VID is bi-directional.  Dialect -> Faces -> Dialect.

Most programs do not require that, so various fields of VID are not 
necessary.

Nice to see you here carl  ;)

Good to be here. Had a few minutes extra, since there is a huge storm 
going on in this part of Florida, and everything is runing behind 
schedule.

If I had a lot more time, I would be doing a lot more work on VID, 
because the few missing styles are really annoying. So are the few 
areas like moded-dialogs that need more work..... as does the default 
text editing code.

CArl I'am agree with you VID is a very amazing system no challenge 
with it in any other langagues ... But The first thing that came 
to us when we show VID based GUI is " why does this window looks 
so wired..." The fact that I spent on in less time than in other 
langage (even IDE compositor based) is not relevent for the non programmer 
or informatic nerd (sorry for the nerd word ...). What he want is 
what he knows GUI that are sharp designed but in the convention he 
knows hehehehe  ;)

I'm thinking that if I can find someone who wants to work on VID, 
I will actually find a way to pay for that, you know-- it is that 
*important* for it to be fixed.

look WinXP some people consider it as a renoval and tru novety but 
showing them GNOME/Linux/ Enlightenment based interface and desktop 
they turn mad ;)

But, I think the non-VID GUI projects are good too.  Because, when 
people use the SDK, they can use whatever GUI engine they prefer. 
They do not need to include VID in their code at all.

Carl If I had the knowledge to do so I will do so but most of what 
I learn about it was learn through the simple but amazing anamonitor 
and every day I learn new things Ashley is very y mentor  like cyphre 
or didec or Etienne Alaurent  :)

Yes.... those KDE/Gnome folks have done a nice job these days -- 
it would be great to get some people like that working on REBOL GUIs 
-- that would be used by many REBOL users.

I think that each time we tried to improve VID as a group, we got 
stuck because we tried to add too many things and make it too general. 
There are many improvements that I like, but in the end, it is more 
important to get them released than to make them perfect in every 
way.

Carl sure but in this point of view you loose attraction for RT ... 
and View vm grow grow and needs external things to be polished or 
to insert more evoluated (in the spirit of a user whan you have a 
menubar and a icon dockable bar it's evolued when you get them transparent 
it's even more evolved  :) )

things ;)

After all, look how many years it took MS to perfect even the simplest 
things in windows. For many years they were wrong or broken (and 
even to this day some still are).

Shadwolf, I agree with you -- we need to get those things improved 
for that reason!

I think feed it other is a good tactics that allow us to rethink 
some issues and you to get evolve too the existing system claiming 
that we still are in the Keep it simple ability ;)

feed eatch other ;) no feed it other ;)

each other

yes.

Carl and MS is an ogre ,) they have bunch of billions to spent on 
it but no brains hehehehehe ;)

we are the contrary we have brains maybe we don't communicate enought 
on important thing be we have no billions :)