World: r4wp

I understand your view Max, but that's not what I asked. It doesn't 
work the way you want today, but maybe there's a way to provide a 
solution that is better than what we have now. I'd love to see your 
custom version, so we can compare its results. And I'm asking about 
SPLIT-AT for a reason, separate from SPLIT-PATH. I'd love to get 
everyone's thoughts.


The funny thing is how much we can all care about the details of 
this func we (at least I) use a lot, and yet which none of us seem 
to like all that much. I think it points out that the normal case 
is the most important, where there is both a path and a file component. 
And maybe now is the time that we can make it just a little bit better, 
a little more consistent.

With regard to the edge cases.

The other thing, you may have noticed, is that everyone is at least 
somewhat flexible. We all have reasons for our preference, but the 
other options are seen as valid too. I think it comes back to the 
expected use cases. Sadly, each preference has valid use cases as 
well. :-)

I asked this in the SO chat, to BrianH, but maybe someone here can 
answer sooner.


@BrianH, can you confirm that that it's a bug that a module loaded 
using import doesn't export any words listed in the Exports: header? 
When I load the same module using Needs:, its exported words are 
visible as expected.

It's not a bug, it's a limitation of Rebol's binding model. Needs 
is called before the script is bound, and before the module context 
even exists (if the Needs is in a module header). Due to a couple 
of tricks IMPORT can mostly as a function running in scripts (shared 
globally referencable context), but it's impossible for it to work 
as a function in modules because the target scope is impossible to 
determine and the code was bound already before it even started running. 
So, long story short, IMPORT is for calling from scripts, or for 
Needs to call internally, or for advanced code where you are doing 
your own exporting.

It could be worse. Circular Needs references are currently a bug, 
but I'm not yet smart enough to resolve them, or even to know whether 
it is possible to resolve them.

Hello everybody,  after some months using R3GUI I still doesn't realize 
the causes of the changing syntax from Rebol 2 VID.

My impression is that all become very complicated.  Now to decide 
every action you have to put "on-action" or something similar before 
the action block, before it wasn't needed; but the worst part that 
all is inside the gob object of the graphical object. This way you 
have to write very long commands to achieve the most simple tasks 
(show mybuttob/gob ... mybutton/gob/size). Is it just my impression?
Is there any simpler dialect?

The generic problem to solve is this: You somehow have to specify 
what should happen for different actions. 


Let's start with the "somehow have to specify what should happen". 
For this you have some options:

1. Write the application logic code in the GUI spec block. For sort 
stuff OK, for long not.

2. Just call a function from the GUI spec block and write the rest 
somewhere elese. That's IMO the best way. I used FSM and just send 
"application logic events".

The next part is the "for different actions". Same here:

1. Name them explicitly on-* and specify the code with one of the 
options above.BTW: IIRC R3-GUI has click and right-click blocks for 
convinience.

2. Define an implicit mappging from block order to event type. 1st 
block = click, 2nd = right click, 3rd = double left, 4th double right, 
etc. IMO that's not a good style.


Overall what I never liked about VID was that is was not explicit 
enough. For big projects that's a must. For small you might skip 
this but if those projects get bigger, you are hit again.

We can always build a "shortcut" dialect like VID on top of R3-GUI, 
for common simple patterns, once R3-GUI is complete.

Now ... every action you have to put 

on-action" or something similar before the action block, before it 
wasn't needed; but the worst part that all is inside the gob object 
of the graphical object." - these decisions were made by Carl, but 
he also reacted to some popular demand when doing them.

My concern about GOB! is that all the rest seems not useful, probably 
at the present is missing some function, but or you act to GOB! directly 
or you have no other ways to change a facet. Am I wrong?

The problem is, that while the R3-GUI is now more flexible by removing 
reactors, it is also more difficult to understand. I remember trying 
to understand the 'on-action issue in the past, now I briefly re-read 
the doc, and I still can't understand the design. I need following 
things to be cleared up for me, so that I can both use it, and possibly 
explain it to others:


1) If you look into Actors docs - http://development.saphirion.com/rebol/r3gui/actors/index.shtml#
, there is no mention of 'on-action actors. There are many actors 
listed, but not the 'on action one


2) The 'on-action actor is mentioned in the attached doc at the same 
URL, describing, why reactors were removed. So here is the definition 
of 'on-action: 

        a) "The ON-ACTION actor is useful if the style needs to call some 
        default action from multiple places (actors) in the style definition." 
        - understand the purpose, but why and when I would like to do such 
        thing? Any example easy to understand? Just one sentence maybe?

        b) "For example, the BUTTON style needs to call the default style 
        action from the ON-KEY actor and also from the ON-CLICK actor, so 
        it is better to call the ON-ACTION actor from the both code points 
        to avoid the necessity to override multiple style actors." - looking 
        at button or even clicker style definition, I can see no such stuff, 
        as 'on-key or 'on-click calling anything named 'on-action. That is 
        the part that is most confusing for me, and which did not help to 
        understand the 'on-action a little bit. Are we talking about the 
        'do-face here?


There is also a question, if better name could be found for 'on-action. 
Unless I can fully understand, what happens here, difficult to suggest. 
Now to make it clear - I am not judging architecture, just trying 
to get my head around the docs and button/style examples. And being 
average reboller - if I have difficulcy to understand it, the chances 
are, there is more ppl, which will strugle in that area?

Another interesting thing I noticed:

    facets: [
        init-size: 28x28
        bg-color: 80.100.120
        border-color: 0.0.0.128

        pen-color: ; set by on-draw
        area-fill: ; set by on-draw
        material: 'chrome
        focus-color: guie/colors/focus
        draw-mode: 'normal
        materials: none
        face-width: none
    ]


Normally, in regular Rebol code, 'pen-color and 'area-fill, would 
be set to 'chrome, if I would use it to construct an object. But 
maybe it is just a spec block, so I should not care? I mean - what 
about setting them initially to 'none too, for a convenience? :-)

MaxV: "This way you have to write very long commands to achieve the 
most simple tasks (show mybuttob/gob ... mybutton/gob/size). Is it 
just my impression?"


My guess is you are not using R3GUI correctly. If you are using the 
current included R3GUI styles you shouldn't be forced to write any 
SHOW commands at all(the SHOW command is considered 'internal' in 
R3GUI and shouldn't be used anyway). Just use the SET-FACE/GET-FACE 
api to make changes to the specific style.

In worst case (usually when some ON-GET/ON-SET handler is unfinished/incomplete 
in some style) you can either try to enhance/fix that style part 
or

if this is too difficult for you you can try to use SHOW-NOW <face> 
to really force 'show' on the specific element.

MaxV: Alternatively you can post simple example of what you are doing 
in the R3GUI group here so we can see what is your exact problem.

Pekr: I agree the docs are still not corrected...infact it is a mix 
of old(patched) docs from Carl and some '"dev notes" docs from Saphirion 
team who did significant changes.

I started to at least review the Carl's docs to fix the most confusing 
or obsolete parts but I relaized I have not enough time now for that 
instead of programming. 

If you want to help clean-up the documentation or even write new 
document...kind of "User guide" for newcomers I'm offering you a 
help/support with any questions issues etc. during the doc writing, 
just le me know. Also we can discuss the issues in the R3GUI group 
here (I still wonder noone is asking anything...probably noone is 
interested?)

I think ppl in kind of an wait mode. Some interested in Android in 
general, some interested in Red progress, som interested in Ren, 
most of us busy other way.  Max in fact is doing a good job - he 
tries to use the system in a practical way. My questions are just 
theoretical, just by reading docs and looking into the code. I know 
I will be back to GUI at some point, just dunno when ...

I don't understand your "kind of an wait mode". If this is the case, 
which I don't know, I would like to know: What are people waiting 
for?

Robert, people like me feels they wont be able to face all the problems 
that will arise from uncomplete/unwritten documentation and prefer 
a REBOL2 version.

Personally I am waiting for the updated documentation since it has 
been announced. Also I am waiting for the IMAGE datatype my personal 
application needs.

 it is also more difficult to understand
 - frankly, *this* is difficult to understand:
* before, you had to understand both actors and reactors
* now you need to understand just actors, reactors vanished

...and you call it "more difficult to understand"?

The self-talk of my mind is the following:

Any example easy to understand?
 - yes! The Button style.

I don't know anything about R3GUI
There is an uncomplete documentation

It is difficult for me to understand new things. Since the documentation 
is uncomplete and refers to outdated concept it will be more difficult.
RMA has promised a new documentation
Since then I can wait to work in REBOL3
Also REBOL3 has many bugs and it is still in ALPHA

(Please note, no accuses of any king, only direct word from my mind)

Also REBOL3 has many bugs and it is still in ALPHA

 - what about the (already known for a while) info that R3 has less 
 bugs than R2?

Excuses, excuses...

Ladislav, where should I have read this fantastic information ?

That has been announced in the "Testing and tools" group long time 
ago.

Excuses have reasons.

Lets dress the clothing of someone which should adopt something new 
rather and unknown instead of something old and well known.

That programmer should adopt an ALPHA labeled product that let flash 
in his mind difficulties like "BUGS, NO DOCUMENTATION, SUDDEN CHANGES"

Apart from Unicode, we have no comparison over REBOL2 for new and 
better feature which could motivate the programmer.


Ladislav, consideer that people are humans. They have obstacles in 
their life. It is our role to understand which obstacles they have 
and how to "reframe the context" to avoid them.

I think that my situation is more common than we think.

R3 needs some marketing action to promote itself and lets people 
feel they can use it.

Apart from Unicode, we have no comparison over REBOL2 for new and 
better feature which could motivate the programmer.
 - wrong again, you surely heard about:
- essentially all cycles being natives in R3
- money implemented as a "truly decimal" format

- functions implemented differently to be compatible with multithreading, 
etc.
- closures implemented natively
- Parse improved significantly
- R3GUI improved
- new modules feature
- I do not even have the time to list all...

As I said, and need not take back: excuses

Ladislay - you yet again missinterpret what I expressed in my message 
above. I don't care about removal of reactors, it is not about actors 
vs reactors. I clearly posted points, which I don't understand - 
simply I don't understand, what is architecture behind on-action. 
And that's all.

Yes, it takes time to get into this new stuff, especially since things 
are moving. But hey, that's how it is. So, either wait (perhaps forever) 
or just start.

You can ask all questions, and we will answer.

Everone from our team stated that we will help.

About excuses - there are imo no excuses. As I said - we are just 
few, and ppl are busy with other things too. As for those really 
needing GUI right now (it's not me for e.g.), I think, that some 
ppl prefer what they know R2 VID, RebGUI, just because of typical 
entry barrier. There is nothing wrong with R3-GUI imo, and from what 
I studied in the past, it is much better system than R2. Sometimes, 
it is difficult to find out real reasons, why ppl react this way, 
or that way, I just dunno ...

And while doing this, if you start writing it down for others that 
would be great. And, we get feedback what's not a good design etc.

That's how I think a community should work together.

I think that there is no way to take it as offense. Noone said a 
bad word against R3-GUI today imo ...

no way=no need ...

I don't take it that way.

I'm just wondering why things don't lift up... and the explanation 
given. I'm just wondering.

Well, just count ppl here ... how many ppl are active? Even this 
channel is now split between here and Stack Overflow ...

From my experience one of the golden rules of life is (wow that gets 
philosophical): Waiting doesn't change thigns, you need to do it.

Sure, but if this is the conclusion, we better stop today and use 
something different.

Yes, I know - if I would have to write some small util for me, it 
surely would be R3 nowadays. The only thing I might miss is better 
CALL and maybe ftp protocol. But it can be solved ....

And of course time is limited, tell me. Nevertheless, if it's important 
people will do things.

Imo MaxV is trying to do the stuff, just look into his blog. He is 
just comparing what he was used to, with his new experience imo

Ladislav, my role in life is not to label what human beings are doing 
but change the way they look at things to overcome their obstacles.