AltME groups: search

shadwolf -- this group is for <For discussion of the R3 GUI> (see 
first post).
You are posting about the whole of R3 and its development cycle.
This is not the appropriate group for that.

Please switch to a group that is on topic for that.....Or use one 
of the generic ones, such as ~vent as Anton has suggesfed.

And it won't change the actual noone cares about rebol situation 
and less about rebol3 GUI...

thank you sunanda ... but then we don't have any idea of the converting 
lenght ... ok so the info are ''at August 14 th  2010, the Rich text 
dialect is adapted to the new project GUI using host kit . And Robert 
could compile it properly"

Cyphre, you GUI update inside a network looks similar to what I did 
... but which didn't work!  Ok, time for me to try again.

All my GUI updates occurred after network activity completed.

Just in relation to the binding issues being discussed in core, how 
does R3 gui work ... are named gobs in the global context or private?

the GUIE context may also change, once the R3 GUI becomes a module.

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

Slightly more meaningful display of form validation.

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


The ABOUT-PROGRAM function. Only a few lines of code to produce an 
About window. Information is grabbed from the script header.

so once again: complaints about issues that have no relevance to 
the current state of the R3 GUI. I would rather have wishes for dialog 
handling, form validation, how the help system should work and how 
to build more intelligence into the GUI.

ok that's just what i noticed and i'm sure most people will notice 
that too ...  but it's a now in days visual fashion to have flat 
styled GUI but in general it all flat appart the buttons and  the 
text fields or text area wich are sunken and break the visual monotony 
...

henrik GUI was is and will always be for ever look issue over functionnalities 
...

because pretty or ugly: it will not help to speed up development 
time for a large program from months to weeks. having a proper GUI 
architecture saves money in the end. money! :-)

We need to get the basic infrastructure code to a level that it can 
be used by others and won't result in everyone fixen (and by this 
forking) the R3-GUI code.

It doesn't make any sense to fragment our community by having 10 
different GUI libs.

host-kit was the first mandatory step so that we can now fix GUI 
bugs that we find while developing the base infrastructure code. 
This is now done.

basic-styles: We need to provide some basic styles with resizing 
etc. included, so you can see how this all works. This is what we 
currently do. Sprint review is today. Than I will have a better overview 
about where we are at the moment. ASAP we will release the GUI to 
you.

If say I wanted to try helping out with the graphic design of the 
GUI, what would be the best approach? Create some mock-up using a 
graphics design app? Can REBOL create anything I could come up with? 
What are the limitations I should impose on the design in terms of 
UI states, style overlapping, transparency, etc?

but even there, the problem could be that a concept that looks good 
as a 2D design can't be implemented adequately in the REBOL's GUI

Robert i'm agree with you we are 10 we can't make 1 GUI lib by person 
 that's rediculous...  As basic lib i want it to be nice apealing 
and fonctional that's all i don't care since it's not flat and drak 
grey with 10 times the same widget that's ok with me ... (ok let 
say if i have to choose betwin having it flat  or having it dark 
grey i would choose having it flat)

Gregg sorry actually  i'm very very sick ... i spent past week after 
our interresting (what was the word damn ...) "flow of nonse" (maybe 
i don't remember and i'm too tired  to remember anything)  in bed 
spiting my pulmons to the floor...  so i think i'm out for another 
week and if eventually i'm not dead at the end of next week i will 
try to send some ideas .... but basically i would say if it's not 
dark grey and  flat it's ok will me .... we use AGG for the gob design 
and rendering this allow us some creazy stuff that will promote the 
new VID and make it apealing .... VID gui never seen before but not 
because they  are super ugly  and all childish with glowing primary 
colors ....

think that agg can offert us really creazy effects motions shape 
changes solidity changes.... etc.... so for me the perfect gui Lib 
would play with those aspect in a clever way and maybe be the base 
for people to say ok .... and what if my next application would be 
a cloud ... a cloud have a non definited shape you can cut it in 
pieces than rearange those pieces you can make some part more dense 
some other part lighter   you can shrink it or completly change anytime 
it's shape .... the kind of interface that would be just  so fun 
to exploit use a multi touch screen ...

The current GUI style is just to see anything at all. Henrik has 
a concept how to decouple the decoration and look from the rest. 
We need to get this up & running in a way that it's not changing 
on a dayly base. Than we will release it and you can start doing 
all the nice GUI looks.

This shouldn't distract from the GUI work being done in code, should 
it?

Defense of situation: Because the foremost thing that has been criticized, 
when posting screenshots is the appearance of the GUI, as I was experimenting 
with a skin early on, which was dropped. As creators of professional 
UI systems know, looks are secondary, while functionality and consistency 
is primary. This is a point, I've been trying to make with the VID 
Extension Kit.

The problem with creating artwork now is that there is not a good 
method to implement it, other than by having to get your hands dirty 
and write the styles. There's no easy way to shove photoshop images 
into the R3 GUI. Maybe that will happen at some point. Feel free 
to post imagery if you like, but I'm afraid it's a bit of a waste 
of time right now.

Of course I don't expect that artwork can just be dropped in and 
we have a new look - I've done enough GUI work to know what the limitations 
can be. Still, even if the rendered look has to be reproduced programatically, 
there could be a benefit in starting to evaluate different proposals. 
A site like 99designs seems to be a pretty cheap way to get various 
ideas thrown around.

About UI fads, I have been contemplating various designs that are 
not typical, but with things like the iPhone out, it's very difficult 
to differentiate from that, in a way that makes the R3 GUI easily 
recognizable. I would like to make a GUI that one doesn't forget 
that they have seen, similar to when you saw or used OSX the first 
time. I'm fairly resourceful, when it comes to building consistent 
GUI artwork.


About animation and gestures: If this is done correctly, they can 
be added as subsystems of the GUI.

Our primary concern is that RM Asset needs to use R3 very soon for 
a production app for a customer, so the focus is to make all things 
that are normally handcranked in VID and RebGUI, such as form validation, 
handling of database records and a complete UI test framework fully 
automatic. If it takes 2 days instead of 7 to build and test a GUI, 
Robert saves money and can ship earlier.


Over the past year, with the rather big RebGUI app, NLPP, that RM 
Asset has built, we've learned exactly where we need to make things 
better and what works OK and certain delays, because of GUI architecture 
limitations have cost money. It's no longer for convenience or for 
advertizing the GUI as easy, but hard money savings are involved.

I'm not sure I follow this "It's no longer for convenience or for 
advertizing the GUI as easy" - so the current intent is to get something 
out the door as opposed to creating the easiest to use UI framework?

no, it's both things. The GUI system must be easy and quick to work 
with. That's how we build apps.

I think eye-candy is a very important aspect and, as Henrik said, 
making a GUI that is breathtaking and rememberable is a lot of work 
but worth doing it.

I know a guy who recently left Adobe to do GUI design on contract. 
 He was employed as a GUI designer and has been doing it for many 
years now.  I've suggested to him that this 'could' be a good way 
to get some recognition 'IF EVER' R3 made some ripples in the development 
world.  I didn't get a firm committment that he would do it or not, 
but I will follow up to see if he wants to make a submission of a 
mockup or two.

Perhaps rather discuss the GUI looks we should be considering the 
mechanism of how that look is implemented.  Is it all draw based? 
 No bitmaps at all?

What's this? :-) http://rebol.hmkdesign.dk/files/r3/gui/234.png

can't wait for the time, when you will release some alpha or beta 
of the GUI for us to try our first experiments :-)

uh ... it almost feels like noone is really working on gui right 
now?

in the process what is the most disgusting is that instead of turning 
this R3 GUI project a real community effort you sabotaged it you 
let it rote then you proposed your own monney based speudo solution 
that for the moment have produce nothing more than was previously 
done by carl effort after his rejection of Gabriele's work. 


After you can say to me you are in need of monney blah blah that's 
the case for many more than the "elected ones" ... you create a close 
group where the knowledge is retained and not shared. And when someone 
like me comes to get information try to discuss things alternative 
options futur he get insulted and systematically pushed aside.

I predictate your faillure in less than 4 more moth ... January 2011 
maximum the actual bounty hunters R3 group will be disbanded and 
nothing concrete will have been done apart the extraction of VID 
from R3.exe to hostkit. When you take money you do things like professionals 
that's the minimal things this means a list of what will be done. 
A roadmap with important steps and release dates  for those important 
steps before starting anywork you make that dev plan to appreciation 
to the public you debat it serriously you remove things you add things 
... You try to get involve the most possible people that have been 
already involve in R2 GUI use or creation because they have the practice 
knowledge and experience. 


Thousand way of being serrious starting a positive attractive motion 
for this part could have been done but by lack of interrest and generosity 
you end doing what you are doing ...

I predictate your faillure in less than 4 more moth ... January 2011 
maximum the actual bounty hunters R3 group will be disbanded and 
nothing concrete will have been done apart the extraction of VID 
from R3.exe to hostkit. When you take money you do things like professionals 
that's the minimal things this means a list of what will be done. 
A roadmap with important steps and release dates  for those important 
steps before starting anywork you make that dev plan to appreciation 
to the public you debat it serriously you remove things you add things 
... You try to get involve the most possible people that have been 
already involve in R2 GUI use or creation because they have the practice 
knowledge and experience. 


Thousand way of being serrious starting a positive attractive motion 
for this part could have been done but by lack of interrest and generosity 
you end doing what you are doing ...

ladislav i foresee what i want and this R3 gui have not better reason 
to succeed than the previous intents since it's based on the same 
main problems to it's achievement in time you will get it.

I have no reason to shut my mouth when i see things so wrong. I exposed 
what i though of this process now please don't fuel me anymore do 
as i was far and in january 2011 remember i said this was going to 
a faillure.

PAD is a style, so it produces an object which then moves the next 
faces one grid place forward, just like any other style.

This layout:

view [panel 2 [button pad pad button]]

...produces this:

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

Very little. Most of my VID knowledge comes from DevBase 2 and the 
VID resize project. Aside from that, very little GUI work in REBOL, 
just (many) other languages. Most of my REBOL code has a web or batch 
UI, or no UI at all.

Likely not in the R3 GUI. We did a lot of work to separate layout 
and behavior.

Not unless it has been changed recently. According to the design 
of the R3 GUI, DO doesn't switch the layout dialect into DO dialect 
mode, it declares an action for the button (in your example) to perform 
when clicked.

Does this still apply to the WIP ? http://www.rebol.com/r3/docs/gui/gui.html

Well, the R3 GUI has very little in common with VID2. It is designed 
based on completely different principles.

The reason we never refer to the R3 GUI as VID (for the last 2 years) 
is because we don't want to confuse people. The R3 GUI has nothing 
to do with VID.

Yes, Henrik, you are more familiar with the recent work on the R3 
GUI, please explain :)

anyway, Vid has the ability to switch dialects at gui layout ... 
but as r3gui .. i don't know...

http://www.rebol.com/r3/docs/gui/reactors.html

BrianH: stop claiming we don't refer to R3 GUI as VID, please? Where 
did you find out such a claim? It was VID 3 (Gab's version), and 
Carl's version was marked as VID 3.4 by Carl himself imo. There is 
NO point to stop calling it a VID, unless we find another marketing 
name, just because the architecture changed ...

Yeah. And then we decided to stop calling it VID because of the confusion. 
There was even a blog where a new name was requested, but it never 
came to a consensus. So we ended up calling it the R# GUI by default. 
The only one who still calls it VID is Pekr.

(length? "rock") < (length? "marshmallow")

What's your point? There are docs and tutorials for VID out there. 
They don't in any way apply to the R3 GUI.

vivid.com si a porn-site though, so I think that VIVID is 1) not 
useable due to the factor mentioned 2) maybe too general name to 
google for? maybe vivid-gui.com would work though, dunno ... let's 
not opent the topic right now, there was something like 40 or more 
names suggested :-)

CAn we have a better calling for R3 hostkit package ... since it's 
supposed to haven't change on API level can't we distinguish the 
number for the hostkit api version and a number for the GUI related 
engine ? something like r3-hostkit-102-GUI-still-the-same.zip ?

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

In my GUI trial, the resizing of styles use a small amount of primitives.
When a resize event is triggered. I mix them in an intuitive way.

....
when [
	resize [resize xy]  ;full resizing both direction
	resize [resize x]   ; resize the height only (for menu bar)

 resize [move x resize y] ; move the x offset, resize the width (for 
 right scroll bar)

 resize [move y resize x] ; move the y offset, resize the height (for 
 bottom scroll bar)

 resize [resize xy do-childs [trigger resize]] ;full resize + pass 
 the resize event thru all child gobs (for container)
]

James Marsden was also writing a GUI for R3

I need a review of specific source code, the concepts and prototype 
documents. This is to ensure that the prototype doesn't lack important 
features that I didn't think about, before the prototypes are integrated 
into the R3 GUI.

Im waiting for a more stable R3 before I continue GUI work.  Too 
busy at the moment to play with the host-kits.

R3 GUI now builds and runs with the new build system. Nice and clean. 
:-)

the built GUI is 193 kb and 53 kb shrinked.

Is there anything about this GUI that will make it standout from 
other languages's GUI's? or is this first version going to be standard 
stuff?

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

** GUI ERROR: Cannot parse the GUI dialect at: buttonn

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

download the files. first load r3-gui.r3, then run dialog.r3.

** GUI ERROR: Unknown parent style for: LAYOUT-USER

and for A105

>> do %r3-gui.r3
Script: "Untitled" Version: none Date: none
** Script error: expected command! not font

** Where: size-text font-char-size? make make-text-style parse fontize 
catch eit
her either applier do
** Near: size-text gob

http://rebol.hmkdesign.dk/files/r3/gui/validation-prototype.html

http://rebol.hmkdesign.dk/files/r3/gui/docs/validation-prototype.html

and now also:


http://rebol.hmkdesign.dk/files/r3/gui/docs/dialogs-prototype.html

You should use them for the R3 Gui.
Just my opinion

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


Some of the last glow stuff I did which is not hardcoded, but done 
using a real material system with calculated specular highlight.

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


It'll probably be closer to this. I find a good source of inspiration 
in this skin that can yield some interesting results.

http://rebol.hmkdesign.dk/files/r3/gui/123.png
http://rebol.hmkdesign.dk/files/r3/gui/124.png

Any questions? :-)

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


The vertical scroller looks like that, because it works nicely with 
the bottom right corner, but there are still issues to figure out.

Generally, always use this (please download as it's on a low bandwidth 
connection):

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

For validation, a proposal was written:


http://rebol.hmkdesign.dk/files/r3/gui/docs/validation-proposal.html

This has been translated into a prototype:

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


and then a set of notes on how the prototype works has been written:


http://rebol.hmkdesign.dk/files/r3/gui/docs/validation-prototype.html

but the role of reactors is still not clearly defined to me
 - you have Carl on your GUI world, no - so just ask him :-)

Now we need to get R3-GUI to work again with the new hostkit. Will 
be finished this week.

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

Materials system is back in (just a quick test)

the next GUI release will require A105. is it generally available?

new build released at http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3


This one contains material system and some bug fixes. Requires A105.

Are these docs still valid? http://www.rebol.com/r3/docs/gui/guide.html

The GUI is highly non-functional, we imo need to wait few more releases 
...

In clean R3 A105 session, I do following to get following image:

do %r3-gui.r3
view [field] ; resize needed to see anything ...

result:
http://www.xidys.com/pekr/rebol/a105-field-strange-chars.jpg

Any idea?

ok, whatever the box model means in new gui :-)

I simply tried to go via http://www.rebol.com/r3/docs/gui/guide.html
, and to test those examples ...

I guess I'll add the issues above to CureCode - not sure that anyone 
will look at GUI issues though since it's known to be in flux - and 
Henrik's probably already modified the source enough that this couldn't 
be replicated

i see that some people recommend that your GUi should run in a separate 
thread from the rest of your application so that while's it's busy 
doing things, the GUI still remains responsive.  How can we apply 
that to R3?

Does r3-gui.r3 run on core a107?

I'm getting an error.

>> do %r3-gui.r3
Script: "Untitled" Version: none Date: none
** access error: cannot open: %shape.r reason: none

Just wanted to show what the GUI looks like without the box model:

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

And with the box model (panel skin was reset by this action):

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

The skin work is minimal, as there is only enough done to work the 
material system into the GUI.

(do you really think I would release a GUI that looks like that?)

shadwolf - dunno if Robert proceeded, but someone sent him a contact 
to some cool guy doing some GUI designs. We will see, if anything 
will happen in that area. Robert? :-)

pekr, yes exactly. the box model was turned off when the GUI was 
moved to the host kit. now it's turned back on.

auto-resizing is good ... if it works as expected of course. I liked 
Carl's model - not the model, but that it did what I mostly expected 
it to do (by examples posted). So far R3 GUI does not work for me 
yet (button sticking itself to bottom left corner for e.g.), but 
it is most probably very preliminary to do any judgements right now 
...

see when i look at those last posts here that reflect exactly why 
i don't want to use R3 GUI for the moment most of things are not 
done or disactivated ... What is made this week can be undo the next 
week... that's in too much work in progress stage...

shadwolf, the GUI is released as is, so the community can help find 
bugs.

Maxim good idea to take as entry point for rendering display with 
other graphical libraries area the  Gob/IMAGE even if it's some what 
extrem at least using that kind of binding you can keep using natural 
R3 GUI  and even use draw over the rendering. I'm surprise Carl doesn't 
see the point ...