AltME groups: search

you don't need another gob to define click-area. It will be probably 
done using a bitmap mask.

Pekr, after working with multiple GOBs for a single face, I think 
it's simply easier to just work with one GOB and a set of draw blocks 
on top of it. Otherwise you get many small parts.

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)

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.

a bitmap mask has the advantage that we can define any shape, even 
counting in anti-aliasing for clickable area.

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.

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.

that's a very nice summary of various font issues.

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.

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.

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.

No it won`t be a performance problem for sure.

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

Will there be a way to swap languages in the GUI?

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.

Gregg, solution was found and we should soon have a prototype.

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

carl say => With the above renewed effort on the GUI, the priority 
of moving the graphics library to the Host-Kit has jumped up a few 
notches. This is a non-trivial project; however, the next sprint 
is expected to arrive in two weeks

so it is a mixture of original Carl's VID model, plus some new alghoritms?

http://rebol.hmkdesign.dk/files/r3/gui/212.png- this is a layout 
using a PANEL style, elements are layed vertically, (in columns), 
center-aligned, having different (randomly adjusted) sizes

We're afraid because we've see some of these before, and they didn't 
turn out well. Specification dialects that don't require much specification 
and are easy to understand, make and maintain are preferred. If you 
were able to show us some layout dialect source with the resize specification 
markup, it would help a lot.

Davide, much harder actually, since I use virtual box on a mac. :-)

that is a principle, you can have layouts defined with the horizontal 
direction being the "major direction", or the vertical direction 
being the major direction, the former ones are groups, the latter 
ones are panels

216 is a more special layout in respect to resizing. It is defined 
so, that it can be resized only horizontally, and only the first 
and the last element are allowed to change their sizes when being 
resized. (that is something you cannot define in RebGUI as far as 
I know, neither it was possible in Carl's resizing algorithm, afaik)

Well whai I wanted was a non-awkward, minimal specification method, 
so a definite no to that. How's the dialect on yours?

The problem with Carl's original was that it was a good idea but 
it didn't work. That's fixed now.

But, are you saying, that you could get a picture like 216 being 
scaled so, that the two boxes in the middle do not change their sizes, 
while the first one and the last one do so, that the boxes remain 
next to each other all the time?

I don't like max-size, but the way it's done now, I think, that it 
can be omited from style-writing and R3/GUI can take care of it. 
But that's just a guess right now. There's now code to support my 
guess.

Rebolek, actually you are wrong, you cannot define layouts with elements 
having max-size/min-size without having a direct support for these 
features (maximally, you can get some "ugly approximations", but 
surely not the same behaviour)

The main problem with Carl's resize model was that it was difficult 
to specify proportional scaling independent of max-size. This made 
layouts fail on unexpectedly large screens, or made it necessary 
to put in a lot of very large numbers in max-size.

And, yes, that was a motivation for me to invent something more convenient

Hard to code, yes. Useless, no, not unless you're on a fixed-size 
screen.

Steeve, that would defeat the purpose of buying a large screen so 
you can see more stuff. Used a spreadsheet lately? Graham, that can 
change the whole layout. If it autoadjusts, cool, but you'd at least 
need different layouts for languages that go in different directions.

I also want a combination of proportional resizing for scale, and 
expanding sections for size. Fot instance, an iPhone 4 has a higher 
resolution screen than a Droid, but the Droid's screen may be larger. 
So I want to both scale to higher resolutions on platforms that support 
them, but make use of more physical space when available, as needed. 
I don't want my menu/ribbon to expand to fill more of the screen 
unless I am going to be further away from it.

ah sorry, Babylon is a transcription used in Cz

the invention of zero was a considerable breakthrough, taking into 
account, that even nowadays there are people hesitating to call zero 
"a number"

it's a bit, actually :-)

Just read a new Droid review - larger screen than a iPhone 4, less 
resolution. I'm starting to want a device-independent coordinate 
system :(

also now that Microsoft seem to be releasing a new mobile OS per 
week...

Anyone know if one can update the GUI from a network event?

I'd like to know, inter alia, if one can build a progress meter for 
downloads

As for resizing - how much I can influence the scaling aspects? I 
mean - e.g. I have simple reblet, a calculator. Now while it resizes 
buttons etc., what if I want it also to properly scale on large display? 
I mean - making the UI element just bigger, including borders, font 
metrics, etc.?

since it's a very basic function

as for why min-max size totally sucks. Who tries to predict, what 
is the correct max-size? I linked my notebook to my LCD TV, and instantly 
the gui looked totally wrong, as the resolution went up to 1920x1080 
(FullHD), but field was set to max 900. Carl told me, that fields 
should not be so long. But - I don't want to discuss it with the 
style author. In such a case, I had to adapt the style to "fix" the 
case ...

Cyphre, is the layout framework pluggable in any way? Could it be 
replaced with a different model? I'm just thinking how layouts are 
done in Java where there are quite a few different layout managers 
available and one size doesn't have to fit all. Here are some options:


http://leepoint.net/notes-java/GUI/layouts/90independent-managers.html

Does the declaration of REBOL GUI elements need to be so different 
from how other toolkits handle them? It just seems that needing to 
have only one way (one layout engine) of laying things out is a lot 
to ask of both the layout framework designers and the users of that 
layout engine.

It seems from reading:

http://www.rebol.com/r3/docs/gui/faces.html


that you might be able to define a new "layout" function implementing 
a different layout description dialect to achieve a new layout. Am 
I understanding it correctly? Is this layout description dialect 
specifically what the gang is working on?

Apart from the fact that I can't properly answer your question, my 
understanding is, that the team is working on all aspects of GUI, 
in following areas:


- low-level (in C) - new GUI is based mostly on AGG, some fixes and 
enhancements are going to be done. Carl, and Cyphre probably too, 
is also working on HostKit GUI isolation, so that the GUI can be 
fully open-sourced, becomes part of Host environment, and can be 
eventually replaced


- various GUI subsystems are being worked on - layout, resizing, 
keyboard navigation/tabbing/accelerator keys, skinning/themes/materials, 
GUI transition effects, etc.


- GUI styles - new VID is supposed to be released with some advanced 
styles, as e.g. tabs, grid, hopefully tree too, maybe a menu (dunno 
about that one) 


- some other things come to my mind - browser plugins, video codecs 
etc. - good times ahead once we are there, but first things first 
:-)

Sure, I was aware there are other things being worked on, but I was 
asking if the resizing functionality that was discussed earlier is 
specifically part of defining a "layout description dialect" (as 
mentioned in the docs), and, if this is so, do I understand correctly 
that if you want a new layout engine, than it is "just" this dialect 
that needs to be redifined.

'I was asking if the resizing functionality that was discussed earlier 
is specifically part of defining a "layout description dialect"' 
- actually not, the resizing functionality affects the functionality 
at a lower level, the "layout specification dialect" is a layer above 
that

Ok, but does this mean that a new "layout specification dialect" 
would not be able to redefine sizing? It seems that it should be 
able to do so as the sizing of GUI elements is intimately part of 
laying things out.

I would think that a GUI element's size is relative to the layout 
model defined by a particular layout implementation - that is, GUI 
elements that are being managed by a grid/table-like layout manager 
would resize differently than those being laid out by a layout implementation 
that "flows" it's managed elements or fixes their positions to absolute 
coordinates.

If you want to do it right, resizing is a fundamental concept. That's 
why we take care that early. It will be used by all styles. Hence 
if you want to replace it, you have to touch the code. The GOB objects 
might look differently, the dialect needs adjustments etc. So, a 
lot of ripple-effects.

IMO making resizing that abstract that you can swap it, doesn't make 
a lot of sense. If it works, I don't see any value in supporting 
several different resizing systems.

It's not the idea that resizing is separate from the layout implementation 
that I'm wondering about, it's that the layout implementation is 
swappable. My assertion earlier, that resizing is intimately tied 
to a particular layout implementation, still stands, though. Are 
you saying that you can vary the "layout specification dialect", 
but not have to have a resizing implementation that takes this changed 
layout engine into account?

Yes, the layout implementation is the code that is behind the function 
"layout" in a face, for example. See:

http://www.rebol.com/r3/docs/gui/faces.html


The dialect parsed by this code is specifically called "layout description 
dialect" in the docs. This is different, as I understand, than VID, 
is it not?

Within the VIEW part the resizing is a simple call:

The way I understand it, VID is a superset of the layout description 
dialect. So, to reiterate, if there is such a thing as a "layut description 
dialect" and there could be more than one defined, how come you are 
saying that resizing of GUI elements managed by any number of layout 
implementations is independent of these implementations when, as 
I tried to describe above, the resizing that you should get for a 
GUI element should take into account the "bounds" set by a particular 
layout implementation.

VID is a superset
 - VID is a layout description dialect, no superset

Hmm, well words in VID that declare the GUI elements, button, text, 
for example, are not layout specific. If I were to change the layout 
dialect, would these not stay the same? Doesn't this mean that the 
VID is a superset of any layout dialect in that it includes words 
for defining layout and words for declaring GUI elements?

My assertion earlier, that resizing is intimately tied to a particular 
layout implementation, still stands, though.

 - you can assert whatever you like, but it is beyond my understanding 
 why. Certainly, a layout dialect implementation may be "tied to" 
 a particular resizing method, since for different methods you may 
 need different data structures, so what? You can always use different 
 resizing, and if the respective layout dialect is not able to specify 
 all options the resizing algorithm offers (quite unlikely), you are 
 free to change the dialect.

Nevertheless, that does not mean, that if a different underlying 
data structure/interface is needed, you are not forced to modify 
the dialect implementation to be able to couple it with a different 
resizing algorithm, but, that is again a trivial information, that 
everybody understands/knows.

Hmm, well words in VID that declare the GUI elements, button, text, 
for example, are not layout specific. If I were to change the layout 
dialect, would these not stay the same? Doesn't this mean that the 
VID is a superset of any layout dialect in that it includes words 
for defining layout and words for declaring GUI elements?

 - no, this is REBOL, and you can define a totally different dialect 
 than VID, and such a dialect surely does not have to be a subset 
 of VID in any sense of the word

As I see it, your goal is actually different: you would like to have 
a VID-replacement dialect compatible with VID in properties you call 
"non layout specific". Yes, that is possible too, of course.

'Are you saying that you can vary the "layout specification dialect", 
but not have to have a resizing implementation that takes this changed 
layout engine into account?' - certainly, we can do whatever we like, 
especially create two different layout dialects using the same resizing 
implementation, if that is what we wish

yes, this is what I'm getting at - if I were to define a new layout 
dialect could I re-use/take advantage of the code that is already 
written behind the parsing and behaviour of those elements that are 
not layout specific

AdrianS, I've worked with Swing and know what you are talking about. 
The equivalent to a Java swappable layout model in the R3 GUI (when 
last I worked on it) is a group style. The "group" and "panel" styles 
are two such grouping styles. More group styles and other composite 
styles can be added. What you request is built into the model already.

Brian, what you're saying though is that a containing GUI element 
is responsible for the layout of it's children as opposed to delegating 
that functionality to a layout manager. In Java, each GUI component 
that can be a parent can have a different layout manager added to 
it,but it doesn't manage the layout itself.

You can create your own layout manager styles with little difficulty. 
Or you can create container styles that layout their children in 
a specific way for a specific purpose, like a scroller pane with 
scrollbars. You don't need separate layout manager functionality 
since laying out stuff in a custom way is an inherent feature.

I suppose I just had the expectation that REBOL styles would only 
concern themselves with look and behaviour (group acting as a tab 
group, for example) and that layout would be handled by other types 
of constructs in the dialect, the way I'm used to. As for needing 
hierarchies in Java, these are there in the GUI component declaration 
to match the visual hierarchical arrangement and to make control 
of child visibility, event passing  and layout match what you would 
expect to see coming from such a visual arrangement. If similar control 
can be achieved by REBOL in a different way, so be it.

graphic pipeline like ... hum  the rendrering pipeline in my GPU 
?  or just a software like pipeline wich havec pipeline only the 
name....???

http://a-browsertests.s3.amazonaws.com/219.gif

like amount of processing in my rebol ok but one thing ... now in 
day grphical cards are hella weak in 2D rendering and espacially 
under windows 7 they are even slower than a 3DFX voodoo 3 back in 
the days ...

SOOOOOOOOOOOOOOOOO

what i like with carl implementation is that he shows with better 
source code algorithm you improve the rendering queue even if you 
don"t  access the hardware specific accelartion part wich will be 
a pain to handle anyway...

doing 2D using  3D hardwar stacks generates a lot of problems due 
to the antialiasing and mipmaping manipulation ( and  drawing text 
without true font but with mipmaps  provide you no gain the card 
will not use it's fonts acceleration then)

cache are always a good thing for repetitive task if you draw use 
is to draw 1 square or 1 circle or 1 line of texte will you don't 
need a cache buuuuuuut

if you do  a document rendering like area-tc with alot of  time the 
same calls over and over again then you see the obvious optimisation 
brought by a cash

i hope with the cash we tends to a more extensive use of AGG and 
a less anecdotic use of this marvelous fantastic powerfull tool (aGG)

6 am i got a heavy day yesterday and i take some time before going 
to work to be tuned ....

multiple draw blocks per styles it's like a stack systems ?  you 
could influence a layer of graphical contents without touching the 
other block

Not sure, there is one state at a time.

ok it's too early to speak english for me i need a coffee and a proper 
wakeup

i'm leaving i will try to get around at a more suitable time for 
me ...

http://rebol.hmkdesign.dk/files/r3/gui/220.png


220 to 225 shows the resize engine in use with globally set borders 
with quite good pixel accuracy. the border style should be possible 
to set globally according to cyphre in a similar way as in VID, of 
course without the artistic limitations of VID.

http://rebol.hmkdesign.dk/files/r3/gui/225.png
http://rebol.hmkdesign.dk/files/r3/gui/226.png


First integration test of the new resizing scheme. It looks much 
more solid and accurate, but there are still a few bugs (the partially 
blanked button in 226).

WAHOUUUU !!!!!!! REBOL GUI START LOOKING LIKE SOMETHING A PRO COULD 
SELL !!!

I thought I just wasn't perceptive enough to notice a subtle error 
in 226. I can see the problem in 227. :-)

there are still a few bugs (the partially blanked button in 226

 - yes, that is a Draw bug as it looks. BTW, it has nothing in common 
 with the new resizing scheme, the above new resizing scheme test 
 just exposed the bug

yes, there are a few internal releases of the host kit.

internal releases meaning a restricted release

(I'd like to see a 28 kb R3 too, but alas...)

Graham, from what I remember from the old "host kit" (2007), i don't 
think you can do that, as you had to pass a function table to the 
dll.

The DLL is the plain Rebol interpreter. All the sourrindings, named 
host-kit, that you need to make use of Rebol on a particular platform 
is in the EXE. The EXE loads the DLL at init time.

For example: If you can't get AGG to work, you need to do a replacement 
with an equal API layer.

Graham, I don't see a real good case to use the R3 DLL within R2. 
Why to do this? And the interpreter in the DLL is nothing "useful" 
on it's own. It requires at least a simple host environment to do 
something useful.

The host of the hostkit can itself be a dll, and that dll could be 
designed to be loaded by R2.

yes I have a client which would benefit from R3 within R2 specificaly 
to use PARSE..   as brian noted, I'd compile the R3 host as a dll 
and try to make a routine in R2 to access it.

Graham - we use AGG 2.4, because with 2.5, Max changed license to 
GPL. But Cyphe said, that there is not much new in 2.5. AGG is a 
dead-end anyway - it is not further developed by original author 
(Max Shemanarev) imo, but still good.

so far we're not even taking 100% advantage of AGG, so there's a 
bit of juice left in it.

Yep, there are some interesting methods, like bounding_rect or so 
(to calculate the bounding coords of a shape)

so both are in a way relevant

Henrik, something really interesting would be a method to get back 
all the constructed vertices (after transformations).
As a shape block.