AltME groups: search

The GUI system may end up being one module, but may end up being 
more than one. System design first, code organization later once 
we have an idea what it is that we are organizing. The entire GUI 
code base will be small enough for one (smart) person to understand.

For focusing and such effects, it makes more sense to separate that 
out into a small gob system layered on top of the GUI. Similarly 
for drag'n'drop, bubble help, etc. It's not hard to do.

We are not working with a single-complex-gob system only, we also 
allow compound gobs, rich-text-only gobs, image gobs, whichever is 
the best for the situation. We even have modes and custom draw handlers 
for more complicated situations. The new GUI's approach is both simpler 
and more flexible than the frames system you describe, even flexible 
enough that you can implement that frames system in your style if 
you like.

It's basically a convenience function, though used widely in and 
by the new GUI code.

I may not have studied Gabriele's system as much as you have, but 
I have studied many other GUI systems and implemented some as well. 
There are a lot of differences between the systems in implementation 
details, but to a great extent they accomplish many of the same things. 
I know enough about Gabriele's and Carl's GUIs to be able to tell 
you that the overall design strategy is different, but the capabilities 
are comparable.

There is new Doc showing, how to "easily" view all styles - http://www.rebol.net/wiki/GUI_Example_-_View_all_styles

http://www.rebol.net/wiki/GUI_Note_-_Shapes_in_DRAW_Blocks- I think 
that we should be aiming at graph based low level AGG based design, 
with the ability to cache various nodes. IIRC Cyphre was talking 
about something like that, but not sure it is implemented ... good 
that such low level things are explained though ...

The SET [a: b:] issue:


In current REBOL a block argument to SET for the word parameter needs 
to be filled with values of the word! type, not any other word types. 
This is in contrast with just passing a single word value, which 
can be of any word type. The result of this is that values in word 
block argument need to be converted to word! before being passed 
as a parameter.


There is no reason that those words need to be of the word! type, 
particularly since the block isn't evaluated. One interesting thing 
about REBOL is that a word! bound to a context will refer to the 
same value as words of the other word types with the same spelling 
otherwise. This means that if you set a lit-word! to a value, you 
can get the same value from the corresponding word! or get-word!.


Now, the current behavior has some bad consequences as well, usage 
issues. Some word block arguments had to be preprocessed. The big 
problem we ran into was when we wanted to use SET inside of functions 
created with the new FUNCT function (temporary name).


FUNCT collects set-words from the code block and nested blocks and 
adds them to the function's locals. This is cool and works a lot 
better than I thought it would, and all action handlers of the new 
GUI are turned into functions with FUNCT. The problem we ran into 
is that when we had to use block SET to set local variables, those 
local variables would leak into an outer scope, wreaking havoc. If 
you are specifying the function spec directly there is an easy workaround 
for that: Just specify the locals that aren't caught with your own 
/local vars. However, you can't specify the function spec of an action 
handler in the dialect, just the code blocks (security/stability). 
This meant that if you wanted locals to be captured, you had to set 
them to none earlier in the function. How soon do you expect that 
to fail?


An easy solution to this would be to specify the words you want local 
as set-word! values in the literal word block argument to the SET. 
Those set-words would then be caught by FUNCT without any overhead. 
No problem, except for that SET doesn't allow it right now.


This is what we are going to fix in the next build: You will be able 
to do SET [a: b:] value.

In some circumstances like with FUNCT above, you will likely *have 
to* do SET [a: b:] value. This is where we get to the implications, 
what it means for us: We are making changes to the core, sometimes 
subtle changes with big implications. These changes are coming as 
a result of the work on the new GUI. Some of them are bug fixes, 
some of them are new functions or other enhancements, some are fixes 
to design flaws in the language expressed in functions we have already. 
They will affect the code you write even if you aren't doing GUI 
code. Every change like this is going to make R3 a cleaner, easier 
and more powerful language than R2, even with the backports. Something 
to look forward to :)

Simple answer: I don't think we are currently talking about finalization 
and the color picker was an example, not a feature.


Longer answer: The new GUI is going to be part of the open source 
portion of R3, and open source projects are never really finished 
until they die. So the question here is not "finalized" but "ready 
for a release to the wider developer community". In order to do that 
we need to put together the core design of the infrastructure and 
enough styles to get the new DevBase GUI up and running. Right now 
we are focussing on styles and features that have the most impact 
on the system as a whole, or the most potential to flush out bugs 
in the underlying runtime.


If it all seems low-level, that is because it is. We will have a 
development release before we have most of the styles you mention 
because we will need the help of the developer community to make 
those styles and more. However, don't expect the styles you list 
to be missing - some of them meet the criteria I lested above, like 
helping flush out design flaws or use in DevBase.

The new GUI is going to be extensible with new styles. No list of 
styles will be sufficient for everyone, so we are enabling and encouraging 
developers to make their own. For instance, I would like some styles 
inspired by the Office 2007 UI: ribbons and contextual toolbars. 
I know whole applications that are less complex to implement than 
those styles, so I would not expect them to be included in the core 
release at first.

What happened to the stuff Carl was working on to increasing the 
power of the GUI by making it more webpage-like - by incorporating 
services into the widgets? I have not heard any recent talk of these 
ideas...

Pekr, I understand Services will be there in R3 but Carl blogged 
about this concept of a button linking to the www...It was a little 
vague and Henrik did try to clear it up buy the new GUI seeems void 
of this..

I thought it was to be tightly intergrated into the gui and a major 
reason for the delay of vid 3.4. I thought it was a bold new step 
in the concept of GUI's but it does not seem to be a part of what 
we have been privy to.

What I hate about many websites is that they have very inefficient 
layouts. This is particularly so for forums and certain newssites, 
where perhaps 10 or 20% of the information on the page is relevant 
to you. Now imagine AltME's GUI inside a webpage. It's very efficient.

Doc style now exists:

http://rebol.hmkdesign.dk/files/r3/gui/083.png

most slowdowns are because of excessive redraws, so as we move along, 
those are weeded out and the GUI speeds up.

Where do you think the PARSE improvements are coming from? We are 
working on Core, because Core isn't good enough now to implement 
the new GUI. There have already been significant enhancements to 
the core as a result of the GUI work.

No, not just the underlying View component, low-level system enhancements 
and even mezzanines that can be used for non-graphical development 
- Core changes. The work on the new GUI is generating benefits for 
people who don't need a GUI.

Of those you list there, only modules are getting some love as a 
result of the GUI work so far, as the GUI will be modularized. However, 
the new GUI will be used to implement the new DevBase, and that will 
bring us open source code and more people.

Modules are not utilized yet, because the model for them isn't done 
yet. The GUI is serving as a test case to help refine the model. 
This is exactly what needs to get done in order to finalize modules. 
Once we have modules we can get plugins.

Steeve:
http://rebol.hmkdesign.dk/files/r3/gui/101.png

The vertical and horizontal slider are two different draw blocks.

Steeve, http://rebol.hmkdesign.dk/files/r3/gui/index.rsp

[http://rebol.hmkdesign.dk/files/r3/gui/071.png]   looks like my 
easy-drawer tool ;-)

Henrik - does GUI only resize, or does it also scale? E.g. when I 
go for bigger display resolution, if all elements are scaled accordingly?

Oldes: http://rebol.hmkdesign.dk/files/r3/gui/104.png

There should be absolutly something done about the font display quality. 
In following screenshot, look for letters like w, s, G, D, B - it 
ruins overall impression from the new GUI look.

http://rebol.hmkdesign.dk/files/r3/gui/110.png

Henrik - what I dislike about current GUI though, is its too big 
metrics overally. I especially hated it with Gnome - those guys are 
crazy. To display one dialog, it takes xy percent of your screen 
with no added value, just to display some info to users. Too much 
spacing for my liking. When I look at my current desktop - 1280x600 
notebook with Vista, and compare VID 3.4 scroller and button - it 
is unnecessary big imo, and I am not sure it should be a standard 
... Dunno if I can judge it upon screenshots (as who knows what resolution 
was it taken with), but UI elements as buttons, scrollbars are more 
than 1/3 bigger than they should be ...

What system do you develop under? OS-X? Can you post a screenshot, 
of your system button and scroller along with R3 GUI ones? :-)

Nice - screenshots there - http://www.rebol.net/wiki/GUI_Panels- 
they are nicely self-explanatory addition to source codes ...

btw - thanks for update, I was currious, what is happening in GUI 
field, as r3-alpha is mainly discussing supporting infrastructure 
nowadays ....

We should really have an alpha+gui release

The Friday following thanksgiving is known as Black Friday ... would 
have been sweet to release R3 alpha/gui

he's already said he does not  want to be distracted from GUI and 
core

The other issue is that at the current stage of development, R3 needs 
apps. We need network apps to test the network infrastructure, GUI 
apps to test that, the list goes on. We don't need these to do a 
development release of R3, but we need to do a development release 
of R3 to get these apps made. You didn't think that Carl was going 
to delay the R3 release to write a forum, did you?

For example, somebody stated that the GUI does not yet handle unicode 
strings.

I would if he were talking about DevBase (and did), but I think you 
are overestimating just how long it will take to write. We aren't 
talking about a web forum here, it is clear from the blog that he 
is talking about a R3 GUI client. He can knock that out in no time.

Now, there is in fact a part of the R3 GUI I want to release for 
testing and that is the color conversion functions.

Carl makes R3 usable the only way you can... create a test application 
that has enough real world charateristics to be representative of 
real life work being done in R3.

Look closer, you see:
- server
- async web network client 
- GUI
- local and remote data storage

 and so on.

For me it would be enough, if unicode is already possible in the 
text areas of the new GUI.

Henrik - somehow some screenshots show GUI being a bit distracting, 
not nicely placed elements ...

working a bit on date styles.

view [year-calendar 2008]

gives: http://rebol.hmkdesign.dk/files/r3/gui/153.png

http://rebol.hmkdesign.dk/files/r3/gui/007.mov<-- older video of 
slider styles here. same area as shown in the blog.

Should new development initatives that require GUI be done in R2 
or should one wait for R3? What would the porting excercise be like 
if I were to start with R2?

I would also say that the 'wait is frustratig. Reading the docbase 
article about 'wait in GUI does not satisfy me. I thought we are 
away from stupidly blocking GUIs.

Small status update:


- Mostly doing code cleanups and bug fixes now, so changes are not 
very visible.

- Carl has worked on window positioning and popup offsets, which 
were not working correctly. This should finally enable us to get 
popup styles done. Actually I've already done the first for date 
field. Popups are very simple to do, compared to VID. Just open a 
modal window without a border.
- Icarii has begun working on R3 styles too now. Thanks!

- Still baffled at the concept of MAX-SIZE. There are some places 
where it just doesn't work (see my later screenshots with a funny 
curled-up scroll-bar).

- I'm very pleased with my container style. It has proven to be very 
useful and we will build many more styles with it.

- Autogenerated style list and style tree (will publicize this soon 
here. R3-alpha users can see them in Users/Henrik/style-tree.rmd 
and style-list.rmd)
- Over 80 styles now. I suspect there will be 10-20 more.

- Color policies are being settled, so you can abstract colors away 
from a style into a theme.

- Each style will eventually get a tag block. This makes it possible 
to tag a style as 'internal or 'advanced, depending on where it's 
intended to be used and what it can do. This is very useful in documentation, 
and for some styles that need to work together in specific ways. 
It also makes it possible to hide advanced styles from end-users, 
who won't need to use them directly.


For those who have missed it, screenshots and videos are here: http://rebol.hmkdesign.dk/files/r3/gui/index.rsp

The distinction boundary and suggestion of how to think about tagging, 
is imo - VID level user, making GUI, not wanting to create style, 
vs style tweakers, vs style authors ... - but that is only suggestion.

Henrik - nice - http://rebol.hmkdesign.dk/files/r3/gui/166.png

Any clues as to why Carl decided not to build the new GUI to support 
Unicode from the beginning?

There will be unicode support in new gui, as the all R3 core is already 
unicode aware. Problem is probably the input, but it's not such a 
big problem and will be done soon.

I guess that in AGG you just must call unicode functions of the api. 
But I really don't know details. But the unicode in gui must be, 
else the changes in core were useles.

Oldes: "But the unicode in gui must be, else the changes in core 
were useless."

I think the Core changes would still be useful for server-side apps.

Henrik - I am not sure I have any intention to participate in VID 
world, even if invited. I suggested you and BrianH initially to Carl 
on purpose. My understanding of situation back at that time was, 
that VID 3.4 is almost finished, and 2 ppl are needed to help it 
to finish it. I was probably wrong, as now it once again seem, as 
a regular release. So as for me, what was initial purpose of r3-alpha 
world, now moved to new GUI world.

I can understand how Pekr, Graham and many others feel about the 
lack of R3 releases especially given all the early announcements 
and the first public alpha. However, I really feel that Carl is still 
prototyopng R3, he is a long way from settling on the design of R3. 
There is too much missing for the current version to be considered 
an Alpha (e.g. No modules, no threads, ASCII GUI, Host environment 
& Runtime Core in a single executable,)


This is seems to be Carl's way of working and something that he has 
to work through step by step.

thank you to henrik for those examples  of REBOL3 GUI ;-)  it seem 
to be faster than R2 and perhaps we could have some grid and db grid 
and others..........

but - to proceed in some unified system way, we would need Carl to 
return to Core development, after GUI is done. Without finalisation 
of main interfaces in R3, we still can't do much ...

There is a bug in R2 that causes a memory leak related to a specific 
use of GUI events and network ports. I've encountered this a few 
times.

It seems that every GUI has a version of Apple's Coverflow these 
days. Flash, JavaScript, JavaFX, even WPF and Delphi. A R3 coverflow 
would be a much better application to test out the GUI than a colour 
selector and a forum client. It would be a great demonstration of 
R3's capabilities.

--no slick animation or reflections (too slow under R2 when I tried 
it)--

That's why it would be such a good test of R3 GUI.

First RebDev version was uploaded to our private world a few seconds 
ago.

The first screenshot of the CLI interface:

http://rebol.hmkdesign.dk/files/r3/gui/174.png

Some shots of rebdev on iPhone:

http://rebol.hmkdesign.dk/files/r3/gui/176.png
http://rebol.hmkdesign.dk/files/r3/gui/177.png

Some small news - new R3 alpha released, fixing form/mold problems. 
Carl says, we are very close to start usage of RebDev, hence very 
close to let more developers to touch the next R3 alpha, along with 
GUI. What will follow is further work on GUI .....

Some status (not much since Pekr told most of this):


- Improved console presentation (sounds so Windows-like, doesn't 
it? :-)) in the latest R3 alpha. http://rebol.hmkdesign.dk/files/r3/gui/178.png

- Carl wants to do a larger release of R3 "soon". This involves a 
merge of my skin or parts of it. I'm not sure everything you see 
in screenshots can go in, because those parts are not clean enough.
- Still working on RebDev.

- Carl noted that RebDev helped him find many bugs in R3. Some of 
those are fixed.

- GUI has not progressed for a couple of weeks as I'm working on 
a big R2 project. I will get a few days in January to help, but I 
won't get more time until mid-March at best.
- Some Devbase submitted changes and fixes are added to R3.

The intended priority for RebDev front-ends is:

1. R3 Shell (doing this now)
2. HTML mobile (doing this now)
3. R3 GUI
4. HTML pretty
5. R2 Shell
6. RSS feed
7. Whatever people want to do.

So - work on GUI is postponed right now to above mentioned activities. 
Once it is done, there will be release to more wider audience, before 
any work on GUI continues.

http://rebol.hmkdesign.dk/files/r3/gui/... but Henrik's site is 
not running now ...

IMHO rebol makers shouldn't worry about these side things... they 
should take care of the language design, it's runtime ( easy to extend, 
embed, stabile,. fast) , and the core/native libraries that they 
decided to bring like networking, gui.. if that will be good I am 
sure community will bring in the various external bindings, and build 
rebol frameworks/libs etc (like they have so far)..

For a GUI version to do this, one could open N windows in the same 
RebDev script. I would love to see that.

is there a http or gui client ?

no GUI client, only read-only mobile client.

I agree with btiifin, that 'tags for numbers would be nice. It would 
be nice to have e.g. R3 heading tagged as R3, and refer to it as 
R3 instead of the need to remember the number. I think that once 
GUI is available, this point will be moot. But I agree to provide 
some directory navigation like functionality.

A GUI client will certainly help usability, but since we have console, 
we can use it over SSH and that's a great thing.

Graham, the console client is also because Carl uses SSH quite a 
lot in different locations, which is why he started with a console 
client instead of a GUI one.

kib2: why? Perl 6 is in development two times the R3. And one year 
ago there was a public alpha. Soon enough there will be another one. 
This time with final GUI architecture (although not complete yet)

pekr, no, r2 console version is low priority. Carl wants to do R3 
GUI version next.

good to know GUI is next. It will help to further improve GUI ...

Graham, that would delay the GUI.

So Carl1 could focus on rebdev, Carl2 could focus on tasks and Carl3 
could focus on modules. Carl4 would work on the GUI and ReBrowser.

Pekr: I wasn't aware of the GUI stuff.

It seems rebdev mobile is down right now, so I made a screenshot 
of Steeve's example post:

http://rebol.hmkdesign.dk/files/r3/gui/182.png

I work on the GUI and point out bugs to Carl.

Yes, but he is very busy with QTask for the moment. He has contributed 
HTTP, REBOL/Services and the first prototype of the VID3 GUI.

well, there's me (GUI), BrianH (smart guy), Brian Tiffin (docs), 
Cyphre (graphics), Gabriele (network/GUI), Pekr (communications), 
Maarten (network), and about 10 others who've made contributions. 
Didn't really want to mention people in case I forget important ones.

And you have the light version currently, the console version.

It will be worst with the GUI if Carl doen't change his conception

The chat can be changed now because it's tiny enough, 

But 50% of his conception is wrong and has to be rewritten to deal 
with direct access in files instead of loading all in memory.

Yes i read carefully his script, 50% of it must be rewritten now...

More Carl will developp the GUI and the console version with wrong 
choices (to my mind) more it will be painfull to rewrite all later.

Many eyes make bugs shallow. We need more developers, which means 
we need a public release. Priorities. We can fix chat *after* the 
public release. As it is, getting the file store in place is a more 
pressing need. That way we can release and track the source. Once 
the source is released we can make fixes as needed. The priority 
needs to be on testing R3 itself, not the chat client. We aren't 
even going to start the GUI chat client until after the R3 public 
release.

Nicolas - every sane person should be able to read between the lines, 
no? So I tell you that all you can get for now is alpha, and you 
ask, if it is going to be an alpha? Waht if NOONE really knows, when 
we will be in beta stage? There were various propositions, and mine 
proposition was to create 3.0 with fixed featureset, and then go 
with 3.1 and later, adding other stuff. I can e.g. imagine 3.0 beta/full 
release just with GUI and R2 level featureset, plus Unicode, which 
is in there. Later can come things like plug-ins, threading, etc.

From Pekr: "I already asked Carl for some resolution towards RebDev. 
I really don't like it. We should get back to the main task - R3. 
So - my proposition is to create some plan to link apropriate RebDev 
chat to CureCode and other chat to current DevBase and get back to 
R3 GUI to get it to state, where we can rework DevBase, create RebDev 
GUI client, etc."

It is easier to add the VCS parts of DevBase to RebDev chat and rename 
RebDev to DevBase (the current plan) than it would be to get DevBase 
into a usable state. I know - I am the lead programmer of DevBase.


What we really need to do to is get the project to the point where 
we can release it to the developing public without it turning into 
a disaster and the project dying. We needed a way to enable and organize 
development discussions, completely integrated with DevBase, to help 
people cooperate instead of hinder the project. We have that now.


I agree that the CLI client for RebDev sucks, and that we need a 
GUI client. We don't need it *now* though: RebDev already works better 
than AltME for our purposes, and we can do the GUI after the public 
release. The messages we write now will still be there later, ready 
to be read in the GUI client if you want to wait for that.


We absolutely do *not* want chat in CureCode - comments in CureCode 
are *documentation*, not chat.


Because we went the route we did R3 is nearly ready for release to 
the developing public (as an alpha). If we had done as you suggested 
we would not be so close to release. Keep in mind that what you are 
suggesting we do is what we were doing before, and it failed badly. 
That is why we are doing what we are doing now, which is succeeding.

You might have noticed the creation of the GUI world, even though 
we already had an alpha world, and the tiny number of people who 
were invited to the GUI world, especially at first. For that matter 
remember the creation of the alpha world in the first place. These 
events happened because AltME failed as a medium for development 
discussions.


AltME lacks the moderation and organization facilities of RebDev. 
If there are more than several people in a world communications break 
down. One troll and the process grinds to a halt. If AltME was good 
enough, R3 development discussions would be happening *here*, instead 
of talk about religion and politics.

load-gui doesn't work either.

Nor would the GUI if you *did* load it, which is why it is not yet 
included.

What's wrong with following? (except the fact that we can't user 
/ as a start of path datatype, which complicates the request)

>> parse [/ /R3/GUI] [word! path!]
== false
>> parse [/ /R3/GUI] [word! path!]

No GUI yet, as I'm still busy with something else. I need to do a 
serious code audit before it's included. Many things are still up 
in the air.

Pekr, i thought you were parsing the /R3/GUI as word!.  Ok, I misunderstood. 
 Thanks Pekr.

Okay, so there's no GUI in this alpha(stated above)?  Also, why aren't 
the actions of buttons in blocks anymore?  That seems ridiculous.

uh ? what do you mean ? 
>>load-gui
then
>> view [button "test" do [print "test"]]

Ah...I didn't know you could load the gui.  Thanks.  And the button 
action isn't in a block because you're executing the block with 'do. 
 I guess it's not that big of a deal, but it's annoying to me that 
view[button "test" print "test"] is also valid

oh, the GUI is there. I retract my previous statement. :-)

well, then that means we can start working on simple GUI demos for 
Carl.

Have you tried http://www.rebol.net/wiki/R3_GUI?

I'm uploading some sources to my site at:

http://rebol.hmkdesign.dk/files/r3/gui/