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

World: r3wp

[!REBOL3 GUI]

Pekr
16-Jun-2010
[1606]
Well, that might be psychological, but I always hated to work with 
"border" in R2. You have to count it into metrics ..... but maybe 
your model is different, than having border area ... but I can understand, 
that having shadow/glow to UI elements could be troublesome othewise 
...
Rebolek
16-Jun-2010
[1607]
the box model Cyphre is working on is unlike R2View, it's more similar 
to CSS.
Pekr
16-Jun-2010
[1608x2]
why slow? I don't know. What's the bitmap mask anyway? Some low level 
C function? I thought that putting one transparent gob upon the drawed 
gob could be faster, as event engine simply flows event to particular 
gobs .... (but it would probably cost a memory, because you would 
need two gobs for one style)
re "Box model" ... good to know ...
Rebolek
16-Jun-2010
[1610]
You render all visible faces to a bitmap. Each face has different 
color. The you just read mouse coordinates and do a PICK on the bitmap. 
That way you know exactly where the event should end. That's the 
bitmap mask.
Henrik
16-Jun-2010
[1611]
a bitmap mask has the advantage that we can define any shape, even 
counting in anti-aliasing for clickable area.
Pekr
16-Jun-2010
[1612x4]
Thanks for explanation, Bolek, looks easy :-) The only thing I can't 
techically imagine is "you render" .... is it special added operation, 
or you just use already-somewhere-in-memory-rendered area?
hmm, those are low level changes, so Cyphre is doing it his own code 
branch, or does he have code synced with Carl?
sorry for so many questions ... I am just interested :-) I hope more 
guys gets interested too, and even join the testing phase and style 
creation process :-)
btw - what is the situation/plan with fonts? Initial (recent) VID3 
(View) font rendering was not sometimes too pleasant. Was it due 
to not so precise font metrics 'tex-size calculations, or was it 
due to not being able to use more advanced (licensed/patented) techniques? 
Is there any way of how to resolve this issue?
Rebolek
16-Jun-2010
[1616]
render - well, there are different ways to do it, you must ask Cyphre 
how exactly he's going to it.
Henrik
16-Jun-2010
[1617]
Pekr, there are still options in the font rendering engine not exposed 
in DRAW. we need the host kit for that.
Robert
16-Jun-2010
[1618]
What is most important is, that we haven't hit a showstopper yet. 
Even with the current release we can move along. It might not be 
perfect in all aspects but good enough and comparted to R2 base not 
worse. That's enough to do it and get some apps done with R3.
Cyphre
16-Jun-2010
[1619]
Pekr, re font rendering improvements....have a look at this famous 
article: http://antigrain.com/research/font_rasterization/index.html#FONT_RASTERIZATION

Mcseem describes possible way we could try in R3 version but it would 
need some more expereiments.
Maxim
16-Jun-2010
[1620x2]
that's a very nice summary of various font issues.
(regardless of AGG)
Pekr
22-Jun-2010
[1622x2]
Henrik - any new screenshots to R3 GUI in the pipeline? :-)
Also - with the change to the "box model" and introduction of "material" 
system, will it be any easier to adapt the overall GUI look?
Henrik
22-Jun-2010
[1624x3]
Not yet. Carl has entered the resizing discussion and there is not 
yet an outcome.
Materials system is being reviewed by Bolek. May need some changes.
Resize system has been worked intensely on by Ladislav and Cyphre 
for the past few days.
Pekr
22-Jun-2010
[1627x2]
hmm, it seems like Carl is finally cooperating even in the GUI area? 
:-) So, is he liking new RebGUI like resizing model, or not? :-) 
I remember even some discussions in the past, and Carl had his own 
opinion on that. I hope that max-size need is eliminated ... or still 
it is not? :-)
From my perpsective it is easy - we need resizing system, which just 
works. With RebGUI, I still had some issues even with simple GUIs 
....
Henrik
22-Jun-2010
[1629]
I've not read the discussion yet.
Pekr
22-Jun-2010
[1630]
I expect your world being private one right? No web-public output 
at least, so that we can at least passively read some discussions, 
and kind of "influence" it from here? :-)
Henrik
22-Jun-2010
[1631]
yes, it's private
Oldes
22-Jun-2010
[1632x3]
I consider bitmap mask as the  way how to detect click in non rectangular 
areas. It's probably how Flash does it as well. You cannot use alfa 
channel because in many cases you need transparent buttons.
The missing word in my sentence above is "best" - but how I think 
about it, the alpha channel could be used as well if there was some 
flag which would inform the engine, that it should not render the 
gob, but still use it to receive events.
Using the alpha channel with the visibility flag would save some 
memory in many cases.
Maxim
22-Jun-2010
[1635]
using alpha would limit you to only 255 controls.
ChristianE
22-Jun-2010
[1636]
Bitmask or alpha channal would only be used where non-rectangluar 
areas need to be clickable, so that, Maxim, means they are handled 
on a per GOB or per-Style base, giving 255 controls per GOB or Style, 
not in total, at least that's my understanding.
Maxim
22-Jun-2010
[1637]
ah ok, that makes sense, but then you are limited in that each gob 
has to fit within a rectangular area, and do 2 checks.  first on 
the area then on the mask.
ChristianE
22-Jun-2010
[1638]
Yes, point taken, but I don't expect those double check to be a big 
performance burden. First, it's still fast, and second, it probably 
is reserved for special needs only. Not every button with e.g. rounded 
borders needs to be detectable on a per pixel basis, often a rectangular 
region would suffix in most cases, I guess.
Maxim
22-Jun-2010
[1639]
No it won`t be a performance problem for sure.
Ladislav
22-Jun-2010
[1640]
resizing: no, Carl does not like RebGUI resizing model, nor some 
look-alikes. Neither do I. That is why Cyphre and I had to try two 
distinct prototypes not being fully content with any of them (the 
second one being able to deliver some nice pictures already). Tomorrow, 
it is time to try yet another resizing model, this time adhering 
to Carl's original idea more, than his own implementation, so the 
system is going to be quite advanced (it took a lot of time to fine-tune 
some algorithm details, we almost gave up).
Gregg
24-Jun-2010
[1641]
Wow, if you and Cyphre almost gave up...
Graham
24-Jun-2010
[1642]
Will there be a way to swap languages in the GUI?
Henrik
24-Jun-2010
[1643]
if you can reference strings from outside the GUI, that shouldn't 
be a problem to do on your own. I don't find it generally to be a 
good idea to provide language support inside a GUI engine.
Robert
24-Jun-2010
[1644]
Gregg, solution was found and we should soon have a prototype.
NickA
24-Jun-2010
[1645]
@Gregg:  when I imagine Ladislav and Cyphre working like that on 
code, I picture a slow motion movie scene with epic music  thumping 
in the background, lots of dramatic cuts between close up face shots, 
etc...
Ladislav
24-Jun-2010
[1646]
Resizing prototype working well, both Cyphre and I like it.
NickA
24-Jun-2010
[1647]
... and the glorious slow motion victory scene with fists pumping 
in the air  :)
Ladislav
24-Jun-2010
[1648]
:-)
NickA
24-Jun-2010
[1649]
... and the crowd cheering :)
Rebolek
24-Jun-2010
[1650]
Yes, it's nice. I would print the demos in 1mx1m and present them 
in gallery. Piet Mondrian would be proud.
Robert
24-Jun-2010
[1651]
Works well and is pixel precise.
Henrik
24-Jun-2010
[1652]
screenshots coming soon
Pekr
24-Jun-2010
[1653]
Cool, because I did not like RebGUI resizing either, dunno why. Maybe 
because I was not getting what I exptected ...
Claude
24-Jun-2010
[1654]
again 2 weeks :-(
BrianH
24-Jun-2010
[1655]
Good, because I've been waiting for the R3 GUI resizing model to 
be finalized before I retrofit the R2 VID resizing patch with its 
algorithm.