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

World: r3wp

[!REBOL3 GUI]

Pekr
26-Jan-2011
[5527x3]
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.
BrianH
26-Jan-2011
[5530]
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.
Pekr
26-Jan-2011
[5531x2]
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.
Rebolek
26-Jan-2011
[5533x2]
Pekr, if you want ridiculously obese button, just override max-size.
You shouldn't have to do it, but you can.
Pekr
26-Jan-2011
[5535x5]
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 ....
You are depreciating the fact, that even business apps might have 
changed. With touch interfaces, many things are different. One-sized 
buttons are old-school.
I thought about the possibility of VID aproach - having button, and 
btn style, one of them could resize. But my experience is, that those 
two did not mix well together, mainly because the visual difference. 
 And if I adapt the resizable one to look the same as non-resizable 
one, I don't need the latter ...
Rebolek
26-Jan-2011
[5540x2]
Nothing in R3GUI is one sized. There is max-size (and min-size) limit 
and we can debate if the max-size is big enough or not, but you cannot 
say that big red button is not possible in R3GUI, because that's 
simply not true.
Just changing max-size is not enough, that limits maximum size when 
resizing. What you want is this:


view [button "big" options [init-size: 100x100 max-size: 100x100]]
Pekr
26-Jan-2011
[5542x5]
aha, that is another thing to understand. When I looked into button 
source, I found there 'options. I thought that those options describe, 
what parameters I can set inlined. And it may be correct. But - now 
we have layout level word 'options, which is completly different 
thing :-(
From the following code - what is in the 'options block, can be inlined 
in the layout, right? But basically using 'options in a layout means, 
you can set any 'facets?

	facets: [
		init-size: 130x24
		text-body: "Button"
		text-style: 'button
		max-size: 230x24
		min-size: 80x24
	]

	options: [
		text-body: [string! block!]
		area-color: [tuple!]
		init-size: [pair!]
		wide: [percent!]
	]
If so, that is a discrepancy in the naming then, sadly.
To have it aligned, we would have to have:

view [button "big" facets [init-size: 100x100 max-size: 100x100]]

Or just reverse the meaning in the style:

options: [
		init-size: 130x24
		text-body: "Button"
		text-style: 'button
		max-size: 230x24
		min-size: 80x24
]

facets: [
		text-body: [string! block!]
		area-color: [tuple!]
		init-size: [pair!]
		wide: [percent!]
]


Simply calling style attributes 'options, and inlined settable parameters 
calling 'facets ....
Or am I missing something here?
Rebolek
26-Jan-2011
[5547]
discrepancy in the naming

 - you're right, most of the names are from old R3GUI and may not 
 be descriptive enough. I hope we can change it with your help. OPTIONS 
 in layout is used to override FACETS which may seem confusing.
Pekr
26-Jan-2011
[5548x2]
exactly. But the tricky part is as follows - I like having 'options 
in the dialect level, and I am kind of used to have to call style 
attributes a 'facets ..... I would have to think for a while, if 
we can accept following convetions:


- options - used to set style properties, either in the style itself, 
or in the layout dialect

- facets - special purpose properties, which can be used inline in 
the layout level


I think that it would work for me, and that we would have it aligned 
nicely that way. I am just not sure Carl or other guys are ready 
to give-up on facets name being a general attribute/property of the 
style :-)
My opinion is, that 'options as a term is more accessible to the 
ppl, than facets, so I would go for the change ...
Henrik
26-Jan-2011
[5550]
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.


Henrik - I believe you will fail explain technical reason, why it 
prevents proper skinning


An exact failure in understanding why face hacking is not welcome. 
Gab's GUI was not easy due to a number of layers needed to describe 
the look and feel separately, as well as requiring you to handle 
GOBs manually. But it supported applying proper meaning of styles, 
because Gabriele had the same goal as me. Carls does too and RM Asset's 
does this even more. We just have to take advantage of it.


Have you never had to fix someone's MS Word document, so that TOC 
generation, links, indexes, headlines, etc. could be understood by 
Word, because they had resorted to manipulating the words directly 
with colors and style, instead of using Word's style system? This 
is exactly the same problem. You will be teaching beginners that 
their layouts won't scale properly for exactly the same reasons. 
Many people therefore never really learn to create correctly formatted 
Word documents.
Pekr
26-Jan-2011
[5551]
Henrik - what is the difference in not not providing option to set 
a button size, yet like Rebolek showed us, it can be done in the 
options block? I mean - what is the difference for the skinning system? 
And also - button is a rather promitive widget, we don't allow its 
sizing, yet more complex styles as panels can be sized, skinned most 
probably too?
Henrik
26-Jan-2011
[5552]
The difference is applying meaning at the correct level, the layout, 
dimensions, colors, skin information at the style level, where it 
belongs.
Pekr
26-Jan-2011
[5553x2]
I don't want to hack styles in the R2 way, going style/path way. 
I can see, that those layers are wisely designed, but not allowing 
any size button is imo oversight, and it does not imo break the rules 
you describe in your MS Word TOC example. User is simply not hacking 
it. All I wanted was to "export" max-size, not the init-size.
need to check-out from the hotel, later ...
Rebolek
26-Jan-2011
[5555]
The right way to do big button is to use stylize and make your own 
big button. You definitely not want to go thru your code at some 
later date and change all 100x100 to 200x200 for example.
Henrik
26-Jan-2011
[5556]
using stylize must be as effortless as possible, though. :-)
Rebolek
26-Jan-2011
[5557]
That's right. But I think it can hardly be much easier than it's 
right now:


>> stylize [big-button: button [facets: [init-size: 100x100 max-size: 
100x100]]]
>> view [big-button "BIG"]
Pekr
26-Jan-2011
[5558x3]
that's rather easy, but not easy enough. Still a different concept. 
You guys act like button is a text, and it is not :-) If I will have 
whole screen of the same buttons, I might use stylize, e.g. for the 
calculator widget, as an example, becuase constantly repeat button 
30x30 is not convenient for me. But it still does not mean, that 
ocassionally wanting to have button a bit differently sized does 
a damage. Do you think users are crazy and will make each button 
differently sized, just because they can? :-) (Well, as for MS Word 
files, some users are able to create completly twisted texts, bu 
still - that is a text, difficult to restyle ... while we are talking 
GUI here.
Now if I would think about comparing R3 GUI to html/css, then I am 
not able to compare it in my head, but doesn't inline CSS allow to 
override class setting?
Rebolek - I agree, there's hardly any way of how to further simplify 
'stylize :-)
Rebolek
26-Jan-2011
[5561]
Ocassionaly having bit differently sized button sounds like inconsitent 
UI to me.
Henrik
26-Jan-2011
[5562]
Yes, CSS allows this using STYLE, and it gets painful, when you start 
doing that, riddling HTML with CSS code. The reasons are the same 
here by avoiding to apply proper meaning to the HTML code, when using 
STYLE.
Rebolek
26-Jan-2011
[5563]
So, I had a look at BUTTON source and button has init-size in options, 
so this is bug and [button "BIG" 100x100] should work. I will fix 
it.
Pekr
26-Jan-2011
[5564]
I am talking about apps like - http://www.ab-x.cz/gallery/tch1.jpg
, http://www.vseobal.cz/pic/S5kasa2.jpg
Henrik
26-Jan-2011
[5565]
That looks more like a job for the resize engine than the button 
itself.
Pekr
26-Jan-2011
[5566x3]
Rebolek, thanks for confirming it is a bug :-)
REBOL - maybe a simple bug, did not investigate it yet, but you might 
missed my report, as there is lot of a chatter here lately:

 view [doc "test"]

- doubles the content ...
REBOL = Rebolek, damn :-)
Rebolek
26-Jan-2011
[5569]
DOC works? I'm very surprised, this style should be removed, I think.
Oldes
26-Jan-2011
[5570]
Henrik, I don't think Cash screens resizes;-)
Pekr
26-Jan-2011
[5571]
So simple Doc style displaying make-doc format is not going to be 
there?
Henrik
26-Jan-2011
[5572]
Oldes, for layout, span, etc. This is covered by the resizing engine.
Rebolek
26-Jan-2011
[5573]
No, it's going to be there, but it won't be this current DOC style 
(which is some strange format anyway).
Pekr
26-Jan-2011
[5574]
Also - one question to the text style - in Carl's GUI (at least that 
is my undersanding from the demo) it accepted the block of rich-text 
dialect? That is not so with R3 GUI, probably an intention?
Henrik
26-Jan-2011
[5575]
I would like that the finished doc style supports images, tables 
and enough features to allow direct rendering of MakeDoc documents. 
This should simplify creating a documentation system, where we don't 
need to rely on browsers, when using browser-less platforms.
Pekr
26-Jan-2011
[5576]
aha, so more complex issue ... I will remove it from the demo then, 
replacing it by some simple text style ...