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

World: r3wp

[!REBOL3 GUI]

Pekr
16-Dec-2010
[4599x2]
wow, a progress ... will read it shortly .... guys, I have one question, 
which will most probably get dismissed, but I'll at least try to 
ask:


- when prototyping stuff in console, and e.g. when your gui crashes 
from some reason, I am very used to just "unview". But - in R3 I 
have to do either "unview none" or "unview 'all" (not caring about 
the name of the window)


So my question is - couldn't the aproach be rethought, and old R2 
functionality brought back? Especially "unview 'all" in comparison 
to (imo) more rebolish R2 "unview/all" is non intuitive for me ...
my opinion is, that most of the time I just want to unview everything, 
and only from time to time I want to unview particular window
Cyphre
16-Dec-2010
[4601x2]
Jerry, shape dialect is fully supported. Also note you can use chinese 
glyphs as normal unicode chars in the richtext dialect so no need 
to render it custom way in R3. Also any feedback on the rendered 
unicode fonts usage would be useful as it was just tested in basic 
tests and not in any native language like chinese, japanese etc.
Pekr, yes I thought about the UNVIEW in simmilar way.
Anton
16-Dec-2010
[4603]
About showing faces: In R2 I found it quite annoying not to be able 
to create an image of a layout without viewing it on screen first.

If I did things like set the face size to 0x0 or move the faces outside 
the window bounds, clipping would introduce artefacts (black regions 
not supposed to be there) in the image created by TO-IMAGE.

So, in R3 at least, I'd like to be able to create an image of a panel 
layout in R3 without first viewing on screen.

I think I thought that an UPDATE FACE function, being similar to 
SHOW FACE, except without the final copy to the window buffer, might 
be what's needed.
Jerry
16-Dec-2010
[4604]
Cyphre, Thanks. I'd just tested it. Chinese characters can be rendered 
correctly and perfectly.
Maxim
16-Dec-2010
[4605]
Anton, as long as you have a face you can to-image it.  no need to 
show it first.  I've done this many times.  many your problem is 
related to a specific style like a iterated face.
Pekr
16-Dec-2010
[4606x2]
Late to the game, but


as for A) - don't we have already tags? It could all be in the tags 
block, not in the new field. And if tags block is just flat, and 
those for states could collide with another flag names, we could 
use nested blocks flags: [ show? [visible]]. I see no reason why 
to introduce new field, unless from the speed reasons

Generally I like B) more, but:


I definitely don't like being dependant upon the size of 0x0? That 
seems really strange to me. Visibility state in the gob-tree should 
be imo independent from the size? E.g. look at Cyphre's code example:

button 0x0 "test" options [resizes?: true]

Do you really want to see code like that in the VID level?
ah, should read the whole discussion first - already decided ...
Rebolek
16-Dec-2010
[4608]
I see no reason why to introduce new field, unless from the speed 
reasons

. Yes, it's faster and the code is also easier to handle for user.
already decided
 - really?
Pekr
16-Dec-2010
[4609x2]
Cyphre: "Brian, yes, what would you want to see on the screen if 
something has zero size?" - really, I am not sure I care about if 
something is theoretically visible in 0x0 size, because face itself 
will not have a meaning even with 1x1 size, but I think that visibility 
(event flow) should be separate. OTOH, I can't find any practical 
reason how it could be internally usefull to have some inner state 
as shown, while being at 0x0. I thought about some graph models, 
event flows via the face hierarchies, etc., but with 0x0 size, you 
can't receive events anyway (apart from timer events maybe)

Max - speak on :-)
Rebolek - by "decided" I meant Cyphre's message stating what they 
agreed upon with Ladislav, and Robert kind of seconded :-)
Rebolek
16-Dec-2010
[4611]
You can receive lot of events for 0x0 face even without timer, you'll 
be surprised.
Pekr
16-Dec-2010
[4612x2]
If so, you can't auto-hide the face by just setting its size to 0x0? 
That seems like an ugly hack to what could be implemented by 'hide 
function? Well, if we have 'show, why don't we have low level 'hide 
one?
Simply put - I am for separating hiding faces from resizing the faces/gobs. 
But I will let it to the clever ones :-)
Rebolek
16-Dec-2010
[4614x2]
There was HIDE-FACE that is removed with this implementation, you'll 
just use SHOW-FACE face 'hidden
SHOW-FACE and HIDE-FACE allowed only two states, this method allows 
more states.
Pekr
16-Dec-2010
[4616x3]
compare the code:

show-face face 'hidden
hide face


which looks more readable to you? ;-)  Why to overload show? We have 
'View, and 'unview. And with two separate functions serving its purpose 
you can implement more functionality for each of them imo ... I must 
be missing something :-)
you can use refinement. I can see, that with R3, we departed from 
refinements ... why? Look at 'unview ... unview none, unview 'all 
.... why not just uview, and unview/only, as with R2?
ok, I said enough for others to get my message, it is just my opinion, 
after all :-)
Rebolek
16-Dec-2010
[4619]
it's not just show/hide face anymore. SHOW-FACE sets face's visibility 
and usability mode. Maybe you can come up with better name, this 
one is left from previous implementation even if does currently something 
different.
Pekr
16-Dec-2010
[4620]
Pity following feature was removed - we could have used bitsets - 
that would allow even for more combinations - http://www.rebol.net/r3blogs/0077.html
Rebolek
16-Dec-2010
[4621]
more combinations?
Pekr
17-Dec-2010
[4622]
Yes, generally all possible states - visible ignored fixed hidden 
no-resize etc. could be part of a bitmask, and IIRC that is the aproach 
win32 is taking. I thought that named bitmasks are implemented, but 
they were removed.
Rebolek
17-Dec-2010
[4623]
But some states are mutualy exclusive, so this is not such a good 
idea. You can also achieve the same with block!
Pekr
17-Dec-2010
[4624]
Yes, not a big deal for me ... except the idea of using size 0x0 
to express the hidden state :-)
Rebolek
17-Dec-2010
[4625]
Image the UI animated. You have button with size 100x20 that gets 
smaller until it reaches 0x0 which effectively means it gets hidden.
Henrik
17-Dec-2010
[4626x2]
I don't agree with having 0x0 as hidden. It is an implied state, 
that would occur any time the X or Y size becomes zero. There are 
behavioral issues to consider, such as, whether you want to obtain 
data from the face, using GET-PANEL, or how tabbing and disabling 
behaves with a zero sized face. If the layout is dynamically created, 
so that a face is inadvertently presented as zero-sized, you will 
get topological side-effects.


For animation, you would have a start and end position. Animations 
should not express anything about face states. Only dimensions, offsets, 
transparency, colors, easing are relevant with animations.
For that matter, a face can also be considered hidden, when its parent 
is 0x0, or if the face is located outside the viewport of the parent 
face.
Oldes
17-Dec-2010
[4628]
if "SHOW-FACE sets face's visibility".. than it should have name 
SET-FACE... btw... I'm with Pekr that  "HIDE face" is nicer than 
"SHOW-FACE face 'hidden"... I don't expect to use word SHOW when 
I want to HIDE something.
Rebolek
17-Dec-2010
[4629]
SET-FACE is already reserved. Adding HIDE as a shorcut is of course 
possible.
Henrik
17-Dec-2010
[4630]
that a face is inadvertently presented as zero-sized

 - this may occur, should a style implement its own layout engine, 
 which is possible to do.
Ladislav
17-Dec-2010
[4631]
Re the 0x0 issue: I am sure, that the solution used will satisfy 
you.
Pekr
17-Dec-2010
[4632]
hmm, I lack imagination for all possible usage cases. But we should 
have in mind the most complex scenarios, which might be some animations 
along with timers, simply a graph structure.
Ladislav
17-Dec-2010
[4633]
Re the HIDE face: the problem is, what the function should do? (which 
of the four variants it is you want?)
Pekr
17-Dec-2010
[4634]
Ladislav - is the solution part of posted r3-gui version from yesterday? 
Or just something which will arrive shortly?
Ladislav
17-Dec-2010
[4635]
A new one, not posted yet
Henrik
17-Dec-2010
[4636]
Animation should be an entirely separate part, to make it easier 
to discuss, design and change when the time comes, possibly an extension 
of SHOW-FACE.
Rebolek
17-Dec-2010
[4637]
Without timers we can only dream of animation right now.
Anton
17-Dec-2010
[4638]
I agree with Henrik, and I reiterate my uneasiness with face size 
0x0 == hidden. Conflating the two concepts creates the problem of 
how to separate them, which may be difficult, or impossible.

I would not like that in order to hide a face, I would have to set 
its size to 0x0. That means that in order to restore the visibility, 
I must store its previous size somewhere else. So squashing two concepts 
into one value means one or both of them just pops out somewhere 
else, confused, or some state information is lost.
Ladislav
17-Dec-2010
[4639]
Yes, that is why the two *will* be separated
Pekr
17-Dec-2010
[4640]
Cool, my worries dismissed then, as I agree with Anton too ...
Anton
17-Dec-2010
[4641]
Oh, I'm sorry, I probably should have re-read the discussion since 
last night.
Cyphre
17-Dec-2010
[4642]
re Animation: Recently I talked with Carl about it briefly. He plans 
to add timer port device + mezzanine support functions for that purposes. 
No EST has been said though.
Maxim
17-Dec-2010
[4643]
Carl should just make the device extension API .  then these concerns 
can solve themselves on the Open Source side of things.
Cyphre
17-Dec-2010
[4644x2]
From what I know the 'custom devices' will be available in hostkit 
after 3.0.0 release.
Of course it is possible to implement timers as embedded extension 
if someone can't wait for this feature.
Pekr
17-Dec-2010
[4646x3]
will that timer device have any influence on the task design? Well, 
being it one way or other - it is sadly another regression from R2. 
OTOH I think that most of R2 GUIS did not rely on timers, or am I 
wrong?
I prefer to have it designed properly, rather than to rush the implementation. 
And I agree with Max - there is imo long time plan to have extension 
API for devices ...
Cyphre - say hello to Carl :-)