Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: steel... update... of the week (for more advanced rebolers)

From: maximo:meteorstudios at: 27-Jun-2003 18:43

Hi list, thanks to Gabrielle I created a liquid-metal skin its a superset to the metal skin that is currently in the steel toolset. here is a snippet of code I have at home which works now! note that code size has been cut in half wrt last example! ----------------------------------------------------- ------------------------------------------------------ rebol [] liquid: open-library 'liquid 1.0.0 ;---- ; create a liquid pipe network (the master) pipe: liquify liquid/pipe [] ;liquify replaces make ;---- ; create a vid layout vidblk: layout [ stylize liquid-metal below sheet-metal ; the default steel backdrop text-str: text pipe field 200 attach pipe fill "START NAME:" button [view/new layout [button [unview] attach text-str]]] ] recipient: liquify liquid/recipient [ ; recipient has an init function which checks ; if --valve-- was set and attaches to it automatically. --valve--: text-string/pipe-obj fill-action: function [data user-data][ write %./save.txt data ] ] evrything updates without one action func. further replies below:
> -----Original Message----- > From: Gabriele Santilli [mailto:[g--santilli--tiscalinet--it]] > Sent: Friday, June 27, 2003 9:49 AM
[...]
> For example, wrt face/init, it's not casual that it is a block. > This way, when creating a new style from an old one, we can write:
ok, but layout still has to call face/init ... so the vid dialect handles "dynamic" init, not the object system itself... in glass I must also call some sort of face/init after creating. I know its not a big deal... :-) it just an extra line of code I don't write anymore. It also means initialisation remains private at the object level so I don't need to think about always copying empty blocks and strings or whatever... directly on objects. I love the fact that there are no classes in rebol and that objects aren't instances. But I sorely miss some aspects like private methods and members which, are most usefull (I find) when developping frameworks, api, and tools. I also understand that all this comes at a price that isn't always used by the mass... (that's why python is more flexible wrt rebol objects BUT that's also why its 10 times slower) I do agree with you that rebol thinks differently and the package as a whole is exceptional. Its just a little tough to customize the stuff when the internals aren't overly documented... THAT'S WHY I LIKE THIS LIST... we all have little secrets and I find it cool that people, here aren't affraid to share them :-)
> Another approach would be that of creating a custom type and then > defining your TO action for that type, so that basically you use > TO instead of MAKE to create your values. (If this was supported > by REBOL natively, MAKE would do it for you...)
aren't custom types just in the sdk?
> MOA> does the value at the end of "make block!" really matter i.e. > MOA> could it be 1? is it similar to: [words: copy []] > > It doesn't, except for the fact that the interpreter won't have to > reallocate the space when you'll be inserting values in it.
thanks... didn't know that
> MOA> I guess args points to the word block at the first > argument word (ptr to a notifer, for example), > > If your VID code is: > > Text attach pipe > > ARGS will be set to: > > args: reduce ['attach pipe]
ok, so then when back in layout it does something like?: last-arg-used: my-facet-word-function args new-offset: find vid-spec last-arg-used?
> MOA> and this return the list past all arguments you need... :-) > > Actually, one position back, because LAYOUT is already applying next
[...] weird...I am using: return tail args And it works fine... Am I just lucky? -Max