World: r4wp

I'm fine with a purely REJOIN-based invariant as well. (Even though 
I personally find a path-based invariant more useful.)

For those interested in the "alpha-channel change":

Here is the branch with first round of related code changes to the 
image! and image codecs: https://github.com/cyphre/r3/commit/472c106a0f177ead82a6f29be1ae98b4cd33b9ad


Note: This code doesn't contain any graphics related changes...just 
the image! datatype + image codecs so you can MAKE images and load 
BMP, GIF, PNG and JPG files. But it should be enough to test the 
change.

(I have this code already intergated with changed AGG graphics and 
it works well but I haven't published it as this part is not compatible 
with the 'official' git source at the moment.)

Note2: the code was not tested on big-endian systems so it is possible 
there can be some quirks. Use at your own risk and let me know about 
any problems.


The RGBA tuples on IMAGE! now work so if the fourth(alpha) value 
is not defined it is assumed the RGB tuple is opaque (ie. alpha = 
255) so 0.0.0 = 0.0.0.255 etc. This way color values in old code 
that doesn't explicitly define alpha values are still compatible.


If you are interested, try to compile and test a bit. Let me know 
if you see any issues. Thanks.

Great job, Cyphre!

Isn't a convention that %foo/ is a directory while %foo is not?  
That's one way to tell if a given file! directory or not...  It's 
what I generally expect, and I agree with Maxim that it makes the 
most sense for split-path to return #[none] if there is no file.

Andreas, the trailing slash is the separator.  Are you proposing 
that split-path do a system check to verify if its a file?  like 
dir? does in R2?

It can't do a check, because the file may not exist.

Max said: "split-path shoudn't invent information which isn't given 
to it"


I agree, if we consider split-path to be operating in string mode 
(the rejoin invariant). If we want to have a file-system aware option, 
what would we call the refinement? Or should it be a separate function?


As far as returning none for either part, it strikes me as inconsistent 
(if convenient, which it may be). That is, if you split a series 
into two parts, splitting at the head or tail should just give you 
an empty series for that part, shouldn't it? This comes back to my 
SPLIT-AT question.

e.g., what would you expect for each of these cases?

	[split-at "123456378" #"/"]
	[split-at/tail "123456378" #"/"]
	[split-at/last "123456378" #"/"]
	[split-at/last/tail "123456378" #"/"]

if it where a generic string handling function I'd agree with you... 
but its not... it has added meaning, it splits filesystem paths. 
 its not just a string.  if it where, I'd use parse or some tokenize 
func.

I see absolutely no merit in trying to make split-path act like a 
generic string handling func.  the point of the func is to separate 
folder and file into two parts.   to me it comes down to either you 
decide that when there is no data you invent a default, or use the 
internal one which is none, which works well with soooo many other 
funcs.  if there is no directory part in the path, do not try to 
find a suitable value for it... there is none... funny, even when 
trying to explain my point of view, the actual sentence reads almost 
like a line of rebol source.  :-)

if you give me split-path %"" I'd return [none none]  if you want 
a meaningfull default for the dir, then just use clean-path before 
supplying the value to split-path, then you'll be assured of always 
getting a directory.

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 ...