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

World: r3wp

[!REBOL3 GUI]

Pekr
26-Jan-2011
[5559x2]
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 ...
Henrik
26-Jan-2011
[5577]
(This could be a third party project?)
Kaj
26-Jan-2011
[5578]
Hah!
Pekr
26-Jan-2011
[5579]
Kaj - hah to what? :-)
Rebolek
26-Jan-2011
[5580]
I think that basic DOC style can be really simple and that it just 
will parse makedoc format to R3GUI layout.
Pekr
26-Jan-2011
[5581]
So - I should forget Doc, right? Because I wanted to find the reason 
for it to doubling the content, so I wanted to fix it. If it is going 
to be removed, that would be waste of time ...
Kaj
26-Jan-2011
[5582]
Hah to defining large subprojects and expecting someone else to do 
them
Pekr
26-Jan-2011
[5583]
I prefer to start with small things :-)
Kaj
26-Jan-2011
[5584]
Wise
Henrik
26-Jan-2011
[5585]
why would it be large?
Rebolek
26-Jan-2011
[5586]
Pekr yes.
Pekr
26-Jan-2011
[5587]
Henrik - there's no why imo yet :-) From my POV it is very preliminary, 
and I would orientiate myself to:

- adapting existing styles to new R3 GUI engine

- adding styles most commercial guis will need - table, tree, tabs

- be sure all styles behave in a platform compatible way (especially 
area)
- reskinning/respacing the elements

- add support for ctrl-tab at low level to switch between the tabs
- fix all hard R3 crashes

later:

- add support for accelerator keys, but visually, and in the code 
(requires rich-text, most probably autogenerated, to underline the 
letter, but it could be done a different way to - e.g. displaying 
boxes with accelerator keys upon the styles and Alt key press)

- improve the text quality, that is NOT ACCEPTABLE for the 21st century!

even later:

- add some funky styles as Doc to make documentations, wikis, etc. 
:-)
- HW acceleration support where possible.
Kaj
26-Jan-2011
[5588]
A system that you let someone else write is never large. Yet I would 
say a documentation system is a large task
Ladislav
26-Jan-2011
[5589]
I just have to make my notes to the "button size" thread:


- "We can't easily make 50x50 button for e.g.?" - you can, just respect 
the fact, that every face has got a Max-size, and if you want to 
make something bigger, you need to specify the Max-size

- "you have init-size as an option, yet it is ignored,or totally 
twisted" - it is a resizing rule, that you can resize everything 
only to the Max-size limit; of course, you can make the Max-size 
bigger, but, if you forget, nobody can be cleverer than you are knowing, 
what is the Max-size you want to use

- '   view [button "ok" options [max-size: 200x200]]' - of course 
it works, allowing you to resize the button as specified

- '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.' - only over my dead body, the basic resizing rule is 
to respect the Max-size
Pekr
26-Jan-2011
[5590]
only over my dead body

 - that should not be a problem, we meet today personally, no? :-))) 
 ... just a joke :-)
Ladislav
26-Jan-2011
[5591]
LOOL
Pekr
26-Jan-2011
[5592]
Ladislav - maybe what Rebol thought about was to actually exposing 
max-size in an options block? Is that possible?
Ladislav
26-Jan-2011
[5593]
Rebolek has shown you how, even your code would allow you to resize 
the button
Pekr
26-Jan-2011
[5594]
Now there is init-size, and my opinion is, that it is confusing, 
if the init-size is possible, yet it does nothing obvious. In such 
a case, I prefer to error-out at layout level, not allowing even 
init-size being specified inline ...
Henrik
26-Jan-2011
[5595]
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.
Cyphre
26-Jan-2011
[5596]
Bolek, I don't understad what 'bug' you found in button??? The init-size 
in options is OK
Ladislav
26-Jan-2011
[5597]
That is the basic resizing rule - no error, just resize respecting 
the Max-size. The resizing algorithm shall not be cleverer than you 
are, changing the Max-size sometimes, reading your mind.
Cyphre
26-Jan-2011
[5598x2]
It is correct that you can't do button 50x50 because the button definition 
is:
	facets: [
		init-size: 130x24
		max-size: 230x24
		min-size: 80x24
		....
	]
So as Bolek said..either make own 'fat-button' style or change the 
size related facets inline in your layout definiton.
Pekr
26-Jan-2011
[5600]
init-size should be removed from the options, if it does nothing 
usefull imo ...
Ladislav
26-Jan-2011
[5601]
??? - it says, how you want to resize the face when shown for the 
first time
Cyphre
26-Jan-2011
[5602]
without init-size in the options definition you won't be able to 
set the size like: button XxY
Ladislav
26-Jan-2011
[5603x2]
That is *very* useful
On the other hand, Max-size says, what the resizing limits are.
Pekr
26-Jan-2011
[5605]
Now I don't understand - what is it good for having button 100x100 
allowed to be specified inline, if the resizing does not allow me 
to have what I (user) expect? That should be precisely documented, 
or not allowed at all?
Ladislav
26-Jan-2011
[5606]
That is the property of resizing - you can resize, but resizing *always* 
respects Max-size
Cyphre
26-Jan-2011
[5607x2]
you can still specify any pair!  value in the defined resizing limits 
no?
also another possibility is to change also the max-size if user forces 
to change the size using the inline pair!