World: r3wp

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 
...

pekr, thin buttons:

1. the grouping of buttons specify 3 columns

2. the width of the checkboxes is the minimum as shown. I'm not sure 
why that's set so high. if it were smaller, the window would automatically 
also be narrower.

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.

I think that widgets should keep some metrics/aspect ratio (hmm, 
on the other side, I can imagine square button, e.g. when you are 
simulating some industry panel design, but that could be solved by 
separate style)

shadwolf - just be fair to guys .... when they don't release stuff, 
we complain, when they release some preliminary stuff, we complain 
too :-)

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 ...

Pekr no i never coplained cause i didn't got some half made work 
in progress to test ... I just complain to get the direction to know 
what would be the futur and to know the agenda ... that's all !!! 
 I don't caore of host kit i don't care of the widgets anyway if 
it doesn't fit my taste I'm grown anough  to do my own widgets anytime 
like i did with R2 /VID

see on this you don't have to convince me ...

bu this time i won't share them :)

too easy you pillage us the free workers then you claim money I don't 
want to play that way :)

are you saying you are doing some R3 widgets? Cool then. Show us 
at least screenshots :-)

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