AltME groups: search

Right. So it looks like Pekr wants to be a style maker, but for some 
reason is doing it in the layout block instead of with stylize (or 
whatever it's called)?

So this gets back to a "Render unto Ceaser that which is Ceaser's. 
Render unto God that which is God's." argument, even if both are 
Pekr :)

we should change the button init code so it changes max-size if user 
specifies the inline pair!

 - I am against that change, you don't know (not being able to read 
 mind) what is the Max-size user wants to have anyway"


My take is - if the max size is lower than requested size, then let 
be requested size be the max size. What could be the harm? Or do 
you think that in such a case, user could complain, that his button 
does not resize to being even bigger?

While Cyphre and I are fighting for that same user a few minutes 
later when they need to make a change :)

I would rather hear it from him though. He might have a really good 
reason to choose one or the other.

Guys, I just read through all this and I'm confused a bit why it's 
so complicated.

When this is on style level, just writting button should give me 
a button with these facets.

min / max-size are IMO for style writers first. And can be overrided, 
with a not so easy syntax, by programmers.

I am OK with min-size and max-size being a little harder limits, 
if the reason they are in the style is because of hard visual limits 
(size of contents and such). The limits on the size of button seem 
a little arbitrary at the moment though. Then again, I keep reading 
articles about applicatons and web sites not working on different 
form factors because of hardcoded limits in their layouts, when their 
styles should be adaptable to match the form factor. This is why 
we are trying to cut down on this stuff in the layout dialect.

Robert, I agree...the question is should we remove the iniline pairs! 
? I don't care but Pekr insists it is a problem.

Cyphre - you misinterpret me a bit - on one hand, yes, I think those 
are usefull to have for occassional GUI hackers, for the fun factor. 
If user is an idiot, and wants to define each button differently, 
so be it - there is analogy with inline CSS style. But if we allow 
it, the behaviour should deliver it ...

I don't see a problem.

the style-writer of button needs to specify min & max values as they 
are meant: absolut minimum this style will work. IMO for a button 
with 1 clikc areas it is 1 pixel.

I thought there is a strategy to the sizing, and that styles somehow 
have some sizing tendencies ... I remember some spacers, etc., but 
dunno how new resizing is implemented ...

As said, the style writer can specify these. For a button the max-size 
is most likely less: 1980x1024 for example.

There was also one proposal, to rename options/facets:


- the naming is reversed - in style, you use options for inline parameters, 
whereas in a layout, you use options to set facets


- I understand Carl and maybe others would not like to give up on 
facets being a name for properties/attributes, but ....


- I proposed to rename it, so that options in a layout = options 
in a style, and for inlined style definition we could use facets, 
or inlined name.

What do you think about it?

Kaj, perhaps this is the same misunderstanding as for host kit work. 
It seems that many times, when Carl or RM Asset offers a task to 
the community, the response is negative.

Yes, no problem. But just to get a different init-size it's a bit 
overkill, or am I missing something?

Would it not be better to focus on flow and how a style will fit 
in a cell, rather than impose the size of the button on the button 
itself? We are used to assigning size to the button directly instead 
of posing restrictions on its surroundings, because that concept 
did not exist in VID.

Brian, correct. Pekr, either you as user will understand and agree 
the rules or you need to lear a bit more and become 'style tweaker'.

Henrik - I can't see a great effect here yet :-)

They are important to discuss and you will not get every wish granted, 
but it's only a matter of seeing the big picture of things.

Brian...I don't have multiple screens so I personally have no high 
priority in this. But this is open to anyone..things to do:

1. do a research of the multi-screen handling under different OSes 
(win, linux, mac)
2. define proper abstracted interface
3. implement specific code for each platform

So, instead of on an individual control basis (like old Delphi) sizing 
is done on a grid model (like new Delphi), the change coming about 
for the same reason Delphi changed that: Ease of development and 
maintainability?

grid model: Yes, that is a nice thing. But IMO can be done later 
anyway. Not sure we should add this complexity yet. Let's get the 
simple basics clear first.

Panels implement something like a grid model.

Isn't following a bug? All three buttons are of the same size, even 
if with different init values? Is that intentional, e.g. resizing 
model adjust them? 


view [b1: button "b1" do [print b1/facets/init-size] b2: button 180x23 
"b2" do [print b2/facets/init-size] b3: button 230x230 "b3" do [print 
b3/facets/init-size]]

130x24
180x23
230x230

BTW our current decissions is:
- style writer sets min/max/init-size
- user can override init-size by specifying a pair!
- dialect errors out of min / max-size is violated

I asked dockimbel about this about a month ago.

Erroring out on size inconsistencies is a proper solution

Been away for a while. As the GUI documentation been produced ?

In my opinion, using a style, the user "automatically" agrees to 
the Min-size and Max-size as specified by the style designer, unless 
he adjusts the values as he sees fit.

The problem is that a user doesn't see what he is agreeing to, as 
it is elsewhere in the style. *All* users will be surprised because 
they initially don't know the resizing rules, and not getting hints 
is not a good way to learn them

I agree that a system without errors is nice, but then the userfriendly 
alternative is to have true style overrides

I mean overriding the style in the layout, what you have been discussing 
for a day

What you are effectively saying is that a userfriendly dialect is 
impossible. I don't think that's acceptable

When a user specifies 100x100 you don't want to execute that

For me "user friendly" means "following simple rules, that a user 
can know"

Yes, so you don't want to draw a 100x100 item

Yes, so you don't want to draw a 100x100 item

Yes, so you don't want to draw a 100x100 item

Yes, so you don't want to draw a 100x100 item

If it is not used in a userfriendly way, it shouldn't be there at 
all

when a concept of default size is there, that is usually what you 
want the pair to be.  when it goes beyon min or max bounds, usually 
you want to push these to at least match the default size...   the 
developper is expressly asking for an adjustment to the default.


the thing is that when a widget is in an auto-resizing layout, asking 
for 100x100 might not actually give you that size, because all the 
widgets are subject to the layout in which they are displayed.  in 
row/columns, you will be subject to equalizing other lateral sizes 
in the list and may be given more space in the longitudinal size, 
such that in fact, your button may be larger than what you asked 
for.


the only way to force a 100x100 button is for the gui to support 
static sizing within a dynamic layout, or support max-size and set 
it to the exact same as default size effectively making it a static 
sized button.

There currently is only one Frame resizing model (which works in 
X or Y).   though in fact, one can tweak the frame's default decisions 
in substyles.


this has been done in the scrollframe which uses a sub frame dynamically 
and renders a bitmap then uses the bitmap in the display.

because all the layout is a network of nodes, you can really do funky 
stuff... I plan on making a demo of such things as snapping overlays 
to edges of other widgets.

Does the Frame resizing model use a kind of "tabular layout", or, 
is it more like the hgroup/vgroup styles, where only the rows/columns 
are maintained, but not both at the same time?

A quick question: is proper alignment along font baselines planned 
for the GUI?

Not that I understand anything about GUI implementation, but font 
rendering sounds like a mere technicality for me.

Proper alignment of elements along font baselines sounds like it 
_could_ have a deeper impact and requires some planning.

But no idea, really. Maybe it's just a technicality as well :)

I agree that precise use of the baseline should be doable.  its the 
only way to properly handle multi-font display.  it would also be 
nice to be able to inspect the font so that we can measure the different 
metrics of a font.


x-height, descent, ascent, cap height, linegap (leading), H space 
width, etc.


On the Amiga, I used to align text with these values in code and 
it seemed to be much better.

Panel resizing user poll:

Background information:


For resizing purposes, every graphic element (including panels) has:

INIT-SIZE, MIN-SIZE and MAX-SIZE dimensions:


* INIT-SIZE is the size that is being resized (magnified or minified),

* MIN-SIZE is the smallest possible size of the element after resize,

* MAX-SIZE is the largest possible size of the element after resize.


Until now, we used auto-sized panels, for which we always (after 
every content change, like insertion of a button, etc.) recomputed 
their INIT-SIZE, MIN-SIZE and MAX-SIZE based on the sizes of the 
elements the panel contained.


Currently it looks, that there are many reasons, why it may be better 
to *not automatically recompute* INIT-SIZE, MIN-SIZE and MAX-SIZE 
after at least some of the possible change types.


Therefore, we introduced a non-auto-sized panel, which auto-computes 
INIT-SIZE, MIN-SIZE and MAX-SIZE on-demand only.

Our questions:


* After inserting a button (or other contents), what do you think 
should be the default action - recompute all the above values, or 
not recompute any of the above values?

* How to specify a non-default behaviour? Cyphre came with a proposal 
to use a /UPDATE refinement accepting a WHAT block, so, e.g. /UPDATE 
[MIN-SIZE MAX-SIZE] is required to update just the specified dimensions. 
Would you find a different alternative more convenient?

The outcome of the case not recalculating INIT-SIZE, MIN-SIZE and 
MAX-SIZE would be, that the panel would try to occupy the same space 
as before the change. That may be what the user wanted, if he had 
a specific idea, how large the panel should be, regardless of the 
contents he might add into it later.


The outcome of recalculating INIT-SIZE, MIN-SIZE and MAX-SIZE (on 
the other hand) is, that the panel dimensions are auto-changed after 
almost every change. It looks especially "ugly" in case dividers 
are used to change panel dimensions, since if you change the X dimension, 
and later the Y dimension, due to INIT-SIZE recalculation, your former 
change may become totally ignored.

So you are referring to what happens when the faces are first rendered 
or when a user manipulates the GUI manually or both?

The above is not related to what happens when the Panels are first 
rendered. It refers to the case, when somehow, a panel changes somehow, 
e.g. whan a new button is inserted into a panel, or a divider in 
a panel is moved, ....

Thanks. Then, if I am thinking about this correctly, in the case 
where a user might increase the size of a window, would it be likelt 
he wants the interface to be larger or that he wants to see more 
of what is not visible. Am I off in thinking this is what you are 
asking?

I personally don't like any automatic sizing... when I design a gui, 
I know exactly how I want the components large with pixel precision.

Yes, I see that point as well. Most of time I resize something it 
is to either gain more real estate (Obviously shrinking the window) 
or to see what is being hidden, as with a large spreadsheet or to 
show me more as one might do with an email client.  In the latter 
case, the objects resize larger but not the fonts, etc. This ALTME 
window is a good example. If I want to see more messages I can increase 
the size but I don't expect everything to just get bigger.

I have no preference, as I am not able to imagine all possible outcomes. 
I fear we might get in a weird situations, when someone adds a button, 
you will see part of the button, but panel will not be large enough. 
But otoh I am able to understand, that auto-adjusting what user thinks 
is the right size to the pane, might be unnerving too. Anyway - those 
questions are not for users, but for style programmers, no? Or where 
I am supposed to use /update refinement?

Yes, mainly when programming a style, you nailed it

sorry, crying right, but on a wrong toom here ;-)

I can see following possibilities:

PANEL ENLARGEMENT:

- panel is not enlarged, it adds scroller

- panel is enlarged, but it does not affect window - window adds 
scrollers

- panel causes enlargement of the window (hence window moves, and 
we should be carefull, because new size of the window does not need 
to fit to the screen - it is a special case)

PANEL SHRINKS (content removed):

- panel just stays as is, eventually removes scrollers

- panel shrinks, to fit its content, but window remains of the same 
size

- panel shrinks to fit the content, window shrinks to fit the panel

All above plus the combination of auto, vs manual

So - one more note - if above would be wisely implemented, I am for 
auto-update with manual override not to update for the style author. 
But if I would get unexpected results, I prefer not to auto-resize 
probably (but not 100% sure, unless giving it a try for a while)

 if I insert new button there, there is no place to enlarge the panel 
 to, so what happens?

 - that is actually not true; when resizing, the algorithm resizes 
 proportionally to the INIT-SIZE, which means, that a change to INIT-SIZE 
 of an element changes the proportions of displayed parts, while no 
 change to the INIT-SIZE does not

example: if a (maximized) window contains two panels, and you enlarge 
the init-size of one of them, leaving the other as-is, the proportions 
change, and the panel with enlarged init-size will become greater

I still miss simple style to group things. I always wanted a panel, 
with border, gradient, etc., but then also exactly the same style, 
but with zero visuals ...


IIRC, in Carl's GUI, it was panel vs group - except the fact, that 
it group used opposite coordinate system - very unwise btw


In RMA's GUI, if I am not mistaken, group is internally completly 
different - it is here for those users, used to VID2 - you have to 
use RETURN keyword, it does not align in grid cells, etc.


So - how do I easily define inline style, which removes panel visuals? 
I don't want to create new style for such a simple and usefull thing. 
And I start to think, that 'group style is here just to confuse users 
...

Andreas: "A quick question: is proper alignment along font baselines 
planned for the GUI?" - no, it is not, since the understanding is, 
that it has already been implemented... In case you see some quirks, 
please, let us know.

In the original DOM 0 model, each event had one handler attached 
to it.  In DOM 2, you instead have listeners, as many as you want, 
listening for an event.  Each of those are triggered by the event. 
 So, it's like have 10 actions on a button, each of which are triggered 
on a mouse click.

Yeah ... I was thinking that maybe we should be using a similar event 
model to make it easier for us to learn both :)

We need the ability to create events, and we should also be sure, 
that we are able to obtain modern events, as e.g. above mentioned 
FF4 can now handle multi-touch native Windows 7 event. And we are 
not even receiving such things as ctrl tab for tab handling. What 
I still don't understand is - the system port? Is that port still 
available in R3? And what was it good for? It would be e.g. nice, 
if by opening the system port, you would insert such a listener to 
the OS event model, registering for particular events. Well, that 
might be slow, if you are not carefull, but that way you might be 
able to receive any system event possible .... but not sure it is 
even possible :-)

Yeah, they also have event bubbling .. so a click can propagate outwards 
for other things to deal with

Rebolek - I know make event! is possible, but does it actully work? 
IIRC it was not fully working in early alphas? So you say I am able 
to simulate e.g. a keypress, mouse event, etc.?

is make event! attached to a particular GUI object?

Graham - why should it be? I expect it being just a structure/object, 
you fill in the data, and it gets inserted into the event queue, 
then your objects react accordingly, like if the event would be generated 
by normal action.

So, how you would you simulate a mouse click on a button then?

a button that might be buried by another window on top of it?

resize on a window?

and a way to record macros?

is there a way to enter characters into a field ?  Like the DEL, 
and Backspace ?

I am going to work on it a bit today, and tomorrow, then I can release 
what I have ...

e.g. following function (trying to study material system):

set-material: funct [

 "Chooses the gradient from a material object to use with a face mode"
	face [object!]
	mode [word! none!]
][
	all [
		mat: get-facet face 'materials
		set-facet face 'area-fill any [
			all [mode select mat mode]
			select mat 'up ; default mode is 'up, for none inputs

   select mat first words-of mat ; if 'up does not exist, use first 
   word
		]
	]
]


E.g. for panel, there is no 'materials facet, just 'material one, 
as can be seen in on-make actor ....

does the panel style have a draw-mode 'plain?

I believe that is a problem that is yet to be solved.

There are still many things to solve, so there are bound to be many 
regressions until we reach a point where no more features are needed 
for now.

I a sense, this is very disappointing, as we have no more the possibility 
to use the Carl's gui, and the RMA 's version seems far from being 
usable !

So far, Petr's feedback helped us a lot and we know the GUI is not 
perfect yet. Nevertheless the more people help us the faster we will 
be.

Robert - I can't see any subsystems ready, other than proper resizing 
(which is really nice), and focusing system. How can you say 2-3 
styles are enough to judge the design? I would not call non-working 
styles being an eye-candy :-) This is all about architecture -  when 
porting demo, I meet the case when I am able to easily change e.g. 
color of the scroller with Carl's GUI, which does not seems to be 
a case with RMA's GUI, or I just don't know how to do it. As I did 
not want to bether you here with such simple stupid thing, I tried 
to study material-system myself. But - I can tell one thing - if 
those things are not simple on the surface, it is either - missing 
docs, or very wrong architecture.


You should really remember, why Carl decided to rework the GUI - 
to be the pleasure to use, kind like of Amiga AMOS Basic, yet still 
allowing more complicated designs. If that aspect will not be pursued, 
ppl will not like the GUI. And what is the system good for, if not 
liked to be used by ppl?


OK, at this point, with 2-3 styles in focus, I might postpone port 
of the demo, no? As the demo is surely done with more than 2-3 styles 
:-) I will soon finish it to the state, when clicking the left side 
list items will not crash the demo. Non working stuff will be commented 
out. Then others might try to get more complicated set-ups running 
...

So much questions, great :)

I want freaking to change the color of the scroller
 - If not possible right now, it's bug and will be fixed.

How do I 
destylize" panel for e.g.?" - use material NONE

What is the correct way to call an actor?

 -  do-style FACE [object!] ACTOR [word!] DATA [any-type!] ; for example: 
 do-style face 'on-update none


how can I recognise, what arguments particular actors should obtain

 - good question. I have some ideas how to solve it, but right now 
 you should ask or study source :)

How can I properly attach scroller to progress bar?

 - In your case it should be auto-attached and 'attach shouldn't be 
 needed. Maybe 'attach doesn't work at the moment as the auto-attaching 
 of scrollers is actually a very bad thing that brings more problems 
 than it solves.So ATTACH is going to be reviewed and fixed when necessary.

I really wonder, if R3 GUI sees ANY regular development?

 - It does, but the developement does occur in areas you're probably 
 not interested in (GUI internals, TEXT-TABLE...)


Recent R3 GUI status is, that it is not usable for more than simple 
dialog box
 - Typical Pekrovina ;)

- Rebolek - if a button and field are enough for you forms, than 
yes, GUI is usable for a real-life apps :-)


- do-style - OK, understood. I also found do-face in the sources. 
Is it relict of Carl's GUI, or is that function good for something 
too?


- actor arguments - Carl did so by simply put them in the comments 
of the first line, right after the left bracket. All it needs is 
imo a discipline, when writing styles :-)


- I am not much interested in attaching the scroller to progress 
bar, apart from getting demo ported. But - it surely should be allowed 
and fixed. I will ask different question here - how do I display 
scroller, with minimal sized knob?

DO-FACE ... "Evaluates the reactors (result actions) for a specific 
face.". So no, it's not a relict, it does just what it says.

Scroller attachment is actually a bad method as attachment code is 
rather complicated and error prone, hence it has been removed. Scroller 
will likely only be used where it makes sense. Better to use SLIDER 
later for demoing things like this.

Henrik - I thought that it nicely worked in carl's demo? As for me, 
I never found any practical reason of why to attach scroller to progress 
bar :-), but I might like "general" way of attaching things, to "cause 
an update". I mean - when you e.g. change one value in a field, some 
resulting non-editable field gets updated. But that might not be 
role of 'attach anyway ...

ATTACH is useful, it's just auto-attaching that isn't that great 
idea. If ATTACH doesn't work, it's a bug and will be fixed.

Ultimately a scroller and an item to scroll has many subtleties that 
you don't notice at first, such as step size, whether you want smooth 
or non-smooth scrolling, and the structure of the item to scroll, 
and whether you want separate behaviors for vertical and horizontal 
scrolling. Then there is also placement of the scroller. Do you want 
the scroller to automatically "sense" what direction it has to scroll 
in?


All this means that the scroller should treat each such case as a 
special case and you can't ask a style developer to meddle with attachment 
code inside the scroller style to deal with this issue. It's better 
and simpler to have a "dumb" scroller that will do your bidding for 
your style.


It "works" in Carl's demo, because he only has 1 or 2 cases to work 
with, but it doesn't really work that well. He never implemented 
tables, image-pans, icon lists, chat lists, maps, browser windows, 
etc.

Then it would be a much better idea for Pekr to use SLIDER.

Rebolek - then there might be a difference to init knob size. I know 
it should be recalculated to the amount of data, but maybe by default 
it could be the minimal size, instead of 100%?

Nope, slider is a value adjustment tool. It doesn't need knob size 
management.

What is the situation with compound styles? When you e.g. design 
scroller - is it a mixture of two styles? Slider (in old gui sense) 
+ arrows? I mean - if we have arrow style, and you will use the arrow 
in some compound style, then when you change/restyle arrow, will 
it change also inside of compound style?

I have yet to see a single case where FACED is useful to change my 
mind about that decission.