AltME groups: search

eh? you launch demo, go few items down in text-list, select text-view, 
and it crashes to console with:

Cannot parse the GUI dialect at: 'set ts read-string %main.r

the demos will of course have to be made correctly. gui-demo.r is 
only a launcher.

you need to 
   load-gui
first.
Then, don't use layout, that' sso R2. Just:
  view [button "press" do [print "pressed"]]

Graham, I think you can get a list from within the R3 alpha as discussed 
here: http://www.rebol.net/wiki/GUI_Example_-_View_all_styles

r3-alpha as well as r3-gui AltMe worlds are completly dead ...

.... hopefully it is an interim state, a preparation for GUI client. 
New chat system starts to turn being interesting - threaded discussions, 
user ranking, tagging, searches, secure, movement of msgs/headings 
(reorganisation), recently files sharing is being worked on. The 
long term plan is to replace Altme ... with better Altme :-)

yes, but with MS console crap, it is really a pain to use the chat, 
as you can't increase number of columns. I hope some primitive GUI 
comes soon ...

As far as I've seen, there's currently no way to run a GUI script 
with R3 alpha. Am I wrong ?

kib2: that fooled me first, but type "load-gui" and you have the 
GUI system available to you.

kib2: about the GUI system, it is very far from done, so don't be 
too disappointed. Also we have a private bug list for the GUI alone.

Henrik - hopefully we are close to being back to GUI soon ...

Primary issues with the GUI:


- Layout resizing can result in too much horizontal stretching and 
too little vertical stretching.
- Style list is very incomplete.
- Keyboard navigation is very sparse.
- No rich text editing.
- Skin will become more esthetically pleasing later.

- Some nasty bugs in the low level graphics engine, not yet solved.

What is not likely to change:


- The design of the system feels very solid. Every time a change 
or addition is made, it's 5-10 lines of code.
- Style creation process, so feel free to make your own styles.

What is likely to change:


- The layout engine gets new features now and then to simplify the 
dialect.
- Popups, dialogs.

The GUI demo needs to be made smaller (vertical space)

Paul, that is the plan. The old monolithic REBOL will go away once 
the module system is up and running. There are already functions 
flagged for moving into non-default modules - especially ones that 
have limited use or too much overhead.


But remember that we add these mezzanines so that we can use them, 
and many are just cleaned-up versions of code that is used in the 
GUI, the other mezzanines, the intrinsics, etc. We are trying to 
keep things as efficient as possible so that the code that is loaded 
by default is minimal. Still, you will have to realize that REBOL 
is partly written in REBOL so you can't get rid of everything.

The advantage to the current chat is the messages in it, not the 
UI. Those messages are still going to be there when the GUI client 
is in use, and we needed something in place to get the information 
out there and managed (AltMe wasn't good enough at management). However, 
you have once again figred ot the plan: Carl intends to run, not 
walk, away from using console for chat.

You need to ignore the UI of chat for now, because the important 
problem being worked on now is getting the source file database integrated 
so developers can see that source you were requesting. Then we will 
have more developers (in theory) and we can get the GUI working well 
enough to write the GUI chat client you also requested. Which shouldn't 
be that hard - all of the tough stuff is either handled by the chat 
infrastructure (which is mostly there now) or the GUI infrastructure.

If you want to help now I can get you an account on the current DevBase 
- be warned that the GUI is not great yet (because it's R2).

just want to express my oppinion that I am happy of the core things 
beeing in focus (language, runtime, core libs (tcp...)...) not the 
"addons" like gui

I sort of agree, but most of the core bugs were discovered and fixed 
during the course of writing the "addons" like the GUI or non-core 
mezzanine functions. Most of the core language enhancements came 
from the GUI work too. I expect the work on higher-level port schemes 
will help debug the low-level port code. You need to write the high-level 
stuff to help refine the low-level stuff.

most of the core bugs were discovered and fixed during the course 
of writing the 

addons" like the GUI or non-core mezzanine functions" yes, I fully 
agree with this and understand that higher level code tests and helps 
design (reiterate) the low level that it's build upon...

but I still take decision to make chat in CLI first and not focus 
on GUI etc too quickly very highly. Because having a good core on 
which gui (or many gui-s) and all things are built seems 100x more 
important than having *something to show* .. a nice gui on a patched 
core... I appreciate the priorities and focus, and this tells me 
that I can rely on R3 being good.

Graham, an issue with 100% CPU usage every time a GUI was invoked.

Switching from AltME to RebDev chat has been very hard for me and 
since I am not a core developer I will be in read only mode until 
the GUI version will be released.

However I am not negative about how things are going. We finally 
have a pubblic alpha. an upgrade mechanism, an internal chat system. 
GUI is going to be developed and also documentation reviewed.

We already have GUI in R3 but you gotta load it first via load-gui. 
 I know it is still in development though.

It will be the foundation for the RebDev GUI side.
Everyone seems now in the same cavern where Carl retired himself.

I'm not a fan of rebdev either but I view it as the catalyst for 
the GUI side of it.

However we are in the middle of a big change. Once the new messaging 
system and the GUI will be complete the whole speed of REBOL3 will 
shift up again.

Chat system feels good. But if we do add concepts like reply to particular 
message, and system is no more flat, we are not able to easily handle 
it without GUI anymore. Some commands are changed in quick pace, 
some changes don't make sense to me.

( + if I will need gui for desktop server, rebol has lighweight software 
rendered gui, factor also has a gui but on windows it's opengl based 
which is not really practical for a gui.. even casual games on windows 
try to use DX7 renderer for maximum compatibitily and avoid opengl 
beacause of driver issues)

You're right, it's gone. The new GUI uses Draw for its elements, 
so the loss might not have been noticed. I'll check.

Hope we get a GUI for R3 chat soon ... I find it just too hard to 
read it in a console.

I thought Henrik's R3 GUI skills would have manufactured a GUI for 
RebDev by now.

R3's GUI is missing some necessary styles for a RebDev client, notably 
grids. Filling in the blanks needs more programmers, so we are focussing 
on getting the file management portions of DevBase integrated first 
so we can get other people involved in the process. Priorities :(

... untill there is GUI to DevBase, many ppl will prefer Altme channel 
for quite some time ...

so the layout parser sets the action properties of each gui element

the big question ... will this make making gui's harder or not?

I still like the cleaner separation of gui from function

There is not just general 'do, like in R2, there is now many reactors. 
In order to better understand new architecture, here's some docs 
- http://www.rebol.net/wiki/R3_GUI...

Unobtrusive Javascript

 is based on the principle that the behaviors attached to the structure 
 need to be optional, because Javascript might not work or be turned 
 off. This will *never* be the case for R3 GUI behaviors, so the principle 
 doesn't apply here.

BrianH, how does R3 styles work?  I didn't notice it on the R3_Gui 
page

(sorry, I was busy). Imagine if you took the structure/appearance 
separation of HTML/CSS to the extreme, and had *no* appearance code 
in your layouts, just behavior and structure. Put all appearance 
code in the styles. That's the R3 GUI. Oh, and the styles will be 
themable too.

You style styles (what other GUI systems call controls).

You can define the button actions as you please. If you look at this 
shot:

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

The 5 colored buttons are separate styles, based on BUTTON.

No decision yet. I call it R3 GUI.

Anyway I hope R3G has robust keyboard handling .. for speed a mouse 
driven gui sucks

The JS GUI is pretty much the de-facto standard GUI

to give smooth GUI changes

Graham - what JS gui? Is there actually any JS GUI? Or are you talking 
about web gui in general, hence HTML, CSS, JS?

Graham - I think noone criticised you.  But honestly - you started 
your description like if R3 GUI plan would need any inspiration in 
JS.  There were many many discussions about it, and also from some 
docs it starts to be apparent, how R3 GUI is flexible ...

... besides that, there also were some talks of R3 GUI generating 
some output to web .... we will see, where all this leads ...

No need to reopen the discussion, but the thing you wanted was to 
separate gui description (elements and its placing, look) from the 
action code?

So, one person could design the gui, and another could design the 
functionality

There is surely still time to talk about those things for R3 gui.

While basic concepts are in place, there still might be room to allow 
many things. R3 gui is really very flexible ...

You will be able to post some notes via chat system. Dunno when we 
will be back to GUI though. RebDev aka DevBase is still not finished 
...

The R3 GUI does the separation of form and function better than Delphi 
(or even HTML/CSS/Javascript).

Yup. The equivalent in the R3 GUI is to change the implementation 
of the actions.

E.g. JAVA GWT does that - you can have JAVA native GUI, as well as 
very good browser based one - http://www.gwt-ext.com/demo/

Pekr: Delphi (and Lazarus) most definititely separate the description 
of the GUI and the code. They are described in different, though 
simiiar langauges and saved in separate files; .dfm for the GUI description, 
.dpr (or .pas) for the code.

I have a question about the Gui_Basics example in the R3 docs.  The 
ex. under Adding styles won't work for me.  title "Opinion Survey" 
comes back with title having no value - this after load-gui

In fact, it's not the demo. Doing a "load-gui" from the console crashes 
all.

I'm running r3-a35 and load-gui is working for me.

looks like changes in the GUI dialect

That is 2 bugs rolled into one:


1. The script used to be called main.r, which is what it is called 
there.

2. The R3 GUI indicates an error in the dialect, when actually the 
file can't be read.

I just read about 'gather function and would like to ask about its 
area of usage? In the past, in FoxPro DB days, there was common method 
to get all for related data, via function called gather, and the 
reverse was to set a form from an array, via scatter fucntion.  I 
think that if gather takes just one field from objects, we might 
use good name for some limited functionality, whereas it could be 
good name for GUI forms (panels) and gathering of info from all objects 
in one run?

We don't really need scatter/gather for the R3 GUI, as it already 
works with SET-FACE and GET-FACE using panels.

GATHER was your request, Henrik, specificly for use in the R3 GUI. 
Are you withdrawing the request? I need to know soon.

There are some things I can't understand in the demo : when you click 
on source, you don't get the full source but just a part of it.

Also, I've tried launching this script (from Dragger demo) :

REBOL [ ]

load-gui

view [

doc {
^-^-^-===Drag the boxes

^-^-^-Blue boxes are unbounded.

^-^-^-Red boxes are parent panel bounded.
^-^-}
d1: free-drag
d4: lock-drag red
panel 0 80.200.80.80 [
    d2: free-drag
    d3: lock-drag red
]
]

...and got a parse error : why ?

have you studied how the R3 GUI works?

The error that has occurred above is that the "demo-let" that kib2 
looked at is not properly documented. Its script header should declare 
what its dependencies are and in what environment it should be run. 
This is a constant source of time-wasting for everyone, as an undocumented 
script apparently advertises that it has no dependencies and can 
run on its own. So all new-comers to the script will try it in the 
console themselves and see it doesn't work. Now the wondering begins: 
"is it supposed to be working or is it still in development?" etc. 
It's not kib2's fault for not having studied how the R3 GUI works.

http://www.rebol.net/wiki/R3_GUI

I don't know much about the progress of R3 GUI yet.

The latest shots of the UI can be seen at http://rebol.hmkdesign.dk/files/r3/gui/
but it is still changing and far from done.

I noticed the GUI demo in R3 is very buggy.  Sometimes it just eats 
CPU and does nothing.

well, if you can believe it, I've been "following" REBOL since it's 
beginnings, but never really pursued a deeper understanding of it 
due to various reasons (lack of adoption, closed nature of the language, 
lack of time on my part, etc). I have always, though, felt a very 
strong attraction to it because of all the possibilities hinted at 
- the lightweight nature, the clarity of expression, the built-in 
GUI, dialecting, and so on.

I just visited AGG newsgroup after one year, and some interesting 
projects do emerge. Community agreed that any open work will be done 
to BSD version (2.4), which is a good sign (although RT has probably 
no problem obtaining special license).


Dunno why, but there are (apart from Cyphre) another few Czecho-Slovak 
guys, and one of them is doing rather interesting project. AsmJIT 
and BlitJIT libraries, with MIT licence. Author says about it:


Antigrain is great piece of software with great licence, 
but without 
better acceleration it's quite slow.  So blitjit can increase speed 
of 
your applications in way you can't imagine. For example is there
complete 
MMX/SSE2 extension for antigrain ? No, but don't panic, other
libraries 
also have problems with cpu specific features.


The reason why it might be interesting is, that generally there is 
no good 2D HW acceleration out there, and here is what author of 
LibNUI answered to Cyphre:


I'm the author or nui (http://libnui.net) which is a GUI toolkit 
based  
on OpenGL (and now OpenGL ES / Direct3D). This project was 
started  
some 8 or 9 years ago and I've been working on it and with 
it amlist  
daily for that time. My experience is that it's some 
orders of  
magnitude harder to have HW support for those features 
that to add a  
JIT to your engine in order to optimize your bottlenecks 
(I've done  
some of that for pro audio dsp code). The reason is 
that no two chips  
work exactly the same and behaviour even tend 
to change over driver  
releases. To diferent cards, even sometimes 
from diferent vendors,  
will not give you the exact same scan convertion 
or rasterizing, and  
I'm not even touching shaders diferences...


It seems to be x86 only so far, but maybe guys like Cyphre or BrianH 
or Anton or anyone skilled in those areas should keep an eye on those 
guys :-) Here's a link:

http://code.google.com/p/blitjit/

... as for those another AGG based Czech and Slovak projects:
http://www.rw-designer.com/
http://www.crossgl.com/

Shouldn't we get those guys hooked to REBOL? :-)

Henrik - as there is not much comfort in RebDev chat - not using 
other gob types contradics their purpose, no? I do understand, why 
keeping GUI desing simpler might have advantages, but stating that 
effects are not needed so far, because Draw dialect can serve us 
well for GUI purposes, might also mean, that we could discard effect 
pipeline? :-)

No, it just means that I have not needed effects yet. I think they 
should definitely be possible, but we have to be careful not overexposing 
it. MAKE-GOB could introduce a level of control that we don't want 
in a style, making a single style a big mess with hundreds of lines 
of code, because you have to reference GOBs.

So far GOB management happens in 20-30 lines of code in one specific 
place in the R3 GUI design. It's very tight and controlled and by 
adding an effects GOB there, would make sense in the R3 GUI design.

Somewhere in rebdev. We have a high level GUI thread there. Might 
as well create a low-level one too.

Ah, damn, another big restructure of DocBase? :-) While Docs become 
more readable and graphically nicer, the person doing restructuring 
does not even distinguish Gabriele's GUI to Carl's one, so it really 
becomes an organisational mess and he ruined Carl's initial Docs 
for GUI ...

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

Some shapes in this image was done that way.

Those wanting to influence VID resizing model  - http://www.rebol.net/wiki/GUI_Face_Sizing

http://rebol.net/wiki/GUI_howto_debug

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

http://rebol.net/wiki/GUI_howto_debug#Runtime_Debug

I want to get to 't because I'm trying to hack together a GUI for 
DevBase because the console client is painful to use and I thought 
this might be a good way to introduce myself to some of the internal 
workings of the new GUI.  I want to redefine "say" in the chat.r 
to update ''t with the text it would normally print.


To have changed what VIEW returns such that I can't actually get 
to the face produced is unbelievably confusing.  There must be a 
good reason for it though, what is it? 


You do realize that if I have no way creating a pointer to a face 
then I can't use get-face, set-face, etc. on it don't you???

I need a solution to a problem and that solution very well may be 
a paradigm shift on my side.  I just need to know how to interact 
with the GUI from outside the GUI code OR I need an explanation of 
why the ability to do has been removed in the latest release of R3's 
GUI.

Something I did in my code all the time with VID 2 is window: layout 
[ ... ]  then go ahead and connect/modify/abuse the window in any 
number of ways and then show it later.  I'd often set up panels this 
way so that I can have the faces built ready to switch out at the 
click of a button and this would allow me to easily keep different 
areas of the GUI in sync easily but now that Layout is gone I can't 
do it this way.  The real question here is why is view returning 
the gob instead of the face?  Seems on how I actually have the GUI 
source code sitting on my machine, I can hack this to give me what 
I want the problem is, it would be a hack which means that I can't 
hack it to give me what I want because what I want is not a hack. 
 Get it? ;-)

I'm actually not seeing anything in the new GUI that allows you to 
find a given face's parent.  It's really very frustrating me...

I posted my reaction to rebdev chat too. I am missing some aproach 
to easily traverse gui:


- there is bog/pane, but not face/pane. There is face/faces e.g. 
for panel style. If it is the same concept, why name it differently?
- there is no face/parent-face to traverse backwards

- face/gob contains just one gob. It also seems to me, that it is 
not even a pointer to the gob, but not sure. Not sure if it would 
be usefull, but currently face can't be built from multiple unrelated 
gobs. You have to have one gob, and other ones in gob/pane

Maarten, a few thousand? Not likely to happen right now and as Carl 
said, he would add features as needed, and there's no need to support 
a few thousand users right now. Right now the next step is a proper 
GUI.

Ammon, it sounds simply to me that some features for setting window 
titles, etc. are either missing or undocumented. I'm pretty sure 
you're not meant to use obscure paths to access features, but to 
use SET-FACE, GET-FACE, SET-FACET and GET-FACET. These features are 
much more powerful in the R3 GUI than the ones in VID.

And if they're missing, it doesn't take long to add them, so instead 
of "getting annoyed as hell", ask nicely on rebdev and Carl will 
probably find some time to add them. :-)

... and - it was declared from the very beginning, that GUI is much 
needed here, and it will be surely done ...

I was against new system, but I am satisfied with Carl's explanation 
of his POV. He needed streamlined channels for chat, bugs, CVS, filesharing. 
New system, in comparison to AltME, gives us:

- threaded discussions
- ranking
- tagging
- threaded discussions
- message/topic moving
- versioning system
- document management. Docs posted anywhere to any message.
- console version


So far, the big minus is - no GUI client. But - that might be over 
in few months ... So - if we think of RebDev as nothing more than 
RT's supporting infrastructure, I am OK with it. It is just that 
for fast dev related chat, e.g. nowadays GUI related, it can't reach 
Altme comfort and speed in not more than 20%. Threading is very confusing 
now ...

I'm updating DocBase GUI docs.


1. Changing the links at the bottom of each of the pages to point 
to a single template so that they are automically updated across 
all pages by changing one document.
2. Adding [[Category:GUI]] to each of them.

3. If I have time I'll start working on a VID2 to 3 document that 
describes what changed.  Things like face/parent-face is now parent-face? 
face.

I just wanted to mention that when I run the gui demo and click the 
"text view" test it causes an error on my vista machine.

right now, I'm rebuilding the MAKE-TICKS function for the R3 GUI 
as I need more flexibility, and it would be greatly simplified and 
easier to understand with something like this.

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

Make-ticks was used in the 5 sliders at the top.

view is currently swiss cheese and the underlying Core has some large 
gaps that really need addressing before GUI sees the light of day.. 
IMHO..