World: r3wp

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.

Please download both files for local use, thanks.

hello, first thanks for sharing your work. but r3.exe need r3lib.dll. 
where i can find it ?

oh, sorry, one sec.

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

thank you very much

not working :-( ............customized 404 error page

ok working now ;-)

ok, there is a bug (surprise), that I've been able to trigger once 
by accident. I've not been able to do it more than once, but we need 
a way to reproduce it.

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.

Can you resize programmatically, to do it in discrete steps in an 
attempt to find the combination of values that trigger it?

I haven't tried it, and I'm not sure it's a specific size that does 
it, but more a series of events. The testing system is not yet in 
place to do it this way.

thank you henrik for your sharing . i will test it

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.

Shadwolf: "too easy you pillage us the free workers then you claim 
money I don't want to play that way :)" - I wish I could (as I cannot, 
sigh) make you pay for the new code you get for free asking for the 
amount corresponding to the "word of mouth effort" you done in this 
chat

In my opinion, you not only aren't a "free worker", but, actually, 
you are very costly in taking time and effort to deny the nonsense 
you are spreading here

Any news in R3GUI area?

Henrik - to your above code example - what I don't like is, why the 
resize system dictates me, how to shring the window. When I want 
to maximize a window, it should not do so only in horizontal axis, 
but also in vertical one. That's just my opinion, but I would find 
it more predictable.

And I can still observe the same behaviour, when I maximize the window 
of "view [title "test"  button "ok" do [print "ok"]]" - the button 
keeps attached to left bottom corner - why? :-)

Pekr, I'm not sure this is supposed to be standard behavior. As I 
mentioned earlier, I think it's set too aggressively.

To your above example - I am not able to reproduce the behaviour 
you observed ...

Pekr, that would be because the title scales vertically, while the 
button doesn't.

Nothing specially new, right now I'm bugfixing some styles.

I'm working on the build system right now.

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 :-)

the build system will allow that, but the question is if the source 
will be published like that. I hope it will, but I would not rule 
out that many styles will depend on eachother in the future.

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

I would regard such design being - fundamental. I like that RebGUI 
because of that - one widget, one file, easy as that. There is too 
much fuss about inheritance, having some base, upon which other styles 
are based - that is an utopia, and I don't know, while we still keep 
to that. That does not save any signicant memory, and I doubt that 
by changing one parameter to some base style, you want to have all 
childs influenced. That is nice example of inheritance, but completly 
misses practical usability imo :-)

But - I think that we can't change it in recent stage of development, 
so just regards it being my typical rant :-)

It's not utopia, it saves you from writing the same code over and 
over again.

yes, but there is no clear boundary for the style - it is "scattered 
around" ....

same code = pre-rebol ??

Pekr, actually not. On a style level, the style itself is contained 
within one file. It's been like that since Carl's first prototype 
and it stays that way, but a table may contain a variety of different 
styles, such as fields for editable input, but you really don't want 
field to be in the same source file as for table.

so some styles will have dependencies

OK, so it is source-code organisation vs the functionality. That 
is acceptable to me. So simply put - while you might copy table-widget 
around, it might not work, if dependable upon other styles (table 
is compound of multiple styles), which you don't copy/include too 
....

Yes, styles have dependencies. For example TOGGLE is based on BUTTON.

yes, but working a failsafe mechanism into table that makes it slightly 
less functional if a field is not there... I'm not sure that's a 
good idea. It's better to dictate dependencies and follow them. What 
if you decide to derive table? You might get different R3 GUIs that 
work differently. It's now starting to make me think that it's a 
bad idea to allow removal of certain styles. :-)

what about having another field in the style, called 'depends-upon: 
[other styles here] .... then, upon such flags, you might be able 
to kind of automate it ...

look, that's not something absolutly needed, but would be nice, if 
R3 becomes popular, and we have hundreds of styles around to choose 
from :-))

don't prematurely optimize

what sort of completion are we at now ?  10, 50, 70, 90 % ?

Pekr, no absolutely not. That is too error prone.

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

completion: don't know about any particular percentage.

file storage: right now yes, but later it probably will be integrated.

does the latest r3gui work in the released hostkit, or only with 
the version you gave us saturday?

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.

I don't care if it 30MB in size.   I could help you with the debugging, 
but right now its very tedious to do.

I'm preparing a different build script, so it will appear uncompressed. 
Should be up within a day or so.