AltME groups: search

and, you got me, it currently does not have a docstring (maybe it 
is too low-level, but I will definitely write something)

Personally, I think that ANCESTORS, PARENT, CHILDREN  and DESCENDANTS 
are very useful words for precisely defining relative positions in 
a heirarchy.


They do not seem to sit well with the REBOL though as firstly they 
are comparative long (and many rebollers appear to worry about having 
to type one or two extra characters) and secondly they don't really 
fit in with the existing VIEW/VID/REBOL3 GUI metaphors (which are 
more facial - FACE, GOB etc.)

Pekr, one thing you can check for me: Run all-styles.r3 and look 
at the FIELD style: When swiping (holding down the left button and 
dragging from left to right to mark up text) very slowly, start at 
the left 'F', the text is marked up ok, until reaching the last letter. 
Then the marking disappears momentarily and comes back when passing 
by the last letter. Can you replicate this?

Henrik, other than that, marking the text is really buggy. Here's 
few things RMA needs to look into:


- go to the area, type enough text, sot  that it scrolls, and then:

        - when you are at the bottom of the area, just press shift + up arrow, 
        to hilite the text - only one line is hilited -  the alghoritm is 
        buggy

        - go to the top. Try the reverse - shift + down arrow - it hilites 
        the text correctly, unless you hit bottom, then it starts to hilite 
        from the beginning, and cycles forever. It should just stop at the 
        bottom


- the most troublesome behaviour though is, that when you move out 
from the bounds of the style, it stops hilighting. Simply an event 
flow is bad here. We should treat it like pop-up menus - receiving 
events even if outside of the window, while in mouse-down mode. That 
is absolutly needed, or the experience is highly uncomfortable - 
just try to hilite the field - once your mose goes away, it stops 
the hilite. That might be the reason why you think it is slow ...

'will it be "backported" (?) into RT's branch of source code?' - 
As was announced, the RT's branch of source code is currently managed 
by RMA, and ported to keep being compatible with the new hostkit 
updates. What exactly is "backport"?

yes, merged, sorry. Simply put that when Carl reappears, and starts 
eventually to proceed with RT's releases, to not find ourselve in 
a situation, when Carl uses old and different hostkit View sources 
...

User poll questions:


1) Do you find the 'a layout' and 'layout style' notions to improve 
the current 'a panel' ambiguous terminogy, or do you prefer something 
else?

2) Which of the three [[hpanel vpanel] [panel vpanel] [panel panel 
vertical]] alternatives do you prefer?

2-2 - comment - if we stay with align valign, then let's go panel 
vpanel, group vgroup. I think that vertical option will not be used 
so often, and so the code will be nicely readable with just panel, 
group?

1st choice: [panel vpanel] for the compatibility with the existing 
official doc, and for the compactness
2nd choice: [hpanel vpanel]

and closeness to natural language

The wording of the http://www.rebol.net/wiki/R3_GUI_terminologyarticle 
corrected and enhanced.

Maybe we're just tired of user polls, or we don't have the time to 
dig into this. If you don't have a clear view of what a good GUI 
should be, and therefore need polls, then maybe use some time to 
get a clear view. Only suggestions. :-)


I looked into it quickly, and I would at this point go for just have 
panel, letting vertical be a layout-mode option. Reason: K.I.S.S. 
(and vertical is an option anyway). And if you support user-defined 
styles (I'm not sure, you do, as I'm not very much into R3 GUI), 
then programmers can just make their own vpanels, if they need it. 
If I, as new to some GUI, can get it up and running in a very short 
time, because it's so simple, that's a huge benefit.

If you don't have a clear view of what a good GUI should be, and 
therefore need polls, then maybe use some time to get a clear view
 - interesting point, should make a note

Aha, I did not notice the smilie at the and :-)

I guess, it's extremely hard to create a really good and preferable 
GUI. I'm struggling with Cocoa and Interface Builder on Mac OS X 
atm., and I haven't seen any glimpse of a 'perfect' GUI in that yet. 
If I was to design a GUI, I would go for simpleness, and still make 
sure, advanced users can make the advanced things.

Suggestion: If you have user-defined styles, then why not just go 
with a very basic set of styles to begin with, like only panel, group, 
etc. And then you could make an advanced version of the GUI (by including 
some script with styles), where you give users vpanel, vgroup, etc.

Result will be, new users don't read very much documentation and 
can start using the GUI very quickly. If you wanna do more advanced 
things, read the advanced docs, include the extra script and there 
you go.

That is possible, actually, having just the panel style, it is trivial 
to derive a vpanel style from it, since you have to only set the 
LAYOUT-MODE to 'VERTICAL, and that is all.

And that's a problem with polls, you get many opinions. Better to 
set a strategy, define some good basic rules and make the thing without 
asking anybody. Keep K.I.S.S. in mind, as that's the most often (but 
yet very basic) rule broken.

And, it becomes a problem with existing code, since nobody wants 
to rewrite all the code he is using.

So make a cup of green tea, sit in lotus position, close your eyes 
and think. After a while, you might see it clearly and don't have 
to poll. ;-)

As far as I am concerned, I "see it clearly", but I do know, that 
if I wrote it that way, you would come and say: "my dog prefers the 
other alternative".

Interesting - I really don't know, if it is a problem or even confusing, 
when docs talk panels in general, and panel as a style. How often 
do you need to refer to the panel style in your text? And if so, 
you can always use "panel style".

For example,(this is not much a documentation issue, it is a coding 
issue, in fact): There is an INSERT-PANEL-CONTENT function. The function 
is supposed to insert contents to any layout face, i.e. the name 
is inadequate, in fact, and it should preferably be renamed to INSERT-LAYOUT-CONTENT 
(or INSERT-LAYOUT-CONTENTS, respecting the results of some of the 
previous polls).

I am probably OK to stay with the panel name of the style, panel 
name in supporting functions, and still referring to it as a panel. 
I simply regard panel style being one of possible implementations 
of the panel layout concept  :-)

We should also admit, especially as proposed by Henrik and Gab in 
the past, that maybe, many users will create descendants, calling 
them my-panel, my-red-border-panel, whatever. Then I can imagine 
some docs:


My pink-big-panel panel, is a special purpose panel, designed for 
my girlfriend :-) It differs from default PANEL STYLE in having red 
and pinky design ....

INSERT-LAYOUT-CONTENTS actually is OOP style, since:

- you don't specify the style, the style of the face is used

- the "/" is not used in all OO languages, and is not the only way

- as noted above, the current INSERT-PANEL-CONTENT name is inadequate, 
since it does not respect, that the layout may not be a panel at 
all

insert-into my-panel [content here] looks short and reads nicely 
....

et-panel-content
clear-panel-content
insert-panel-content
append-panel-content
change-panel-content
remove-panel-content

set-content
clear-content
insert-content
append-content
change-content
remove-content


; Disadvantage of following group is, that it does not relate to 
the content, and hence we are reserving/blocking those names for 
our particular purpose.
set-in
clear-in
insert-into
append-into
change-in
remove-from

Think about them in the usage scenario,e .g.:

insert-content my-panel [content here]
insert-into my-panel [content here]

1) Do you find the 'a layout' and 'layout style' notions to improve 
the current 'a panel' ambiguous terminogy, or do you prefer something 
else?


To me, a layout is a specification, not an instance. I don't know 
that using a different word (container or compound) helps. You just 
need to be explicit about whether you're talking about a panel face 
or the panel style (which has a layout specification).


2) Which of the three [[hpanel vpanel] [panel vpanel] [panel panel 
vertical]] alternatives do you prefer?


My view was based on there always being a base 'panel style, with 
'hpanel and 'vpanel being shortcut styles to set the layout mode.

I never wanted to be able to discern the panel style and panel face

the word 'panel' was used as a name of the style as well, which means, 
that 

a panel" could mean "an instance of the panel style" instead. Using 
both senses makes the documentation (and code) rather confusing."

I guess I'm not seeing how it is any more confusing in code, and 
in docs you can be explicit. But I'm obviously missing something.

Back in a bit.

And, it is used in the INSERT-PANEL-CONTENT function name, where 
it is inappropriate as well.

Before panel was used as a style name

 - I exptect panel/vpanel to exist in upcoming releases ... and then 
 I suggest to remove word panel from the function name.

Sorry, forgot we have recently hpanel and vpanel ....

We are going to re-factor the complete ACTOR & REACTOR stuff in R3-GUI. 
It will be streamlined, much simpler and more common in that it follows 
"best practices" from other GUI libs. The side effect is, that this 
is a bigger re-refactoring step and will take some time. Until done, 
we are not going to make a new release.

If you streamline well, in the REBOL way, things become more flexible 
and capable

view [ AREA [ red "12" green "AB" blue "ab"] ]
Caret cannot move to "12" and "AB". A bug, I think.

It will much simpler and more cabable.

Pekr: "I hope it stays as flexible as possible?" - sorry to spoil 
your expectations, but our main goal is to make it dumb, incapable 
and more rigid than possible.

As status of RMA's GUI is more of a private effort targetting business 
level apps, I can imagine kind of simplification, which makes it 
"dumb, incappable and more rigid than possible", because it just 
fitst your limited business apps needs :-)

Yep, which are very limited and that's why people pay a lot for our 
stuff.

The main problem at the moment is (and I hope I hit it correctly, 
otherwise Lad etc. will correct me) that it's not clear which ACTORs 
call which REACTORS. And if all REACTORS are executed or not. So, 
there is not logical relation between an ON-KEY event and an ON-KEY 
handler. Further, one sometimes need to first call the user-code 
event handler, than the style handler, or the other way, or in between.

In a simplified form:

- the DO-STYLE function will be renamed to DO-ACTOR

- both Henrik and Robert wanted to be able to influence the behaviour 
of actors from the Layout dialect,
- which was not possible yet,
- and was not compatible with the idea of reactors

- therefore, it looks like the best idea to introduce one new Layout 
dialect keyword (ATTACH),
- and allow to influence actors from the Layout dialect,
- making reactors unnecessary

Well, VID was always declarative, and we know it was/is limited. 
From your proposal it still looks good to me, there just will be 
the need to be able to specify more then one action. I can even imagine:

button "browse" #"B" action [
    on-click [do something]
    on-hover [do something]
]


But for single actions, there would be one unnecessary block level 
probably. I am open to any proposals, and looking forward to final 
solution ....

it won't be necessary with actions (I hope). you simply call actors 
directly. About chaining them, how does it make sense to chain an 
on-click and on-hover actor? They are separate actions. What you 
need is the ability to stack the action code for actors, so that 
if an actor is already defined for a style, then the new action code 
could be appended to the original code. I use a similar design in 
my private version of the VID Extension Kit, but am also forced to 
use the traditional actions as they are part of the standard face.

A terminology problem related to the ATTACH keyword. Every face should 
have an attribute listing the items attached to it, and an attribute 
listing the items to which it was attached. One (let's call it 'extra 
long') alternative might be ITEMS-ATTACHED-TO-THIS and ITEMS-TO-WHICH-THIS-IS-ATTACHED. 
To show you an example, let's have faces A and B, and suppose, that 
the user attached B to A. Then:

1) for A, the ITEMS-ATTACHED-TO-THIS list shall contain B
2) for B, the ITEMS-TO-WHICH-THIS-WAS-ATTACHED shall contain A


The problem is, that the above two attribute names probably aren't 
the best possible (or, are they?). Any "ideal" attribute names you 
prefer?

My understanding is that the purpose of ATTACH is to direct the flow 
of action events.....


....If face B is attached to face C, then face C also gets B's action 
events. And if B is attached to A, then B gets A's action events, 
prior to them flowing to C.


So, from a stream-of-events, perspective: A is UPSTREAM of B. While 
C is DOWNSTREAM of B.


Hence a suggestion,,,,,, ATTACHED-UPSTREAM and ATTACHED-DOWNSTREAM.

It is possible, I think, Graham that a face can be in more than one 
heirarchy; so PARENT and CHILD alone does not describe which hierarchy.

Other structures that may have child/parent faces: panels within 
panels; Z-axis visibility.

It's time to decide about propagation of events using actors in R3GUI 
so we would like to know your opinion on that.

example:
Let's have face A and face B which is inside face A.

Currently, when you click mouse button on the face B and the face 
B has defined ON-CLICK actor the event is fired to that actor.

If the face B have no ON-CLICK actor the event is not catched anywhere.


We got a request to checnge this so there are few possible options 
we could use:


1. If face B doesn't have ON-CLICK actor defined then propagate the 
event up to its parent face (in our case face A) and up until any 
ON-CLICK is found. (If the face B have ON-CLICK defined then the 
actor is executed and propagation stops here.) In other words the 
event propagation stops in the closest found ON-CLICK actor during 
the 'bubbling' of the event upwards.


2. Propagate the event from face B thru its parent face (in our case 
face A) and up to the topmost(Window) face. The propagation/bubbling 
is done by default and can be stopped in any ON-CLICK actor on the 
way upwards by returning 'stop-event(or any other chosen) keyword. 
(this is simmilar to the model used in HTML)


3. (current behaviour) Don't propagate the event. Just execute the 
ON-CLICK actor in face B in case it is defined. Programmer have to 
manually add event propagation code to the actor if event bubbling 
is required.


4. Don't propagate the event by default. But introduce PROPAGATE/BUBBLE-ACTORS 
(or any other chosen word) option field that can be set for each 
face. The option could hold block of actor names that should propagate/bubble 
the events up.


Please, keep in mind that chosen behaviour affects not only actors 
that handle user input but also actors like ON-INIT, ON-MAKE and 
any other possible actors in general.


Please post either your favorite from the above options or even any 
other possible solution you think is better. Thanks for your help.

#4 is an extension to #3, and would be my first choice if #3 isn't 
enough. I generally don't like having to say "stop!" to avoid unexpected 
behavior. I don't know if #1 works well, though I think QNX Photon 
used it.


If the 'bubble option can be part of the style, then you can define 
buttons not to bubble on-click by default, but maybe 'text would, 
for example.

#2 seems the worst of both "worlds"
#3 seems clear and workable
#4 appears to lead to complexity

* I do agree with Peter that #3 is clear and workable. Accepting 
any of the alternatives would require (a lot of, I am afraid) code 
to stop  unsolicited bubbling.

* #4 appears to lead to complexity, and thus it may be the worst 
alternative
* #1 looks like the second best to me
* #2 looks like the second worst

I do remember how QNX Photon used such a trick to share screen content. 
You defined X*Y area of the screen (imagine empty translucent face) 
and all events got via that "filter", so that you know what to send 
to target computer, and then the event was propagated to cause an 
action (at least that is how I understood it back then)

I am probably for #3 or #1. Just help me to brainstorm one case - 
what we have mostly wrong in REBOL, is pop-up handling. I mean - 
just recently e.g. when you "drag", and you move away from the face 
coordinates, the dragging stops. The same goes for the context menu 
etc - you have to be able to close the menu by clicking anywhere 
in the apps window. Which model fits best?

One of the attractions of #1 is that it makes it easy to implement 
"default handlers" at some point higher up the hierarchy. For example 
based upon an  "esc pressed event" (if one were to exist.) and you 
had designed a panel with four buttons. If you wanted to close the 
panel when the user pressed esc, you would simply have a single "handler" 
for the panel which would receive the event.


I'm sure that this isn't  the best example and apologise in advance 
for my ignorance of REBOL3-GUI and its common terms.

With 3. you can simulate 1. The advantage of 3. is, that I can decide 
at what place the parent actor is called.


Which leads me to a question: Is 3. a call the parent actor, which 
returns, or do I just let the event flow and it will never return 
to my handler?

I prefer #1 and then #3.

Is there a way that we can use #1 and add a way that it can be overriden 
by #3 concept? So, everyone how don't require fine-grained handling, 
uses default bubbeling.

For example if I add image to button, with #3 I need to ad actor 
to image to catch click and send it to button. With #1 it's done 
automatically.

...and currently you cannot set actor to undefined state. So #1 wouldn't 
be too much useful, isn't it?

Otherwise in the #1 case I can image there could be some confusing 
situations where some face doesn't have some actor defined and the 
event will 'bubble' too much up in the face structure causing execution 
of unwanted actor. What do you think?

Rebolek, that's not true. You can create layouts with misc actors 
combinations that will behave strange and you'll be scratching your 
head where to put at least empty actor to stop the unvantred propagation.

As for overriding. I am not sure higher level on-click should disable 
lower level on-click. In the OOP I used (CA-Visual Objects), and 
just IIRC (so sorry, if inaccurate), you had such options:

- to execute child method

- in the above you either returned false (maybe I get this one wrong, 
but you get the idea) or the parent method was called right after 
the child's method 

- there was also some override option, but I don't remember it, it 
is 12 years old experience

Pekr, I don't think 'insert-event-func' has anything to do with this 
decission. Currently R3GUI doesn't have the exact 'insert-event-func' 
mechanism. But you can add your custom handler with specific priority 
into the main event loop and then either filter out or pass the events 
to the system.

I'm late and give my vote to #2.

Why ? because I think it's the easiest way to assemble components 
containing several gobs acting together.

I take one example:

If I create one button style with only one gob and then I decide 
to add an inner gob to change its aspect.
I don't want to have to change some code just because of that.
Gob's compositing  should be the easiest as possible

Quite good. We did some major re-factoring and are currently getting 
automatic GUI testing done. We need this for several reasons:
1. Automatic style lib testing
2. Applicaiton testing

This is a major step as it will reduce our hours to do these tasks. 
Testability must be designed in right from the start and it will 
save thousands of hours of effort later.

A post to keep you informed about what the ELICA LOGO can do relative 
to 3D graphics, animation an GUI (under windows only) - all their 
libraries are open source and I thought you would like to know about 
- see the link in the OPEN GL group. Hope it can be useful in some 
way or another. Regards, Gerard

The current overview of all styles:

http://rebol.hmkdesign.dk/files/r3/gui/253.png

Some more images here:

http://rebol.hmkdesign.dk/files/r3/gui/

A bit of status:


- Cyphre has recently fixed a bug in the hostkit with the display 
of some unicode characters. Will see if there can be a release.

- Cyphre has been working on fixing various low level issues in the 
R3 GUI source

- Cyphre is working on testing scheme for GUI and some documentation

- Bolek is working on styles and a TODO test application, called 
"Notation" for Robert

- We still need Carl to fix one particular bug, which is prevents 
creating complex layouts

Thanks a lot for an update, both Robert and Henrik. It is encouraging 
to see some activity. As I personally offered to Rebolek - I can 
make some quick testing/private reporting, so if you can prepare 
some interim release, I am interested. But - I can wait for the official 
one.

how powerfull is a table style? I expect it not being full grid capable, 
as Cyphre did in the past, however what's the basic functionality 
to expect?


- column sorting - two state, or three state? (I don't like when 
I can't get back the original sorting = unsorted), but that's just 
my point-of-view, and not importan feature initially
- column filtering like in MS Excel
- how much data the table handles?

DB mode? That's exciting news. Thanks Rebolek for the update and 
Pekr for asking.

Most excellent Henrick (and RMA).

James, I wrote first round of basic tests for some styles and so 
far this method works well. I haven't tested recording of realtime 
resizing and dragging so far but I'm sure if there are any issues 
they'll be fixed along the way. Otherwise this method doesn't cover 
only recording of user input, but it is possible to insert 'checkpoints' 
with REBOL like code to check specific conditions during the testing 
sequence. Cmobination of both makes this testing subsystem very flexible 
and relatively easy to use.

And, there won't be any changes. It's just to access stuff in a face.

I think the intention is to emulate the MacOSX tag field. You write 
in a "floating" text field and when pressing enter, it becomes a 
tag, which can be deleted or moved around. Deleting or moving doesn't 
work yet.

One thing I would like to see is the ability to keep focus on a field 
and not let it be lost to other faces/widgers appearing

In an async application you can't control which windows popup in 
the background ... so you want to keep focus on a field where you 
are entering data and not be kicked out of that field

NLPP 2.0 is R2 and RebGUI based.

The timing is bad, as NLPP 2.0 has already been in development since 
early 2011 and it's almost leaving alpha development. Furthermore, 
there is a lot of development time invested in some special RebGUI 
widgets for NLPP and converting this work to R3 would take a significant 
amount of time.

With our R3-GUI test-system available now, we could really need some 
help in creating test-cases. The more the better. We want to build-up 
a huge test-suite for GUI tests that we run on "every commit" to 
keep quality high and identify breaking changes.

The more help to build test-cases and submit them to us, the faster 
we will be in pushing R3-GUI forward.

I can still get hard crasches of R3, in various phases:

do %r3-gui.r3
do %examples/run-layouts.r3


Two times I got a crash, when just closing the windows, and when 
at layout #15, clicking in the form. Once I got it with layout #20, 
and once at layout #27, clicking the big red button ...

I just posted what I do. Running above script, closing the windows, 
and trying to click into some forms. Not easily reproducible ...

Cool that he's available. I noticed his new photo on a vineyard, 
on facebook, so he's still alive and well :-)

As for the possible "look & feel" of the GUI, I personally like HTC 
Sense, and Linux Mint - combination of light greay and green. IIRC 
Ashley created some more lightweight look for his GUI too later in 
the process ...


http://www.xda-developers.com/wp-content/uploads/2010/04/ScreenShots.png?139d23

http://smartphoneblogging.com/android-picture-galleries/htc-sense-screenshots/
http://www.linuxmint.com/screenshots.php

Take it just as a note :-)

Robert - I think that it is not accurate, that noone is interested 
in the R3 GUI. IMO we all are, it is just that each of us is busy 
elsewhere. If you look into the past of this group, or in the old 
GUI (Carl's one) old days, it was mostly me and 1-2 users to do some 
comments, studying code, etc. It is about the general lack of man-power. 
E.g. shadwolf claimed, he can do tree view in few hours, but is refusing 
to, and you better don't read the long blog chat. It is also about 
lost confidence of many rebollers into R3 in general. Or just maybe 
- ppl being in wait mode, untill Carl reappears?

As for me - "I would like to help", and I will at some point, at 
least with testing. But got my own project 2Zone moving, awaiting 
LED Screen arrival and needing to do many arrangements. I can't surely 
code tree-view,but I can test, even privately, for anyone who asks 
me. Not much next 3-5 weeks though ....

Robert: you are wrong.  As Pekr said many of us are waiting and busy 
with something else. I downloaded all the RMA R3 stuff, tested all 
GUI examples (found some crash problems btw) I really would like 
to help/write a tree style, but I'm not a good Rebol coder I'm afraid.
So please keep up the work.

Robert -- an R3 GUI just isn't one of my priorities just now.


While  there is no likely target date for a beta release of R3, all 
my REBOL development is on R2.


I was happy to help debug R3 alphas while that project had some momentum, 
and I may be again in the future, But right now, I just do not have 
the time for what I have to consider to be speculative projects.

I hope you do get the help and feedback you need.

I will be more actively interested when I start having to write code 
that requires any GUI at all, but what I'm working on right now doesn't 
even need a web interface. All batch and server stuff, and almost 
all the REBOL stuff is R3. This can't last forever, so I will eventually 
need a GUI. I am working on ODBC though.

Well, we all have a hell lot to do. There are just a some simple 
facts:


- making public releases cost us time. Not horrible lot but anyway...

- people are interested to take a look at the code and run the tests...
- maybe we get some feedback

All nice, but it doesn't move us forward faster.


I'm not frustrated I'm just wondering.... there are still a lot of 
excuses why R3 can't be used (which is wrong) but only a very few 
people try to build something with it.

That would depend if Carl approves it, and AFAIK he has not looked 
at any of the changes yet. However, it won't affect the development 
of the R3 GUI, whether he approves it or not. It will still be made.

and: Than you need to take action and change it. It's not a "musical 
request programm" where you want something and it will happen.

...And, R3GUI is not in limbo, it is being developed

No, NLPP 2.0 is already being tested, and adjusted (finishing touches), 
in R2

I have a RebGUI application of some hundreds of screens and sadly 
it is not very brisk these days presumably due to GC occurring at 
inconvenient times, or just using too much ram.  Any stress testing 
down with R3GUI with hundreds to screens?