AltME groups: search

btw Pekr, from an API designer's standpoint, these types of questions 
are all very good  IMHO.  they force us to reflect on decisions and, 
often, trying to do so will either confirm them or with discussion 
might give new ideas.   I'm not part of this gui team, but I'd really 
like if someone asked pointy questions like this on my stuff.

those come from concrete effort to make Carl's demo translated to 
the new GUI engine  :-) First and second screen is displayed, but 
make-panel just differs, and options argument does not exist anymore, 
it also has reverse order of arguments, and does not accept style, 
but face instead, and so on ...

I simply need to make a block with layout elements a face. Trying 
with make-face, but make-face accepts two arguments - style name, 
and options, I don't know what should I submit for the name ...

the interface was really nice:

make-panel: funct [
	"Create a panel from layout dialect block and options block."
	style [word! none!]
	content [block! none!] "Contents of the panel"
	options [object! block! map! none!] "Options of the panel"
][

and you made it:

make-panel: func [
	face [object!]
	layout-type [word!]
][

not commented, func instead of funct, removed options, reversed arguments, 
and made it accept face instead of the layout block. You should not 
excuse something by just stating - don't use it, it is just internal 
function ... what if I want to use make-panel?

My question still persist - how do I easily create a panel from a 
layout block? :-) Instead of one nice funcitons, which served well, 
I need to study  different concept, and make-panel is generally not 
usefull to average mortal :-)

trying to do some tests with Carl's demo, and it is going to be pain-in-the 
a..., to insert returns in there

 - that is an error, the group style is not the style Carl had, so 
 you should not do that at all

MIN-SIZE and MAX-SIZE of panel - currently, those values are computed 
by the updating software. Do you think we should allow the user to 
set these? When you think this should be allowed, and for what purpose?

...and that is what Carl insists on

none of my algorithms have max-size and its never been a problem 
in any layout I wanted to do.

Well, relating MAX-SIZE to weithting was a bad idea, and we corrected 
that.

I haven't had time to play a lot

- then don't, just pick one example, try to resize the window, and 
see how it works.

no html needed when you just need to copy a part of it and do

...and, it is not mdp

Ladislav: ""I can see you use empty rows...Aren't we wasting memory 
here?" - how can an empty row waste memory?" - :-) This is misunderstanding 
:-) My question relates to my previous discussion with Cyphre, about 
removal of 'faced element. Previously, we had facets, and faced (instance 
locals). Cyphre pointed out, that now everything is instance local, 
and goes into facets. If you want stuff to be shared, new 'intern 
slot should be used.


And that was my question - I can't see intern used anywhere in the 
stlyle definitions. What I noticed is, that in the facets blocks, 
stuff is somehow visually separated by empty rows. Hence my question 
- if I see things like min-size, max-size - aren't those a good candidate 
for items being shared? And if those are not shared (referenced), 
we are kind of "wasting" memory here. I think that it will not be 
significant though ...

Well, empty rows in the source code are just means to organize the 
text anyway ;-)


Regarding your MIN-SIZE and MAX-SIZE - those aren't shared, since 
I thougth (and still think), that it is necessary to allow for every 
face to have individual MIN-SIZE and MAX-SIZE

Example: it is expectable, that two panels have different MIN-SIZE 
and MAX-SIZE, especially if their contents differ

Really? E.g. think about buttons. I think that all buttons will share 
those values, no? But anyway - this is just speculation on my part, 
and call for "premature optimisations". In fact I don't know how 
to measure memory consumption (even if we have stats function) of 
an object, which has two more fields (slots) plus values. Then you 
can count average number of instances your app has, and you can guess, 
how much more memory your app is going to use. I expect it being 
just KBs ....

Ladislav - did not read all your posts here, but as you are here, 
and for me to proceed - how do I "easily" create panel, if I have 
layout stored in a block? Carl's demo uses:

view-sub-panel: funct [
	index
	main-pan
	desc
][
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [
		pan: make-panel 'group pick test-blocks index [columns: 1]
		poke test-panels index pan
	]
	switch-panel main-pan pan 'fly-right
]

his

 make-panel used three values. OK, options block is not needed, nor 
 supported right now. Function attributes are now reversed (dunno 
 why, the argument order is not compatible with make-face for e.g.). 
 That is still easily fixable. But now "rma's" make-panel accepts 
 face, not dialect block. I tried to use make-face on a dialect block, 
 but no luck ....

I simply need to fix this line: "pan: make-panel 'group pick test-blocks 
index [columns: 1]", if possible. Henrik suggested that the aproach 
is different, and that I should use 'content functions, which I know 
nothing about yet.

Maybe such a style could be added by default, but not sure others 
would find it usefull, nor do I know what name to use ...

 - yes, that is possible. The difference between original, Carl's 
 implementation, and the new one is, that you have all the box model 
 attributes accessible, so you can do it easily now on your own.

re min/max-size, here's my take. I don't mind having both, not a 
big deal for me. But - when I tried Carl's examples back then,I tried 
on my nice Samsung FullHD TV. I maximised the screen, and wondered, 
why the heck fields don't resize properly. Then I found out, that 
their max size was set to 900 pixels. I asked Carl - why? And he 
told me, that fields should not be long, or it does not look nice 
anyway. So - as I know myself, my intention for max-size for the 
years to come will always be to cover FullHD displays. But as you 
can see, then it is artificial - I will simply use values, just to 
avoid effect I had with Carl's example.


As for min-size - I was negatively surprised by its removal, because 
I wanted panel of certain min-size to be displayed. But - I found 
there is new item, called initial-size, which fixed the situation 
for me ...

btw - can someone confirm the rendering "bug" with simple example? 
I can see the black box next to "test" text, which is transparent, 
and I can see underlying window content.Resizing causes redraw, and 
corrects it. It still should not happen imo though ...

view [hpanel [text "test"]]

And he told me, that fields should not be long, or it does not look 
nice anyway.

 The problem is that you can't solve the maximum size restriction 
 issue of a nice-looking interface, by using a MAX-SIZE at the style 
 level. Such a problem would be at a higher layout level and much 
 easier for the UI designer to solve at the layout level. There is 
 simply no reason to have it.

yes, and R2 does the same btw... strange

and the index:

	unless pan [
		insert-panel-content/pos/no-show test-panels compose/only [
			pan: hpanel 1 (pick test-blocks index)
		] index
	]

aha, insert is probably not good, since it does not replace the previous 
content - well, the problem is, that change does not work for gobs 
yet, so you need to remove and insert, until change is corrected 
for gobs

btw - I expect that you guys surely know what you do, and so far 
my gui understanding is still minimal :-) But anyway - was there 
really a need to make make-panel internal? Except for the options 
block, I found it nice, that you can easily create panel from the 
stored layout block, just by one function ....

Then I found out, that their max size was set to 900 pixels. I asked 
Carl - why? And he told me, that fields should not be long, or it 
does not look nice anyway.

 - This is the main problem I have with VID and the "official" GUI 
 stuff. If I want it that way, I want it. I don't need a framework 
 that makes my life hard. There are zillions of things people want, 
 and others don't like. For commercial apps, we need to deliver what 
 the customer wants, not what we think is best.

And, to do this, all parts of the GUI must be accessible and able 
to describe. Hence, MIN-SIZE & MAX-SIZE make sense on a face level. 
If I need to specify it, at least I can.

Faced is awful. Content has the same meaning and is less jargony. 
Maybe it's better.

Hmm, so I did some tests, and here's my observation:


- I still have to complain, that in order to MAKE PANEL, I have to 
use function MAKE FACE, even if function of corresponding name exists, 
and was made useless for such purpose :-( Easy things SHOULD be easy 
to do


- The suggested code of pan: make-face 'hpanel [columns: 1] is self-explanatory, 
but then SWITCH-PANEL function does not work. And the possibilities 
are:
                     - this function is obsolete
                     - this function was not adapted to new stuff

                     - make-face does not create sufficient/expected output


The problem is in the following code - I have two panels - m = main, 
p = child:


view [m: hpanel [text "test"] options [init-size: 200x200] button 
"switch" do [switch-panel m p 'fly-right]] 

p: make-face 'hpanel [columns: 1]
insert-panel-content p [button "hello"]
view p ;- check it ....

It crashes on switch-panel, because:

>> p/gob/offset
== 571x384

>> margin: get-facet m 'margin
== [0x0 0x0]

>> p/gob/offset: get-facet m 'margin
** Script error: cannot set offset in path p/gob/offset:


So - does make-face create incompatible structure? Is 'switch-panel 
supposed to work? And if not, how do I support those fly effect for 
switching panels? Just don't push me to manually use insert-panel-content 
and tonnes of similar functions?

I would also like to understand your working plan - why are some 
usefull features removed at all? I can understand, that if things 
break, you set some priority to fix them, or not. But both make-panel 
and switch-panel just worked, whereas now they are replaced but tonnes 
maybe fine-grained functions = better flexibility, but also removing 
visual effects.


I still hope, that having switch-panel is possible, using new *-panel-content 
functions, and that transition effects are still possible ....

Once again - simple things should be simple to do, and simple even 
in my code - when I make-panel, I make panel, not a face. When I 
switch-panels, I just switch panels, so no need for user to care 
about panel content handling funcitons imo ....

it's possible that you have to use different methods than what Carl 
used. many functions were dismantled and rebuilt to support higher 
granularity and this process is not entirely complete yet. in the 
end, it should be just about as easy to build the demo using RM Asset's 
version as well as Carls, except for more solid behavior.

But both make-panel and switch-panel just worked, whereas now they 
are replaced but tonnes maybe fine-grained functions = better flexibility, 
but also removing visual effects.

 - are you not able to read? SWITCH-PANEL is not replaced by anything

Carl's comment after a "preliminary peek": "It seems that the design 
is going well, and this team is very REBOLish in their methods and 
concepts.  So, I am not worried."

Ladisla - thank, that was it. I mean - break-after fixed it.  With 
above - columns, to simply reproduce it, just view child, close the 
window, and call view child once again ... it breaks to console after 
a while with stack overflow. Well, now I know that 'columns is not 
used anymore, but you might try to look at it, if you have time, 
to see why it causes stack overflow ...

Could you try following code? You can eventually replace 'vpanel 
by 'hpanel [break-after: 1]. With vpanel, it just causes stack overflow, 
with hpanel, it kind of displays panel, but try to resize the window 
and see the mes ...


REBOL []

do %r3-gui.r3

lay: [

		when [load] do [print "Load trigger!"]
		clicker
		button "Do" alert "Button pressed!"

  button "Big Quit Button" maroon options [max-size: 2000x50] quit
		bar
		text "Toggle button..."
		t1: toggle "Toggle" of 'tog
		button "Set False" set 't1 false
		button "Set True"  set 't1 true
		toggle "Mirror" attach 't1
		toggle "Mutex" of 'tog
		bar
		text "Radios and check boxes"
		radio "Set above toggle on"  set 't1 true
		radio "Set above toggle off" set 't1 false
		bar
		check "Checkbox attached to above toggle" attach 't1


]

child: make-face 'vpanel []
set-panel-content child lay
view child

btw - maybe more direct question - where's defined spacing between 
the elements? I mean - I run Carl's demo next to RMA's demo, and 
I think that Carl's version got element spacing more pleasant. Where 
should I look to change it?

So, guys, is there any new revised release in the plan?
 - most probably next week
Or any explanations to my findings?

 - having trouble to reproduce some of your findings here, and some 
 problems are related to the parts Cyphre is working on

regarding your layout containing the WHEN and CLICKER elements, they 
look like still being incompatible with the current resizing

I even took the content out, to remove it from the demo dependency, 
and tried, I posted short script, and the space is still there ...

When i close window, and call my %test.r3 again, I get stack overflow 
we discussed earlier ... Dunno, why I did not get it running the 
first time ...

I think that the trouble is in make-face and how the panel is preconstructed 
.... because when I use the same layout submitted just to view, it 
works correctly ...

It does just the same here - first the dialog box with button is 
displayed ... I close it ... then I do the script again, and I get 
stack-overflow ...

It works. But it was not enough to just change the view-show.r3 code, 
and call it after do %r3-gui.r3, as the initial redirection will 
remain. A bit tricky, as there is no script to build new r3-gui.r3 
from sources, and sources are collapsed, but I managed it to change 
:-)

Aha ... and is there any list of "should work well" styles?

To get that, you need to try xy times. Most of the time I am holding 
down the bottom-right corner, moving randomly the mouse (I remember 
REBOL in the past did not receive updated info about about size, 
unless mouse button is released), and it accidentally can end like 
that. Dunno if any such info is helpfull ...

in R2 its pretty weird.   the event handler *accumulates* all resize 
events and then when you release the resize bar... it sends all of 
them to the handler in one stream.... just totally not at the right 
time  ;-)

but for some reason they are not being pushed to the handler.

 - is that the mezzanine level, or low level? If the fix is easy, 
 I am all for it. I just think that it might not be the priority. 
 The question is, if the resizing is not confused by receiving wrong 
 info, when holding the mouse button down, resizing here and there, 
 and then releasing it :-)

afaik, its within the port mechanism, when events are created, for 
some reason, the resize events don't end up at the port handler.


I remember trying to fix this in the host-kit and didn't find the 
solution.  I tried a few things but nothing worked... so I moved 
on but that's like 3 months ago already so the details are fuzzy 
in my mind.

Pekr, regarding your

lay: [

		when [load] do [print "Load trigger!"]
		clicker
		button "Do" alert "Button pressed!"

  button "Big Quit Button" maroon options [max-size: 2000x50] quit
		bar
		text "Toggle button..."
		t1: toggle "Toggle" of 'tog
		button "Set False" set 't1 false
		button "Set True"  set 't1 true
		toggle "Mirror" attach 't1
		toggle "Mutex" of 'tog
		bar
		text "Radios and check boxes"
		radio "Set above toggle on"  set 't1 true
		radio "Set above toggle off" set 't1 false
		bar
		check "Checkbox attached to above toggle" attach 't1


]

child: make-face 'vpanel []
set-panel-content child lay
view child


example - it is incorrect, since you try to give VIEW a HPANEL instead 
of a WINDOW, I suppose, that it was just a test, how it would look?

and if I don't specify backdrop? Aha, so window is not just anonymous 
parameter to make-face, but a regular style?

I initially thought only 'hpanel, 'vpanel is possible, and that it 
is only for panel :-) Well, now I am cool with make-face :-)

I simply don't regard instantiated style, being a face?

 - why not, if we "borrow" the class-based OOP terminology, then styles 
 may be considered analogies of classes, and faces may be considered 
 analogies of instances (objects) of their styles

I don't see why not. I think there would be plenty of advantages 
in allowing objects as face options. They are easier to build, store 
and configure than blocks.

If it's not against some security aspects, then I support Henrik, 
and such alternative could be added. You can decide priority for 
yourself, I am not pushing for it ...

As long as you can do at least the same with maps as with objects, 
then it's ok. I'm focusing on ease of building, storing and configuring 
potentially very large options for faces.

One thing is clear - it will not be complete port, e.g. fly-in/out 
effects are not supported when changing the panel content (switch-panel 
function is not adapted yet). Somy styles are also not adapted to 
the new GUI, and some are not adapted to the resizing model. I would 
welcome if RMA would do that basic work. E.g. even something like 
view [doc "text"] is guggy, and it displays the content twice, etc.

I encourage you (with the support of RMA) to do it , as far as it 
is possible, as this demo is well conceived, very "pedagogic", and 
auto-documented.

in the second example, we don't even need to use 'win, just "view 
panel", and the result is the same. I simply wonder, where's the 
problem. My suspicion is, that panel content functions are not compatible 
with the 'when style?

Pekr, currently, the LOAD trigger is triggered during the 'making 
of panel' and not when the content of the panel changes. But you 
can 'workaround ' that.

Also the content handling functions doesn't process the triggers 
correctly but we'll fix that part.
The questions are:

1. Should be LOAD triggered when whole content of panel changes? 
I'd say yes.

2. Should be LOAD triggered when part of the content of panel changes? 
I'm not sure here.

OK, leaving for a business trip, but one other question:


when I click toggle, it crashes. It seems to me, that the 'of reactor 
and namely exclude panel is not handled properly, but I will try 
later ...

Cyphre's "as usually" most probably means "on Friday", and I bet 
Cyphre will put a note to the announcement group when the update 
will be available.

How is now R2's face/pane, and earlier face/faces replaced? I can't 
see it in the structure. Is that a gob!?

>> help main-pan
MAIN-PAN is an object of value:
   style           word!     vpanel

   facets          object!   [init-size min-size max-size align valign 
   res...
   state           object!   [mode over value]
   gob             gob!      offset: 3x46 size: 572x503
   options         object!   [content]
   tags            map!      make map! [ panel true ]
   draw-result     block!    length: 45
   intern          none!     none
   name            word!     main-pan
   names           object!   [t1]


I really miss the simple aproach of R2 guys. I wish I had a /pane, 
a simple block of stored subelements, accessible via normal rebol 
series functions, so no need for me to investigate the special purpose 
functions. That's what I call simplicity.

I would also like to report, that R3 is highly unstable, when playing 
with panels, and trying to set their content, e.g. manually to some 
slots (I tried doing directly main-pan/content: lay, main-pan/facets: 
lay, main-pan/facets/content: lay, main-pan/gob/pane: lay), to simply 
obey insert-pane-content function. It does not take much time for 
R3 to crash, and now I mean hard-crash - exiting the R3. No matter 
what nonsense I am trying to do, it should not crash R3 imo ....

Pekr, can't you post the whole script somewhere on the net so I can 
download and see what it does?

:-) I don't know if I will have time for that. Still at Aminostar, 
today 3 hours I will write a project doc, tomorrow ditto Aminostar, 
and I should leave for Prague in teh evening. So - if I would be 
supposed to visit Liberec, it would be sometimes after the luch, 
having some 1-2 hours at max ....

As Cyphre explained one concept to me, and because I have some questions, 
I post it publicly, so that others might benefit from the info. I 
was not properly understanding the structure of the panel. Cyphre 
was kind of surprised why do I need to know it, and that I might 
not eventually need it for the layout work, but the truth is, that 
I would like to understand system internals.


In R2, the structure of the face was mostly the same IIRC. And you 
put your elements into face/pane. I found out, that structure of 
face might be different for various styles. I hope I am not wrong. 
And in such a case, I suggest to document particular style fields, 
so that one does know, what does it serve for. That might be really 
good for programmers ...

I was particularly interested to know, what is the difference between 
- style/facets/names and style/names

style/facets/names is a logic value, which you can set to true, and 
it is usefull for compound styles. Sub-faces referenced by name is 
then style local, and does not leak to globals, does not get rewritten 
by new instance of the style ....

Now I have following points to think about:


1) in REBOL we often don't user conventional naming, but if we would 
use it, then probably 'locals? would be a better name?
2) it is a logic value, why 'names, and not 'names? ?

3) for the instance locals, we use name 'intern during the style 
creation, so why not 'intern?

4) I was really so used to the 'pane (or container in other environments), 
that so far I don't like 'content, and I don't like referring to 
the name referenced faces by style/names/a. So, if my understanding 
is correct, and /content just stores the dialect (not reduced?), 
then why not:

face/intern?: true
face/pane/a, face/pane/b
face/facets/layout?


The thing is, that it is still difficult for me to understand the 
role of a gob! Because gob has a pane, and the concept of gob, multiple 
gobs, and faces organising gobs, made the concept messy in my head 
:-(

what is actually being stored in panel/gob? And what is panel/draw-result? 
And is face/facets/content just a layout dialect stored, or already 
reduced?

I don't need to care about some stuff I can understand, so - I will 
investigate further anyway, just for the sake of better understanding, 
and .... because it is fun :-)

That gob structure does not comply with faces. I need to see some 
drawing, or it is a mess, which noone will ever understand. And I 
assure you, that programmers will require to understand that ...

what is the difference for e.g. between panel/gob, and panel/facets/gob?

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

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.

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.

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.

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.

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

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.