World: r3wp
[!REBOL3-OLD1]
older newer | first last |
Graham 14-Feb-2009 [11322x2] | when maybe somet hing this is preferable actions: [ tl:.on-click [ [set-face ca read-string pick files value] ] ] view/across [ tl: text-list files ca: code-area ] |
ignore the double [[ ]] | |
Anton 15-Feb-2009 [11324] | Couldn't you do something like this, using compose? actions: [ my-text-list [set-face my-code-area read-string pick files value] ] view compose/only [ my-text-list: text-list files do (actions/my-text-list) my-code-area: code-area ] |
Graham 15-Feb-2009 [11325x2] | And the same for every other possible event? |
Sure ... but just looking at cleaner ways of doing this separation ... getting rid of the 'do | |
Anton 15-Feb-2009 [11327x4] | It should be pretty easy to write a function that maps an ACTIONS block such as the following into a window: actions: [ my-text-list [ do [set-face ... ] "other-event" [ blah blah..] ] ] |
where "other-event" could be on-click etc.. | |
then the window doesn't have to specify any actions. | |
But I know what you're saying. You probably want such a function built in and used in the examples, so it becomes commonplace. | |
Graham 15-Feb-2009 [11331x2] | Yes |
Maybe there could be a stylize type of way to deal with actions | |
Anton 15-Feb-2009 [11333] | Function name and arguments? set-actions: func [window actions ... |
Graham 15-Feb-2009 [11334x2] | anonymous windows? |
I think it should be defined inside the window definition | |
Anton 15-Feb-2009 [11336x2] | set-actions view window-spec actions-block |
(Assuming VIEW returns the newly created window object.) | |
Graham 15-Feb-2009 [11338] | modal windows?? |
Anton 15-Feb-2009 [11339] | (which it does.) |
Graham 15-Feb-2009 [11340x2] | don't return until closed |
AFAIK | |
Anton 15-Feb-2009 [11342x2] | Ok, so you want the window definition to separate internally into two parts. |
Essentially: view [ ; ACTIONS my-text-list/action: [set-face ...] ; STRUCTURE my-text-list: text-list data files ] | |
Graham 15-Feb-2009 [11344] | yes just like a html page |
Anton 15-Feb-2009 [11345] | (I'm still sort of using R2 terminology...) |
Graham 15-Feb-2009 [11346] | and there's also passing the face correctly to the actions |
Anton 15-Feb-2009 [11347x2] | Well, it should probably be in the reverse order, I suppose. Structure is put in place first, then behaviour operates on top of that. |
view [ ; STRUCTURE my-text-list: text-list data files ; ACTIONS my-text-list/action: [set-face ...] ] | |
Graham 15-Feb-2009 [11349] | makes it easier for the view layout engine I guess |
Anton 15-Feb-2009 [11350] | STRUCTURE is actually "NAME-REFERENCE, STRUCTURE, CONTENT" |
Graham 15-Feb-2009 [11351x2] | I'd also like to have it so that we don't have to name objects and can point to them based upon order ... |
ahh... retract that. | |
Anton 15-Feb-2009 [11353] | I've spent some time thinking about that in the past, and it's difficult, if not impossible. |
Graham 15-Feb-2009 [11354] | in case we wish to dynamically insert objects into the display and then remove them as they do in Javascript |
Anton 15-Feb-2009 [11355] | yes, exactly. Dynamic structure. |
Graham 15-Feb-2009 [11356] | Why? If there's a tab order ... then there must be a serial structure |
Anton 15-Feb-2009 [11357x2] | Which can be messed up all too easily by dynamic structure. Your program could reorder tabs for instance. |
Or, as you say, a tab could be inserted/removed. | |
Graham 15-Feb-2009 [11359x3] | Eg. I like to create tables first as instant feedback, and then fill them with data from an async function. |
But I need to overlay a busy graphic which I can then remove ... | |
in the callback | |
Anton 15-Feb-2009 [11362x3] | Ok, so you as the programmer know that your table has a specific, static order at the time you need to fill it. No problem. |
Did you also mean that you'd like ACTIONS associated with STRUCTURE elements anonymously? | |
view [ ; STRUCTURE text-list data files ; <---- element #1 code-area ; <---------- element #2 ; ACTIONS [on-click [set-face ...] ] ; <---- actions for element #1 [on-enter [ ... ] ] ; <---------- actions for element #2 ] | |
Graham 15-Feb-2009 [11365x2] | well, I don't want to name each element of the structure |
but maybe we have to . | |
Anton 15-Feb-2009 [11367] | We could combine both approaches. In the ACTIONS section, if there's a word followed by a block, then the word is the name reference to the element (eg. 'my-text-list), but if there is just a block, then the next element is taken anonymously. |
Graham 15-Feb-2009 [11368x2] | Any objections to this vid enhancement? |
not all structural elements will have an action | |
Anton 15-Feb-2009 [11370] | view [ ; STRUCTURE my-text-list: text-list data files ; <------ element #1 code-area ; <--------- element #2 ; ACTIONS my-text-list [on-click [set-face ...] ] ; <----- actions for my-text-list [on-enter [ ... ] ] ; <------- actions for the next anonymous element (in this case code-area). ] |
Graham 15-Feb-2009 [11371] | I guess they will ... on-hover, on-tab etc |
older newer | first last |