World: r3wp

No, because every GUI style can load/save itself. Such emitters just 
need to be done once. Every gui element belongs to a record. So, 
it's easy to say: save customer and that's it.

the state of GUI? Still too early state of development, to provide 
us with any estimates of possible release or release-for-testing 
dates?

Yes, we are doing the first basic styles to create our internal apps 
we need. As soon as this is stable and proofed to be useable, we 
will release the GUI lib.

Is it still developed so that it can be included in R3 by RT? Or 
are we talking separate effort here?

We take VID34 AS-IS and patch the code-base. So it's easy to find 
the differences. Most things we try to add non-intrusive. So you 
load an additional file and get new functionality.


The styles are all "self-contained". If Carl wants it can all be 
integrated into VID.

isn't it a bit of an overhead for a GUI itself? I mean - those are 
application (higher) level issue

 - actually no, they should not be that, and this is quite a misconception 
 that you want this level of control in most apps.


It's what prevents us from creating complex forms in minutes, where 
you don't have to think much about how the form interacts with a 
database.


When you think of it, most of the code you write, when writing boring 
business apps, and beyond writing styles, is writing, and worse: 
debugging and testing such code. Wouldn't it be nice to have this 
built into the GUI, all debugged and tested for you?

yes, in Clipper, 15 years ago (as well as in FoxPro), there were 
scatter/gather methods, to get/set forms ....

I still don't like "we patch VID" attitude though. It is understandable, 
from your business POV, but it still sounds as a fork to me. It would 
be really good to get Carl cooperating, so that the work could be 
accepted for official VID distro, or there is a risk, we will end-up 
with two VIDs ... just my opinion ....

I can understand, that it might be really upon the one's skills, 
to actually "get Carl cooperating" :-)

If Carl wants it can all be integrated into VID.
  is the most important aspect ... to prevent eventual fork ...

Well, can't wait to test something :-) Last active VID work happened 
2 years ago or so :-)

Pekr, you misunderstand "patching" for "hacking". This is nothing 
of the sort.

It would be really good to get Carl cooperating
 - yes it would be. And you probably know how to do it? ;)

pekr, if we have 10 GUI frameworks its a good thing.   each one adapted 
to different needs.


its also a good way to attrack new developpers.  look, this language 
has several complete GUI layers.

I'd even like someone to build a native OS GUI extension.   some 
people *require* that for their work.


RT has one it advocates directly, but any others are a boon to the 
language.

what Robert describes also sounds like something they could easily 
adapt to have a web viewer for.   a bit like a .net approach where 
you can build tools and distribute them in different architectures, 
suiting client needs.

Persistent GUI state will allow an application to save its state, 
be suspended or shut down, and be restored later, all automatically 
in response to system events. Windows 7, Androis and iPhone OS 4.0 
all have facilities for triggering this kind of event in applications 
in response to power management or (for Windows 7) reboots. This 
will make it possible for us to write REBOL apps that will resume 
after an intentional shutdown by the system.

Basically, if all your apps support this then it will be safe to 
turn on Automatic Updates and let your computer reboot itself if 
necessary, at least on Windows 7 (and maybe Vista).

Androis -> Android

But I'm not assuming that the R3 GUI will do that immediately, just 
that it will be possible.

Max, yes, we can add different emitters. It would even be possible 
to generate HTML out of a VID form.

just what I thought  ;-)

Brian, yep, exactly. And it's not only about suspension. Think about 
logging of at one system and again on at an other while taking over 
your app session and GUI state on this system to continue your work.

Pekr but it's blue and blue drives me more crazy than i'm already 
...

gray is just the color that hurt monitors and eyes the less .... 
 i hate white on my screen it burns my eyes so much..

one of the things we never though about but that could be a thrilling 
inovative experience is  the hability to send gobs ( windows with 
all it's content idgets) through the net to someone else ...

rebol GUI is light weight gob are enought well done to be considered 
as a stand alone entity... So why not trying to get the best of rebol 
doing things like that...

rebol vnc

more than an X11 export host

more like the X11 export display ... but better ....

Happy Birthday to mee, Happy Birthday to mee...
Today I turn 36.

Ops...
It was for CHAT !

Hmm, as you posted here, guys should make some greetings demo using 
new VID :-)

That's a good idea... I am ready for the gift !

And Carl could release a beta, It's a nice opening

I know that it is probably preliminary topic, but as for UI skinnability 
- will skin allow to have different metrics to the style? I mean 
- I don't like how e.g. scrollers are big, the same goes for arrow 
for drop-down - they should be something like 80% of what they are. 
So I wonder what will skinning be about - only to differently draw 
inside the style area (container), or will we be able to even change 
metrics (size)?

I prefer the rounded edge tabs used in Rebgui ... but I see windows 
uses squared off tabs

I see that there is a color indicator for the active tab, but windows 
also makes the active tab taller ...

Petr, that's a good idea. I take it into our backlog. We haven't 
thought about it yet.

Any updates for this month?

initial table has been made.

any progress on resizing?

Cyphre is looking into it. The box model may use some enhancements.

I'm still steadily posting screenshots as new features emerge, in 
case you forgot. :-)

Robert - I have further questions towards "skinning", inspired by 
short chat to Rebolek .... what if different platform treat fifferently 
style behavioral aspects? I mean - drop-down under OS-X might behave 
differently from drop-down under Windows. So - it is not about having 
different color here or there. It is not about having different metrics 
to style. But it might also involve different reaction to events. 
I think that can't be solved by just "skinning". We would have to 
have differenct, platform specific stylesheets, loaded upon launch 
of the script ...

IMO this could be doen by using different actors and reactors based 
on platform ID. Either it's all included or pre-processed. Maybe 
it's even possible to load a module with all the actors and reactors 
for the specific platform.

Screenshots are here: http://rebol.hmkdesign.dk/files/r3/gui/

Thanks for doing that Henrik.

Get getting around to checking r3 gui. Does anyone else get the char-size 
needs a value error upon load-gui?

james, it may be that you are running a98 or a99. the GUI will currently 
only run on a97 and below.

Thanks bro. I've just been enjoying your screenshots. I'm so glad 
you're working on this part of the dev!

Yes, well, currently I need to finish another project, so GUI development 
could be faster, but Cyphre and Rebolek are working on it. At least 
it's moving. Proper resizing is the topic now.