World: r3wp

... we need ... screenshots :-)

Henrik - is there any resolution to resizing system? I know that 
we both objected to max-size element for e.g., and IIRC there were 
some proposals of how to either fix current model, or replace it 
with different one. Have you made any decisions in that regard yet?

no, no resolution yet.

didec windows console is boring and ugly now that i show agg could 
deal  pretty stuffs with text in color why don't we HTMLize our console 
and bring some new way to experience console direct code flow coding 
cause that was the strong point of R2 and that's the actual weak 
point of r3

if you look at the ruby console it's already mixed with an help  
browser

we could do something with our rebol consol gathering all the pasr 
years accululatedexperiences

accumulated sorry

a console with color syntaxe to locate the kind of state the console 
is in or the kind of field we are calling the rebol words , this 
console could be merged or embeded with dynamic a

help or a way to start step by step evaluation or stop it   and a 
way to look at your data stacks or organisation like in anamonitor 
.. this advanced  console then  could be done in view dialect and 
be a show room to the view dialect capabilities

i'm for modular tweakable devtools

all those years i sharpen my own way  to code in rebol in a more 
professional way ... and that was done basing my self  on the few 
spare tools the rebolers bring  but it would be nice to have this 
effort through years continuated to show that the rought aspect of 
rebol evolved alot ans that now all you really need to do rebol is 
rebol and i think we all shown that in rebol light weight wasn't 
synonimous of  poor ideas oe small capabilities*

one of my dream regarding the developement of applications in rebol 
was to have a way to select a bunch of your code in your text editor 
and hit run by step  to see a step by step excution of that bunch 
of code  in  order to underfstand what rebol is doing closely when 
he clone data  h

or when he manage pointers

personaly one of the hardest part in rebol is the memory management 
and maybe that's part of the reason i don't understand the way parse 
works

Pekr about you gui library 2 comments yes it has all the widgets 
i expect and so much blue are you sure ?

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

Shadwold - I don't understand what are you asking, but if you are 
asking if I like mild bleu gui, then I have to say - yes. I am bored 
by old Amiga and NeXTStep grey look - Fedora, Vista, Windows 7, FaceBook 
login-page, all got it right ...

From rm-asset.com website - "# R3-GUI Library: Our internal extended 
and enhanced VID. We add a persistent layer so that GUI elements 
can be stored into a database backend. Further we added element-tree 
traversal code to simplify accessing GUI elements. Beside this we 
develop a bunch of GUI styles like TABLE, DROP-LIST, DROP-TREE etc." 


What's persistent state for GUI good for? And also - why the element 
traversal code, if we can use path in gobs and their "panes"?

Pekr, you need traversal code to move back and forth relatively in 
the tree.

Otherwise you can't do things like tab navigation.

persistent: If you want to store a form you need to get the relevant 
information from your styles. For example: which ID was selected 
in a drop-down box, sort-order of tables etc.

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

isn't it a bit of an overhead for a GUI itself? I mean - those are 
application (higher) level issues, although usefull ...

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