World: r3wp

oh sh*t, that belonged to my brother into different world :-)

We can't easily make 50x50 button for e.g.? With Carl's GUI, it was 
really easy - button "50x50" 50x50, but with new gui, even if initial 
size is valid parameter of an option block, the requested size is 
not prserved, as can be seen by simple: view [button 50x50 "test"]


I hope we are not back to nonsense of being more clever than what 
user wants, limiting the size of a button?

right, and then you want to set the color and other appearance items 
that are supposed to be managed by the skin. :-)

but you need local overides for almost anything.

we musn't fall into the trap of *only* using styles.

I meant *pre-defined* styles.

honestly I want to be able create big red buttons.. :) I like freedom.

honesty, these things are what keeps us from doing really great GUIs.

no. having an engine which provides great GUI defaults is essential, 
but not at the cost of being able to tweak a widget .


skins/themes/stylesheets provide usefull defaults,  but having access 
to overide any of this is absolutely necessary.

I don't want to rely on the fact that   'red-button-which-doesnt-resize-aligns-right-bold-with-larger-white-font 
  is a style   ;-)

and all of this has to be able to change dynamically.

I have already explained why before, so I'm not going to do that 
again. But suffice it to say, that it's my personal opinion and may 
be overridden. I just think it's a shame to be blinded by apparent 
"freedom" by having the ability to meddle with faces directly. When 
building large apps, this is a mistake, an illusion of freedom.

sorry, but having built "large apps" and for clients, this freedom 
is very necessary.  


if you don't use it that will make the gui generally better, but 
there is always a time when its required and it has to be possible.


what VID lacked had nothing to do with styles and looks.  it was 
the fact that everything under it was insufficient at best... layout 
sucks, event system sucks, dynamicity sucks, no way to switch stylesheets 
on the fly, no locale, etc.

VID's strenghts where the fact that inline styling was possible and 
easy, you could store and use stylesheets and the dialect was very 
innovative.

the best VID users built stylesheets as a lib and then used that 
directly with the least inline styling possible.  but you always 
require to tweak things here and there.  even when the layout resizes 
on its own

I don't agree, and I've also built large apps, both with the VID 
Extension Kit, which supports the philosophy of restrained access 
to faces and RebGUI, where face hacking is necessary. The former 
is significantly easier to work with, than the latter due to not 
needing to be explicit on every single twist and turn. The lack of 
proper uniformity does not leave room for an intelligence beyond 
the style level, and you will not unveil the potential for reducing 
code size, testing times and greater overall consistency and stability.

the single most important part in all of that is "hacking is necessary" 
which means that without hacking you can't do much... 

it most not be necessary it must be possible.

When it becomes possible, people use it and then over-use it. Thereby 
we get incorrect methods for building proper layouts and we can't 
go beyond where we are in intelligent handling of a layout.

(you won't get me to agree after 4 years of working with both methods, 
sorry)

well, we agree to disagree  :-D

Henrik - don't even try the old crap on me again :-( The reason why 
Carl started new GUI was because of Gab's GUI was not all that easy. 
If I want 50x50 button, don't even dare to dictate me, that I can't 
easily have it. If I can't, I almost refuse to use such a system 
period.

I refuse to build new button style, just to have it like I want it.

This is rudiculous - so you have init-size as an option, yet it is 
ignored,or totally twisted, in that regard, that only X axis gets 
adjusted. That simply does NOT work as expected, and if you guys 
refuse to understand, that the freedom of expression is what ppl 
are interested in, then you are building completly different GUI. 
It is supposed to be easily used.

So far - RMA - public | 0 : 3

sorry 1 : 3

Henrik - I believe you will fail explain technical reason, why it 
prevents proper skinning. Carl's GUI used skinning, and was able 
to provide such buttons. That is just stupid limitation imo, and 
should be removed ....

This is not even funny. I know your long time opinion, and I think 
that you pushed in into the design. I believe you have some reason 
based upon your experience, but I am really not surey, it is necessary 
limitation.

You have min-size and max-size still, right? To support resizing, 
you need to support sizing. But that doesn't mean the syntax is the 
same as in R2's VID or Carl's GUI.

Specifying color is a different matter though. You need abstract 
functional colors at most in styles and layouts to support skinning, 
not real colors.

how I see it is that you need to be able to hack the faces, but you 
must not be forced to do so because the framework and API are insufficient.


if the system is strong enough, it will live with very little in 
app hacks.  it will live on its own merits.

but when a client tells me, I want this banner red, this one navy 
and this one black... I've stopped trying to convince them that its 
ugly, it just irritates them, and it inevitably leads to bad relations. 
   I will convey my experience and state that its not something professional, 
but in the end, the client writes the check, and I need to be able 
to push the bytes out the door.


there is no philosophy or ideology when you need to deliver and a 
tool can't turn around and be flexible.


I don't want to post stuff from other engines here since its not 
a comparison game, but I've used many APIs from prbably 20 different 
dev platforms, and everytime I use one which has an "unwielding" 
ideology where you can't modify things to make them do what you want... 
as a user, I get frustrated and I just look for something else to 
do and/or work on.   


good defaults, decent properties and backbone, clean style.  all 
the rest, open and hack.  I woudn't be a Reboler otherwise.

that's just my 2 cents.

The current design is supposed to allow non-GUI-designer programmers 
to specify layouts. Even if you are both the layout programmer and 
the style designer, the work is supposed to be separated. For that 
matter, a proper layout dialect for the types of apps that the R3 
GUI is made for (not games) should be portable to other device form 
factors, accessible, etc. So if you need to be a theme designer, 
do it in the theme section of the app, not the layout. And if you 
need to be picky about the styles, do it in the style section of 
the app, not the layout.

This makes your app more manageable, more portable, the benefits 
go on.

in theory yes... in practice no.    exactly like OOP... on paper 
and in theory its all rose and perfect.  in practice its a nightmare.

anyways... I'll stop participating in this debate.. just cause I've 
got other things to do  ;-)

BrianH: the strange thing is, that different color is actually supported. 
It was not with Gab's GUI IIRC, that was even more strict. I can 
imagine the trouble with mateiral system, when you allow simple color 
override. But - how is button's size influencing  or limiting the 
skin system? It has nothing in common imo with Carl's or other's 
version imo, it is just one developer applying his idea. How does 
new system differ to Car's version in that regard? Carl's version 
was supposed to use skinning too, so?

Or more direct question - how does button, with its border and gradient, 
differ from e.g. even more complicated style as panel for e.g.? And 
panel has border, and gradients too. While panel can be sized in 
a layout as an option, button can't

Unless they implemented the materials system and abstract functional 
colors already, neither support them But this was planned for both.

And even worse - if button is not supposed to react to the sizing, 
the size option should definitely be removed, and it should DEFINITELY 
error-out in the dialect level. Why am I supposed to loose my time 
trying to adjust button, seeing the option there, if it is not supposed 
to work?

When I expressed my opinion on Gab's GUI to Carl, I told him, that 
I miss some aspects from easy of use of VID. I can understand, that 
when things get more complex, you have to put some limitations here 
or there. But - it stopped to be a fun. I need a system, which I 
LIKE to use, which is NOT BORING to use. If I want to use boring 
business GUI, I can go to Delphi with its boring the same buttons, 
and I even believe, that in the end it is Delhi, which allows me 
to shape the button WHATEVER size I want.

The current design is supposed to allow non-GUI-designer programmers 
to specify layout

 - no, it is apparently not. Layout user wants 50x50 button, and can't 
 have it.

Layout user, is not probably going to do his own styles.

I am going by the design, as far as I know it, not the current implementation. 
There are limits in the current implementation that aren't part of 
the design.

The worst thing we can do is to let the option there, while not acting 
upon the override. So - if we REALLY want button's size to be fixed, 
the option really has to be removed, and it has to fail on GUI parse 
...

From Max: "I don't want to post stuff from other engines here since 
its not a comparison game, but I've used many APIs from prbably 20 
different dev platforms, and everytime I use one which has an "unwielding" 
ideology where you can't modify things to make them do what you want... 
as a user, I get frustrated and I just look for something else to 
do and/or work on."


And I say - Amen. Set it into stone, and you might wonder in the 
end, why you have no following. It is exactly the same reason most 
ppl are not able to understand, that no matter how logical it is 
to have the skin done as a last, R3 GUI did not get any following, 
because of the first look experience simply get's users not interested 
at all. And it was said here not jus by me. You can protest, but 
that is all you can do about it.

Pekr, if you want ridiculously obese button, just override max-size.

You shouldn't have to do it, but you can.

will give it a try ...

view [button "ok" options [max-size: 200x200]] - does not work. Simply 
imo max-size is not part of the options block, only the init-size 
is ... And - I want it being part of the options, so that I can set 
it inlined, or in options [] block. If not there, it is more complex 
hack we wanted to avoid imo ...

So no easy apps as calculator, POS system with big colored buttons, 
that really sucks ....