AltME groups: search

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

The latest A107 with TO-IMAGE fix.

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


Newer version too. Sorry about the ballooning in size, but this is 
due to a change in the build system.

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

what I did was create a GUI similar to this one:

view [
	panel 1 [check]
	panel 1 [button button button]
]


When you resize this vertically by a few pixels, the bottom panel 
will resize incorrectly. That is known and will be fixed. What I 
managed to do, was to either move or resize the window in a way, 
that would cause resizing to get stuck in a loop (!), so it goes 
up and down in size by a few pixels vertically on its own, and the 
window just sits there shaking up and down in size. If possible, 
we would like some help with reproducing that.

It's gray because I tweak colors only when I have nothing better 
to do. Once the GUI functionality is finished, there will be some 
simple color/style designer written in R3GUI to make some decent 
look for it.

re build system - will we be able, in future, to bundle only styles 
being found in source-code, or selected ones? I can imagine having 
library of tens of widgets/styles, while my app might not require 
all of them? So far, R3-GUI is still small, so it does not matter, 
hence regard my question being just theoretical :-)

so taking apart the R3 GUI WRT styles may not work as well.

Are we going to be loading the gui from file storage?

is there a way we can get the r3-gui not compressed?  I'm getting 
strange handler errors which cause rebol to halt whever I try to 
open another window not from r3 gui.

cool


also, is there a way to link an arbitrary gob within the gui defintion?

seems using view/as-is when r3-gui is loaded prevents r3-gui from 
doing its stuff... it craps out with a handler-related error...

(this is on a window not using r3-gui, btw)

new build is up with uncompressed source:

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

cause right now, the gui looks totally dead a part for the fact that 
it resizes (though its late by one window resize event.)

does the material support some sort of accumulation?

a very loose example

I want gui in style dark
I want aluminium

the issue here being that dark is not a value but a process.

so you get dark aluminium ?

yeah I did briefly.. but there is a lot of code to sift through... 
it is 216 kb after all  (which is pretty lean for a GUI complete 
engine ;-)

Henrik, why not just put the gui on devbase ?

ah think I found the handler problem.


view's awake function now calls the do-event (it used to be handler).


so its just an adjustment to any code running after it loaded r3-gui.

Pekr:  I had a contact who worked for Adobe and was a gui designer 
on many of their applications.  He is now an indepent contractor, 
but now that he's contracting he's enjoying his time to be with his 
family.  Adobe worked him hard for many years.  So, unfortunately 
he is not available to help out.

http://rebol.hmkdesign.dk/files/r3/gui/r3.exe
http://rebol.hmkdesign.dk/files/r3/gui/r3lib.dll


Fixes clipping bug (disappearing faces) and garbage in text fields. 
Please download and test.

I tried to use area - that style is broken by some changes? In older 
version, gui crashed with something like no scroller attached message, 
now it crashes on divide by zero message :-) I expect area is not 
supposed to work yet?

Well, I expect it being something like that - you work in an area 
of GUI upon which style design/architecture is not dependant ... 
once other guys (as Bolek) move forward, it all plug-ins together 
...

http://www.xidys.com/pekr/rebol/r3-gui-field-text-alignment.jpg

Pekr, did you download the latest r3-gui.r3?

are we using the same binaries and gui source?

I downloaded R3.exe from henrik's site ... and the gui but he says 
it might be caching old versions

I agree with Graham - while I still am not properly used to Vista 
after 3 years of usage, XP is 2002 = 8 year old system - guys install 
Windows 7 and test there :-) Before GUI is finished, XP will be even 
more obsolete :-)

it's the script header for the gui

maybe it is some Aero thing, system GUI metrics, etc. ....?

I got the new exe and dll, the re-downlaoded r3-gui.r3, dialog and 
validation too, but get this error when clicking on a button in the 
dialog demo:

** Script error: path win-gob/text is not valid for none! type

** Where: any view either create-dialog request-user do switch applier 
apply if

foreach if do-face if actor all do-style if do-event do-event do-event 
either ap

plier wake-up loop applier wait do-events if view catch either either 
applier do


** Near: any [opts/title win-gob/text "REBOL: untitled"] ds: screen/s...

probably so, because I did not change executables, so it has to be 
part of r3-gui.r3 ....

this is not much needed feature, imo, but any fix is good :-) We're 
still waiting for R3 GUI to be at least on par with Carl's VID 3.4. 
What's needed in order to experiment with writing own styles?

Maxim, if you have some fixes for R3 GUI, please, share them with 
me.

New r3-gui.r3:

http://94.145.78.91/files/r3/gui/r3-gui.r3

My domain seems to be gone. Will have to fix that later...

http://94.145.78.91/files/r3/gui/db-reactors.r3

This shows a simpe skeleton of what it's made of.

The thing is, that for multimedia, kiosk, tablet, multitouch etc. 
UIs, all that stuff is useless, and that is my point all the time 
:-) Henrik - one question - aren't you afraid, that all the stuff 
you work on, might be dismissed by possible change in architecture, 
when some other subsystems are going to be added? And also - how 
all this stuff is going to be optional? Look - even low-level R3 
now has various boot options, so e.g. someone can write and replace 
even module system. Now how pluggable (functionality wise) is new 
GUI going to be?

What if I don't care for your validation, your DB reactors? What 
if I am used to work with form and db my own way? Will I get one 
bloated gui? Carl was very picky for each single function to add, 
and now we are adding whole layers upon the GUI, which is still far 
from being finished.

Pekr, db-reactors and validation are optional features. Reactors 
are made using the MAKE-FACE-ACTIONS function, which specifically 
is designed to add a new aspect to the GUI in a way that doesn't 
interfere with its original functionality. And while you don't care 
about it, we do, because we need specifically to builds apps that 
use them, and I've missed these things in VID since I first used 
it. There's also that little detail about shaving off months of development 
and testing of large apps. The "bloat" you talk about would be around 
5 kb of code for now.

Bloat of functionality: That's not the point of these frameworks. 
The point is to make certain rudimentary things quick and easy to 
set up for anyone trying to write a GUI. I'm pretty sure that once 
you've fixed the 657283th bug in a javascript/HTML webform, you will 
really wish this was already worked out for you.


If the frameworks don't work out for you, then they are poorly written.

Petr, being able to get a database / table design right from the 
GUI is IMO a very good approach :-).

Small status update:


Cyphre has completed first version with keywords for draw blocks. 
This means you can now use the vertices of the box model for coordinates, 
instead of tediously calculating them inside the draw block.

http://94.145.78.91/files/r3/gui/240.png

New R3 GUI uploaded here

http://94.145.78.91/files/r3/gui/r3-gui.r3

It should contain the feature.

http://94.145.78.91/files/r3/gui/resizing-new-9.r3

Contains example.

Go GUI-team go!

They seem to be the same size, but, just to be safe:

http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

New R3 GUI uploaded here

http://94.145.78.91/files/r3/gui/r3-gui.r3

Fixes slider crash. Is 21 kb bigger. For some reason. :-)

Got a pattern on the resize loop bug, but I guess it requires a very 
specific VM setup:

1. Start the R3 GUI and make a window. Maximize it.
2. Resize the VM desktop window

3. Hope that your resize action is slow enough to allow you to doubleclick 
the titlebar to de-maximize it.
4. Now it loops between maximized and normal size.

Perhaps there is some confusion about screen-face size changing.

Uploaded panel scoping prototype:

http://94.145.78.91/files/r3/gui/panel-scoping.r3

Test support file:

http://94.145.78.91/files/r3/gui/file.txt


It's an earlier prototype that eventually became db-reactors, but 
it shows much more of the panel scoping features and uses EMIT, OBTAIN, 
ACQUIRE and SUBMIT.

New R3 compile should fix a scroll-wheel issue:

http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

GUI Enviroment. I didn't like it at first too, but I get used to 
it. OTOH, you don't need to acces guie most of the time.

Since the GUI is not a module yet, I don't know whether the GUIE 
name stays.

btw - why field style metrics are so wrong? Sometimes I can see proportionally 
too big fields - e.g. Facebook main page. And new R3 GUI uses too 
thin field. Look at old R3 View demo, section 'Form, how nice it 
looks :-) I just hope it is just question of some tweaking :-)

Rebolek - those are details which could be corrected in 1 minute, 
and make the overall feel for the tester much better. The whole team 
is not even at the level of Carl's VID, not unless R3 GUI can do 
anything usefull. I don't care for look now, but correct system metrics, 
closer to typography rules, are always welcomed. The screen forms 
should look relaxed. E.g. I was lately suprised, that I tried some 
Air app, and it was unpleasant experience in that regard ...

Rebolek - I will be harsh, but others might feel, that what is waste 
of time is lack of communication and providing big picture. You accepted 
SCRUM methodology, but only for your team internal purposes. The 
rest of us knows nothing about what's happening at particular levels. 
If you stop informing ppl, then the only thing we would know about 
the GUI would be, that team of 4 ppl are working on it for 4-5 monts, 
with no visible result. Ppl are very eager to have GUI.

It took me 5 minutes, to find area style misconceptions/bugs. If 
you are not ready to accepts comments/critique (CC), then just don't 
release. But then don't wonder, if ppl will not accept the way GUI 
turned out, if you keep it private for 1 year ....

public repository is not likely to happen, as RM Asset keeps private 
sources in the same repository as the R3 GUI to accommodate private 
projects and build system, but I will continue to release the r3-gui.r3 
file until a better arrangement is made.

How want to work with the RMA team on the R3-GUI? By work I mean, 
really getting something done. Writing code, styles etc. not discussing 
generic, high-level architecture stuff and future things to do.

No, because this will than become a community project. I'm going 
to pay the RMA Team, which is than indirectly a sponsoring of the 
R3-GUI project for the community to keep the momentum.

(like I did with testing of the custom renderer in r3 gui)

Style browser as it looks right now:

http://94.145.78.91/files/r3/gui/241.png


Second validation prototype test window. The use of multiple draw 
blocks still doesn't work, so I'm resorting to funky yellow text 
fields to indicate validation state:

http://94.145.78.91/files/r3/gui/242.png

http://94.145.78.91/files/r3/gui/243.png- Shows proper indicators

http://94.145.78.91/files/r3/gui/244.png- Shows validation report

I will, but this will be saved for the end, when the GUI is stable. 
I don't want to discard anymore skin work.

New R3 GUI at:

http://94.145.78.91/files/r3/gui/r3-gui.r3

New validation prototype, which can run stand-alone, at:

http://94.145.78.91/files/r3/gui/validation.r3

I'm thinking there is a design issue with validation, particularly 
the initial state:


The latest version will show that the "Only Chars" field validates 
as OK, which is technically correct, but confusing, as absolutely 
nothing has been entered in the field.


The issue is that the VALIDATE-PANEL/INIT function will see the field 
prefilled with an empty value and this passes validation. All fields 
that show a black dot, actually fail validation and a black dot is 
shown as the initial state.


I understand what this means, but it may be confusing for someone 
who is using the validation system for the first time. The fix is 
simply to add the NOT-EMPTY validator to the field, for the field 
to fail validation initially.

Is this easy to understand?


I've studied the issue with setting an initial state for each field, 
but then there would be a problem with the validation system understanding 
prefilled values, and I would have to add functions to the validation 
system to mimick SET-PANEL that setup fields in a special way. I 
don't want to bloat the GUI like that. This method works fine, as 
long as you know what's going on.

Is validation a fundamental gui aspect that has to be dealt with 
now?

Graham - that is my ethernal question with the GUI project :-)

Of course I am tempted to see things we expect most - more complete 
styleset and at least basically usable gui, but I will test what 
comes-out, as I think talking about what will come next just makes 
guys nervous :-) Of course some basic time-frame  would be usefull 
...

new validation prototype at:

http://94.145.78.91/files/r3/gui/validation.r3

requires a new R3 GUI:

http://94.145.78.91/files/r3/gui/r3-gui.r3

It was decided a long time ago to do future projects in R3 as we 
felt that continuing to write testing tools, frameworks, etc. under 
R2 would give a big pile of work later, when converting that to R3.

Considering also that the result of that decision is that Carl is 
now in tight communication with RM Asset, I think it was a good decision, 
as we avoid the months of darkness without info. It gives RM Asset 
control in what direction to take the GUI and to work towards R3 
being a usable product as quickly as possible, when you have to answer 
to other companies and customers. SDK is also a requirement, that 
we hope can be pushed through as quickly as possible.

New R3 GUI with dynamic panel content functions:

http://94.145.78.91/files/r3/gui/r3-gui.r3

Style browser:

http://94.145.78.91/files/r3/gui/style-browser.r3

Of course, I expect "typical" - from top-left to right-bottom direction. 
Not sure, how gui would look like, if I would try to think about 
arabic support for e.g.

New R3 GUI which fixes a few styles, like text list, although text 
list will eventually be rewritten:

http://94.145.78.91/files/r3/gui/r3-gui.r3


Style browser now shows style options, alphabetic sorting of style 
names, face debug option (currently broken in the R3 GUI):

http://94.145.78.91/files/r3/gui/style-browser.r3

what about this kind of IDE looks like small talk but for rebol and 
Rebol/GUI having such a tools could be crazy look at this and try 
it 
illumination Software Creator 
http://radicalbreeze.com/

maybe in a different way / shape but since along ago i like the idea 
very smalltalk like to organize Applications like a UML model ... 
And i think rebol GUI could shape that and use that ...

sounds like i'm feuding ... lol well the idea is since GUI is planned 
to evolve then maybe we can start thinking toward that kind of extensiv 
graphical use to see how this can be meaningfull with rebol context 
of writing applications...

i like the ideal of rebol being able to gui draw iit's own gui ... 
in my opinion most of the interest using rebol hides there ...

now discussing undo/redo management. There is a small spec available 
here:

http://rebol.net/wiki/R3_GUI_Specs#Undo.2FRedo_Management

any input is welcome.

best is to have a simple block with named threads... and you force 
people to supply the thread name when using any of the undo/redo 
functionality.


also, undo/redo is best done when its not directly part of the gui. 
  


though its nice when the undo engine is able to speak to the gui 
directly.  the gui must not be the "brain" of the undo..

having written  a few, I recommend making it an external api which 
is fully "gui enabled"   this way, undo events can automatically 
call face accessors,  and you can put the undo stuff in the logic 
rather than the gui.   many times, the logic might generate a few 
undo, or none, based on things which the gui can't properly be aware.

yes, the idea is also that it can be entirely decoupled from the 
GUI, so if you don't want it or want to use a different way to undo, 
that should be possible. the task for undo as I see it is to read 
actions and allow playing them back by taking control of the GUI.

take the case of a system where the undo crosses the lifespan of 
a window (or a few) how do you undo that?  re-open a new window which 
isn't connected to anything?

it basically has to be built with undo actions at the center.


each action has to be able to handle any gui issues gracefully... 
the gui itself cannot manage that unless its an uber simple gui.

might even be that the gui which manages the effect cannot be re-opened... 
ex photoshop.


and yes the data has to be stored somehow... another thing the undo 
"actions" are able to manage better/

also most undo/redo tie-in commands with macros and/or actual gui 
buttons and menus... sort of like the internal API for the lower-level 
stuff.


each of these commands/actions puts itself on the undo stack  and 
usually has a counter command...  add-text/remove-text, edit-record/restore-record, 
etc.

New r3-gui.r3 available at:

http://94.145.78.91/files/r3/gui/r3-gui.r3

No changes to other components.

and changes to gui itself? at least in brief?

New r3-gui.r3 released at above location.


New feature: Now allows reactors to be run after a specific actor 
in the style. If your style runs ON-DRAG, a block of reactors after 
an ON-DRAG keyword will be run afterwards. This opens up a lot of 
new possibilities.

view [field on-drag [do [probe 'dragging]]]

This needs a lot of testing.

Unofficial A110 available:

http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

http://94.145.78.91/files/r3/gui/247.png


Tab boxes now support drag and drop. I'll provide a built version 
tomorrow as I found a build problem tonight, so you can try it out.

style design is not really commentable, since it will be replaced, 
when the GUI is stable and near complete.

seems there are some issues with LOAD and SAVE in A110, so no r3-gui 
build today.

I do not like multiline tabs either, and they violate some of the 
rules of good GUI design.


Sure Graham, good and bad design are matters of opinion; however, 
they are based on what "most users" can understand and efficiently 
operate.  If a GUI causes a user become "lost" or do the wrong thing, 
then it's not a good design.

There is now Carl's blog upon how to easily list styles in R2. I 
posted corresponding R3 code, although it might be preliminary:

foreach [name obj] guie/styles [print [name "-" obj/about]]

But - I would like the GUI team to think about following aspects:


Imo the guie/styles list is highly insufficient. Imagine you want 
to auto-inspect (load) list of styles into your GUI designer. What 
you get now is a flat list of styles, where apart from 'table, you 
have its sub-styles like 'table-cell, 'table-row, 'table-header, 
etc. I am not sure that in the case of an IDE, you want to see those 
styles listed. OTOH those are legitimate styles, from which you might 
want to derive something, or just being able to change their aspects. 


So, I propose to resolve this situation somehow. The implementation 
is up to gurus, just few wild ideas:


- use tagging - tag style as 'main/root/parent, whatever - but - 
that introduces another field to the styles? Maybe not, because I 
expect some tagging system being available anyway?


- create guie/widgets, e.g.: guie/widgets: [table [table-cell table-header 
table-row] - that way we will be able to list just/only widgets as 
table, not having the list poluted with widget internals


- the above aproach might not work well in the case, when you aproach 
styles more as a CSS, not as widgets. Because - even e.g. 'table-cell 
might be derived from a totally different style, e.g. a box, or field, 
so I have no idea of how to keep track of those dependencies, but 
this is the area I leave for gurus to think about. E.g. someone changes 
box style and your table is influenced and user might be confused, 
why it happened. But I expect style/parent or something like that 
being available?

Maybe we need two separate things - style grouping (use gui/widgets 
for that), and style hierarchy - tree or other map of styles, their 
inheritance and dependencies (maybe this is what Rebolek now referst 
to as an object browser?)

Tags can be used, they are implemented.But, IMO, if you need a list 
of styles for a GUI builder, you better make a list manually.

> Imo the guie/styles list is highly insufficient. Imagine you want 
to auto-inspect (load) list of styles into your GUI designer. What 
you get now is a flat list of styles, where apart from 'table, you 
have its sub-styles like 'table-cell, 'table-row, 'table-header, 
etc. I am not sure that in the case of an IDE, you want to see those 
styles listed.


We already have and use tagging. The styles you mention should be 
tagged INTERNAL, if they are not already, as they are part of compound 
styles. So it's up to an IDE to discern that properly 


It might be possible to make a helper function that filters in only 
end-user styles, but we'll see how important that becomes.

But it's important to note that all styles are equal citizens in 
the R3 GUI. Tags are used for conceptual separation.

OK, I've provided you with some idea, now it is your team's take 
to discuss. Maybe such proposal could go into the long R3 GUI doc, 
before dismissed right away :-)

Was just trying out the r3-gui.r3 script and found out the fonts 
are hard-coded for Windows. I changed them to some Amiga fonts and 
the hello world GUI popped up. We'll need to find some way of handling 
fonts on non-Windows platforms via freetype to keep that script generic...

What about finally releasint useable GUI with more than useable button 
style? :-)

I have a very basic question, that I have already asked to Carl : 
how to get a working gui.r version ? when doing load-gui, I get the 
following error message : ** Script error: size-text has no value. 
It seems to me that this point should be definitely fixed, as it 
prevents anybody to do view tests (for instance the ones given in 
the reference doc http://www.rebol.com/r3/docs/gui/guide.html) I 
think that this should be done quickly and independently of any improvement 
and evolution of the gui styles and functions.