r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 GUI]

Ladislav
19-Jan-2011
[5360]
(since I was unable to reproduce the problem, I bet it is exactly 
because I never ran the LOAD-GUI twice)
Robert
19-Jan-2011
[5361]
Works. Differently from handling but works.
Pekr
19-Jan-2011
[5362]
It works. But it was not enough to just change the view-show.r3 code, 
and call it after do %r3-gui.r3, as the initial redirection will 
remain. A bit tricky, as there is no script to build new r3-gui.r3 
from sources, and sources are collapsed, but I managed it to change 
:-)
Ladislav
19-Jan-2011
[5363x2]
well, the next update will cure this issue for everyone, this was 
just for checking
thanks
Pekr
19-Jan-2011
[5365]
Is it possible some styles are not adapted well to resizing? When 
I removed 'when style, the space at the top of the panel is not there 
anymore. Then I removed clicker too, upon your suggestion. But - 
when I lower the size of the window, the display is still corrupted 
...
Ladislav
19-Jan-2011
[5366x2]
Sure
(meant for the "not adapted")
Pekr
19-Jan-2011
[5368x2]
Aha ... and is there any list of "should work well" styles?
Resizing problem reduced down to button plus text: http://xidys.com/pekr/rebol/messy-resizing2.jpg
Ladislav
19-Jan-2011
[5370]
thanks
Pekr
19-Jan-2011
[5371]
To get that, you need to try xy times. Most of the time I am holding 
down the bottom-right corner, moving randomly the mouse (I remember 
REBOL in the past did not receive updated info about about size, 
unless mouse button is released), and it accidentally can end like 
that. Dunno if any such info is helpfull ...
Maxim
19-Jan-2011
[5372x2]
I really would like it if Carl could fix the event port so that it 
lets all resize events go to the even handlers.


right now, the graphics code has access to it, (because you can see 
the AGG gobs refresh when the window resizing) but the REBOL event 
handlers receive only the last resize event.  which means we cannot 
resize the view while its being dragged.
by resize the view, I mean refresh the layout iteslf.
Pekr
19-Jan-2011
[5374x2]
I really would like it if Carl could fix the event port so that it 
lets all resize events go to the even handlers.
 - that is long time problem, even for R2?
I am for the fix, as it really looks ugly as it is ....
Maxim
19-Jan-2011
[5376x2]
yep.  but in R3, I can actually see that the window resize events 
are being triggered while we drag the window size.. but for some 
reason they are not being pushed to the handler.
in R2 its pretty weird.   the event handler *accumulates* all resize 
events and then when you release the resize bar... it sends all of 
them to the handler in one stream.... just totally not at the right 
time  ;-)
Pekr
19-Jan-2011
[5378]
but for some reason they are not being pushed to the handler.

 - is that the mezzanine level, or low level? If the fix is easy, 
 I am all for it. I just think that it might not be the priority. 
 The question is, if the resizing is not confused by receiving wrong 
 info, when holding the mouse button down, resizing here and there, 
 and then releasing it :-)
Maxim
19-Jan-2011
[5379]
afaik, its within the port mechanism, when events are created, for 
some reason, the resize events don't end up at the port handler.


I remember trying to fix this in the host-kit and didn't find the 
solution.  I tried a few things but nothing worked... so I moved 
on but that's like 3 months ago already so the details are fuzzy 
in my mind.
Ladislav
20-Jan-2011
[5380]
Pekr, if you want to make e.g. a HPANEL with a given content, you 
can use the MAKE-FACE function anyway:

child: make-face 'hpanel [break-after: 1 content: [button "OK"]]
view child
Pekr
20-Jan-2011
[5381x2]
thanks ....
are there any accessor functions, how to easily list face, pane, 
style etc. structure? I mean without references? I would like to 
see (e.g. in docs, or by query) the ability to list face, gob, style 
structure ...
Ladislav
20-Jan-2011
[5383]
Pekr, regarding your

lay: [

		when [load] do [print "Load trigger!"]
		clicker
		button "Do" alert "Button pressed!"

  button "Big Quit Button" maroon options [max-size: 2000x50] quit
		bar
		text "Toggle button..."
		t1: toggle "Toggle" of 'tog
		button "Set False" set 't1 false
		button "Set True"  set 't1 true
		toggle "Mirror" attach 't1
		toggle "Mutex" of 'tog
		bar
		text "Radios and check boxes"
		radio "Set above toggle on"  set 't1 true
		radio "Set above toggle off" set 't1 false
		bar
		check "Checkbox attached to above toggle" attach 't1


]

child: make-face 'vpanel []
set-panel-content child lay
view child


example - it is incorrect, since you try to give VIEW a HPANEL instead 
of a WINDOW, I suppose, that it was just a test, how it would look?
Pekr
20-Jan-2011
[5384]
Yes, it was a test, to isolate the example form layout from the demo 
....
Cyphre
20-Jan-2011
[5385]
Pekr, since you are passing the FACE object as argument to VIEW, 
currently, it jsust shows what you pass.
Pekr
20-Jan-2011
[5386]
I thought that gob, panel, are directly "viewable"
Cyphre
20-Jan-2011
[5387]
So in your case the example should look like:

lay: [
	backdrop [
		<your layout here>
	]
]
okno: make-face 'window reduce/no-set [content: lay]
view okno
Pekr
20-Jan-2011
[5388]
what is 'window type? I remember from the past, that it was stated, 
that just "view lay" simply adds lay into the panel, which is just 
- implicit?
Cyphre
20-Jan-2011
[5389]
Every face is 'directly' viewable but it won't resize always correctly 
unless you don't comply to the resizing rules
Pekr
20-Jan-2011
[5390]
It just should be - easy ... or the directly viewable face is - useless 
...
Cyphre
20-Jan-2011
[5391]
In the current VIEW code the FACE arg case is simple low-level stuff. 
But we could use th AS-IS refinement for this current behaviour. 
If you don't specify /AS-IS then the passed FACE will be wrapped 
into the appropriate window sturcture as it is in the VIEW block! 
case.
Pekr
20-Jan-2011
[5392]
Is 'window type just a panel? Or special window gob?
Cyphre
20-Jan-2011
[5393]
If WINDOW would be just a panel there won't be need for that WINDOW 
style no? :) Anyway, the WINDOW is the base style which controls 
all the content.
The structure looks like:
WINDOW [	; this is the main container GOB
	BACKDROP [ ;renders solid background under the content
		<your layout>
	]
]
Pekr
20-Jan-2011
[5394]
and if I don't specify backdrop? Aha, so window is not just anonymous 
parameter to make-face, but a regular style?
Ladislav
20-Jan-2011
[5395]
yes, window is a style
Pekr
20-Jan-2011
[5396]
btw - I don't like the name make-face, to make a window, which is 
a special style. We have:

make-panel
make-face
make-style


in the above case, window, is a widget for me. I really don't know, 
if we have terminology OK here. I simply don't regard instantiated 
style, being a face? Or is it aligned correctly?
Ladislav
20-Jan-2011
[5397x2]
We have: make-panel

 - wrong, you do not have any make-panel, I thought you read that 
 above
You do have just MAKE-FACE, which makes a face for you, as specified
Pekr
20-Jan-2011
[5399]
yes, but I still don't understand it. My latest understanding is, 
that this function is going to be overhauled? Or - should I forget 
it exists, regard it being an internal function?
Ladislav
20-Jan-2011
[5400]
Forget to use it at all
Pekr
20-Jan-2011
[5401]
ok, so what paramters make-face uses as first argument? Can I use 
any style name? E.g. make-face 'button?
Ladislav
20-Jan-2011
[5402x2]
You need to specify the style of the face you need to create
Of course, only existing styles (styles you, or someone else defined) 
can be used
Pekr
20-Jan-2011
[5404]
So basically I can create instance of any style? If so, then heck, 
it is more flexible than I thought :-)
Ladislav
20-Jan-2011
[5405]
Yes, it is
Pekr
20-Jan-2011
[5406]
I initially thought only 'hpanel, 'vpanel is possible, and that it 
is only for panel :-) Well, now I am cool with make-face :-)
Ladislav
20-Jan-2011
[5407]
I simply don't regard instantiated style, being a face?

 - why not, if we "borrow" the class-based OOP terminology, then styles 
 may be considered analogies of classes, and faces may be considered 
 analogies of instances (objects) of their styles
Pekr
20-Jan-2011
[5408]
Why following works:

child: make-face 'window reduce/no-set [content: lay]

while following does not?

child: make-face 'window compose/deep [content: [(lay)]]
Ladislav
20-Jan-2011
[5409]
Here, the latter works as well