I like how facets, options are separated, as well as actors, and whole style is drawn using a draw dialect ...
So, I hope we get nice code patterns like follows:
stylize [
    my-progress: [
        about: "Progress bar."
        facets: [
            size: 200x22
            max-size: 1000x22
            edge-color: 96.96.96
            area-fill: span-colors area-color [.3 .5 1]
        options: [
            bar-color: [tuple!]
            size: [pair!]
        faced: [
            bar-color: teal
            bar-size: 1x1 ; modified by the progress % value
            bar-fill: ; generated from bar-color option
        draw: [
            pen edge-color
            line-width 1.5
            grad-pen 1x1 0 20 90 area-fill
            box 1x1 area-size 3
            grad-pen 1x1 0 20 90 bar-fill
            box 1x1 bar-size 3
        actors: [
            on-make: [
                face/facets/bar-fill: span-colors
                get-facet face 'bar-color [1.0 1.5 .6]
            on-set: [ ; arg: event
                ; Update the bar size from the face value.
                face/state/value: arg/2
                v: clip-face-val face
                size: get-facet face 'area-size
                face/facets/bar-size: as-pair v * size/x size/y
view [
    prog: my-progress
    button "Set 50%" set 'prog 50%
Notice that facets are shared, whereas faced are private. Also notice the SET VID level reactor ...
Remember - Carl spent 3 months designing it and writing a prototype. That was time spent for good ... and Red gui should aim no less ...
My method is iterative, I don't do tunnel-development. ;-)
Where is that code example coming from?
"My method is iterative, I don't do tunnel-development." - which is how VID Junior is meant to be done. :-)
Ok, found the source of the example:
Well, not sure about the styles, if you want to map to native widgets ...
I still remember Cyphre's remark in Brno - how many usefull widgets are there in the OS anyway? How cross platform are they? So we have fields, areas, buttons, images, radio buttons, check boxes. What about more complex ones, as grids? Win32 API apps look uglier, than old 70ish unix clone. And - design sells. Let's hope, that this time, we are going to dress that :-)
Red has different needs, like willing to _compile_ as much code as possible vs run it through interpreter. So the actors above need to be defined differently so that the compiler can effectively find and process them.
"Win32 API apps look uglier, than old 70ish unix clone" On each Windows platform, you will get the native OS look'n feel, I don't know what you are talking about.
I had a preview of that in Windows 10... that's what I would call "ugly". ;-)
Doc, if you use our release on Windows:
>> source load-gui
load-gui: make function! [[
    {Download current Spahirion's R3-GUI module from web.}
    /local data
    print "Fetching GUI..."
    either error? data: try [load] [
        either data/id = 'protocol [print "Cannot load GUI from web."] [do err]
    ] [
        do data
Robert, thanks, downloaded and decompressed it.
The few docs we have are on our web-site. And yes, R3-GUI targets something different then VID or Carl's idea. It's for long-maintenance, business applications. So, not for a quick & dirty approach.
I don't know how often I explained this... If you expect a VID on R3 don't use R3-GUI, it's for full-blown applications.

Last message posted 68 weeks ago.