World: r3wp

in R2, the console is a window that is controled by the application. 
 in R3, for now, the console is controled by the OS.


Windows does not allow an application to be either a windows app 
or a console app.

a future version of R3 will probably manage its own console like 
in R2.

Ah, yes, that's the reason. So, no way around that for now, no big 
deal.

its a stupid windows limitation which goes back to windows 1.0, if 
you can imagine that!

Not sure we can make a discussion out of it, so I'm posting here: 
How closely related would AGG/Draw be with HTML5 canvas?

dunno about HTML5 Canvas, but browsers contain SVG, and there were 
some attempts to do REBOL-2-SVG converters. There was some incompatibility 
in how gradients are specified, but that could be added to our kernel. 
I am sure Cyphre has more to say here ...

R3 is alpha, so the console window !

Any news from our fellow GUI team? :-)

I'm having a cup of coffee. :-)

I prefer tea :) Also right now I'm investigating password style and 
then will move to tabs.

:-)

I have a coffee too, although I prefer the tea ... well, quite an 
oxymoron :-)

... 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.