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

World: r3wp

[!REBOL3 GUI]

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.
Pekr
14-Feb-2011
[5967x2]
Rebolek - then there might be a difference to init knob size. I know 
it should be recalculated to the amount of data, but maybe by default 
it could be the minimal size, instead of 100%?
Usually when you work with IDEs, you are able to choose scroller, 
and the know size is at the minimal position, not at the maximal 
one, imo ...
Rebolek
14-Feb-2011
[5969]
Yes, that may be changed. OTOH, scroller's main  purpose is to scroll 
an inner area, while you want to set value, which is slider's purpose.
Pekr
14-Feb-2011
[5970]
Slider is just scroller without arrows, no? :-)
Henrik
14-Feb-2011
[5971]
Nope, slider is a value adjustment tool. It doesn't need knob size 
management.
Pekr
14-Feb-2011
[5972x2]
Ah, visually different. IIRC we had used "scroller without arrows" 
for such purposes in the past?
I'll change the demo then ....
Henrik
14-Feb-2011
[5974]
We did, because VID provided such features in its usual extremely 
bare-bones style. :-)
Pekr
14-Feb-2011
[5975x2]
What is the situation with compound styles? When you e.g. design 
scroller - is it a mixture of two styles? Slider (in old gui sense) 
+ arrows? I mean - if we have arrow style, and you will use the arrow 
in some compound style, then when you change/restyle arrow, will 
it change also inside of compound style?
Or are arrows "hardcoded" in scroller style?
Rebolek
14-Feb-2011
[5977]
SCROLLER is not compound style and arrows are "hardcoded".
Pekr
14-Feb-2011
[5978]
So what is an example of "compound" style? E.g. table?
Henrik
14-Feb-2011
[5979]
text area + scroller
Rebolek
14-Feb-2011
[5980]
Can SCROLLER be compound style? - Yes, it can.
Pekr
14-Feb-2011
[5981x2]
Rebolek - your above example of setting the delta to 10% does not 
work. It displays something, but the know is 100% sized anyway ...
I can confirm from demo:

radio "Delta 50%"  set 'sbar 'delta 50% ; does not work
button "Set 50%"   set 'sbar 50% ; does work
Rebolek
14-Feb-2011
[5983]
Pekr, maybe it requires some fixes that weren't released yet.
Pekr
14-Feb-2011
[5984]
What is the 'state object? I can see there is knob-size set to 100%. 
What is the purpose of this slot? I thought that parameters are stored 
in facets?
Rebolek
14-Feb-2011
[5985x2]
Well, the STATE object is for internal parameters that shouldn't 
be changed by user... We got rid of FACED already, as it was only 
causing confusion and wasn't solving anything. STATE will probably 
stay, but various words may be rearranged and moved between STATE 
and FACETS.

My secret plan is that SET(GET)-FACET should one day probably work 
as SET(GET)-FACE/FIELD but currently there's only one style that 
supports fields, so this will take time.
I think the original idea was that user should always use SET(GET)-FACET 
for accessing values and should pretend that FACE/STATE/... is impossible 
to do, so STATE would stay internal and inaccessible.
Pekr
14-Feb-2011
[5987x3]
For better understanding of material system. I can see code like 
this:

		material: 'scroller

		area-color: 200.233.245
		edge-color: 0.0.0.128
		arrow-color: black

		area-fill: 
		over-fill: sky
		down-fill: coal 

And late in the on-make, this:

			; Prepare materials
			make-material face get-facet face 'material
			set-material face 'up 

Questions:


1) why are those  facets being set? Is it just that you need to give 
them some initial value? Is my understanding correct, that during 
on-make, those values are being overriden? Most probably not, because 
materials field hold up/down/over values.


2) is material system sufficient, if it holds only gradients? It 
should imo hold all values, which might influence the design of the 
widget. And hence even bare-bones colors. The question also is, if 
draw-blocks shold not be part of the material system too, because 
my impression is, that so far, it does very little to be any usefull, 
and the difficulcy to understand the whole concept might not be worth 
the effort.


3) There is an architecture discrepancy - materials do use central 
storage (kind like old VID kept 'feel actions block together - nice 
idea, but really not any usefull, and VID2 design mistake imo), while 
draw blocks are contained per style definition. I think it might 
be wise to think about moving materials: [up [] down [] over[] ] 
slots to the style definition itself
Rebolek - I hope you know what you are talking about :-) FACED was 
usefull - it was local instance copy of the value, not the shared 
one. FACETS then kept the values shared. RMA changed the design, 
so that FACETS are now instance local, which of course might lead 
to the increased memory consumption (that would have to be proven 
though). RMA introduced INTERN slot for holding instance local values, 
but from what I saw, that is not used that much yet ...
What I really start to miss is high level design docs. I simply don't 
necessarily agree to some of architecture design decisions. I know 
that last thing you want to do is to create docs, but I am starting 
to think I'll produce some CC tickets for that ...
Rebolek
14-Feb-2011
[5990]
I have yet to see a single case where FACED is useful to change my 
mind about that decission.
Pekr
14-Feb-2011
[5991x2]
FACED is not usefull anymore, as you reversed the design. Once gain 
- Carl's gui: FACED = instance local, FACETS = shared. RMA's GUI 
- FACETS = instance local, FACED = dismissed, INTERN =  instance 
local. So if you question usefullness of FACED, then you are also 
imo questioning usefullness of INTERN. I must miss something then, 
or you did not understand, what was FACED supposed to do in Carl's 
GUI?
My secret plan is that SET(GET)-FACET should one day probably work 
as SET(GET)-FACE/FIELD but currently there's only one style that 
supports fields, so this will take time.
 - Sadly I have no idea what you are talking about here. 

GET-FACET FACE 'SIZE
vs
GET-FACE 'SIZE????
Rebolek
14-Feb-2011
[5993x2]
FIELDS are probably not part of the latest public release. Currently, 
[set-facet face 'size 10x10] is basically the same as [face/facets/size: 
10x10]. With fields you can have some code that will check the value 
for right datatype, boundaries, etc.
Carl's gui: FACED = instance local, FACETS = shared.

 - I know, but what is it good for? In the end everything will end 
 in face's facets anyway. Neither me nor Cyphre saw a single reason 
 to leave it, if you have some user case, then please, enlighten us, 
 because for us, FACED is only problem-maker.
Pekr
14-Feb-2011
[5995]
So why have you introduced INTERN? INTERN is the replacement for 
FACED :-)