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

World: r3wp

[!REBOL3 GUI]

Pekr
12-Feb-2011
[5917x2]
I am looking for the GUI for massess, not for academic stuff ...
Any hints how the material system work? How do I "destylize" panel 
for e.g.? Let's say I want panel functionality, but without the visuals 
(if I enclose everything in panel, there's too many borders and gradients 
around, and I would like to have more relaxed design). Let's say 
I would like to create derived style, called panel-, panel-less, 
pure-panel, whatever. I can see following draw code:

draw: [
			plain: []
			gradient: [
				clip margin-box/top-left margin-box/bottom-right
				pen none
				line-width 0
				grad-pen linear 1x1 0 gob-size/y 90 area-fill
				box (margin-box/top-left + 1) (margin-box/bottom-right - 1) 1
			]
		] 

And following on-make code:

			on-make: [
				make-material face get-facet face 'material
				set-material face 'up
				all [
					get-facet face 'area-fill
					set-facet face 'draw-mode 'gradient
				]
				make-panel face 'panel
			] 

What I am supposed to do, to change the disign?
Henrik
12-Feb-2011
[5919x2]
When this is created properly, the basic panel should have no visible 
frame.
Then other styles would derive from it and add the necessary frame.
Pekr
12-Feb-2011
[5921x4]
yes, but what's the usage case?
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 ....
hmm, progressing slowly, but at least something:


>> view [p: hpanel [button do [print mold get-facet p 'materials]]]
make object! [

    up: [0.0.0.200 0.0 0.0.0.255 0.5 255.255.255.255 0.5 255.255.255.220 
    1.0]

    down: [0.0.0.200 0.0 0.0.0.255 0.5 255.255.255.255 0.5 255.255.255.220 
    1.0]

    over: [0.0.0.200 0.0 0.0.0.255 0.5 255.255.255.255 0.5 255.255.255.220 
    1.0]
]

== make gob! [offset: 566x379 size: 148x42 alpha: 0 text: "REBOL: 
untitled"]


>> view [p: hpanel [button do [print mold get-facet p 'material]]]
container-groove

== make gob! [offset: 566x379 size: 148x42 alpha: 0 text: "REBOL: 
untitled"]
Why does following does not work? I try to set the panel to the 'plain 
mode, but calling 'show crashes the code:


>> view [p: hpanel 200x200 [button do [set-facet p 'draw-mode 'plain 
show p]]]


So - how do I refresh/redraw the panel? Should I somehow call the 
'on-update actor?
Henrik
12-Feb-2011
[5925]
does the panel style have a draw-mode 'plain?
Pekr
12-Feb-2011
[5926x2]
yes, an empty block :-)
What is the correct way to call an actor? do-style face 'on-update?
Henrik
12-Feb-2011
[5928]
shouldn't it have an argument?
Pekr
12-Feb-2011
[5929]
how can I recognise, what arguments particular actors should obtain, 
if not in the comments? :-)
Henrik
12-Feb-2011
[5930]
I believe that is a problem that is yet to be solved.
Pekr
13-Feb-2011
[5931x4]
How can I properly attach scroller to progress bar? Following code 
shows scroller at 100% value. Scroller accepts some initial size 
parameter, but not sure how to utilise it either ....

view [prog: progress sbar: scroller attach 'prog]
Why text utilising rich-text does not work either?
'drawing style has not effect too:  view [drawing [pen black circle 
50x50 30]]
I really wonder, if R3 GUI sees ANY regular development? ;-) Half 
the styles don't work or don't work as expected :-) Recent R3 GUI 
status is, that it is not usable for more than simple dialog box 
:-) I hope that we can see some quick fixes? :-)
Henrik
13-Feb-2011
[5935]
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.
Pekr
13-Feb-2011
[5936]
I know Henrik - but I thought that there is someone actually working 
on styles? Possible Bolek? I was about to "port" rewrite demo, not 
to redo styles (which is beyond my capabilities :-) Most of things 
I mention here are obvious by very simple examples, so I wonder if 
someone tested them, or what is the "action plan" towards the GUI 
progress?
Henrik
13-Feb-2011
[5937x2]
Bolek is working full time on styles, particularly tables.
The plan is to do styles on priority with needs with the SCRUM tool, 
that's why tables are being worked on right now. Also continual design 
reviews are necessary to make sure we won't run into design dead-ends. 
That's why there may be regressions.
Pekr
13-Feb-2011
[5939]
tables - nice, and good to know ...
Robert
13-Feb-2011
[5940x2]
Petr, as said hunndred times... we are first drilling deep to get 
the concepts right. Than we are boing broad by priority. This means: 
Focus on few (2-3) styles
Everything that is eye-candy has no priority at the moment. This 
includes: Material system, rich-text, DRAW effects etc.
jocko
13-Feb-2011
[5942]
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 !
Robert
13-Feb-2011
[5943x3]
It's available, take it and help us to port more styles. Again, this 
was said several times. If you don't want to, than you have to wait.
We are not going to change our strategy, in this we are very stable 
and predictable.
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.
Pekr
13-Feb-2011
[5946]
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 
...
Rebolek
14-Feb-2011
[5947]
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 ;)
Pekr
14-Feb-2011
[5948]
- 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?
Henrik
14-Feb-2011
[5949]
actor arguments would need to be formalized to allow them to be documented.
Rebolek
14-Feb-2011
[5950]
DO-FACE ... "Evaluates the reactors (result actions) for a specific 
face.". So no, it's not a relict, it does just what it says.
Henrik
14-Feb-2011
[5951]
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.
Rebolek
14-Feb-2011
[5952]
Yes Henrik, but manual attachment using ATTACH reactor should be 
allowed.
Pekr
14-Feb-2011
[5953]
You still don't understand - I am not interested in ideological reasons 
of why someone thinks something should not be allowed. Because - 
next person will think, that it should be allowed :-) I don't need 
to use scroller, I would be fine with slider. But - does it make 
any difference? Attaching something the way it was designed was not 
imo all that bad idea. Please don't remove features for no apparent 
reasons :-)
Henrik
14-Feb-2011
[5954x2]
ah, yes, ok.
Pekr, the reasons for why things should or should not be allowed 
is not for ideological reasons, but results of many hours wasted 
on trying to make such attachment code work and failed.
Pekr
14-Feb-2011
[5956]
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 ...
Rebolek
14-Feb-2011
[5957]
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.
Henrik
14-Feb-2011
[5958]
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.
Pekr
14-Feb-2011
[5959x2]
Rebolek - I don't know if it works. I might work. The "trouble" is, 
that scroller itself displays itself with 100% knob size. So there 
is nothing to scroll :-) How do I cause the scroller to have smaller 
initial knob size?
nothing to scroll
 = nowhere to scroll
Rebolek
14-Feb-2011
[5961]
Ah, I see. Then use this:


view [prog: progress sbar: scroller options [delta: 10%] attach 'prog] 
; DELTA will set knob size.
Henrik
14-Feb-2011
[5962]
Does SLIDER not work?
Rebolek
14-Feb-2011
[5963x2]
Yes
(yes, it does work)
Henrik
14-Feb-2011
[5965]
Then it would be a much better idea for Pekr to use SLIDER.
Rebolek
14-Feb-2011
[5966]
Yes, replacing SCROLLER with SLIDER works well and is better in this 
case.