World: r3wp

>> img-size: func [img] [img/size]
>> img-size logo.gif
== 100x24

something that should be RAMBO'ed?

I don't think it's that important. It's a small inconvenience isn't 
it ?

But for some fun, you might be able to do something like this:
>> do to-path [help.gif size]
== 48x48

there probably are other cases like this.

well, sure. I just thought that there would be a way, like using 
first, second and third on objects

yes, but first etc have a different meaning already

what i really want, is the abilty to list the available refinements 
of a datatype.

Mmm.. in which context do you want that ? Autodocumentation ? Just 
quick console help ?

it should be part of reflexivity. you can access the components of 
an object; you should be able to access the components of everything.

(security and modules aside)

maybe the select action could be overloaded to do what Henrik wants. 
i'm not too much in favor of overloading functions though.

(that is, select something 'word would be always equivalent to something/word)

I think a separate function such as ACCESS should do that. SELECT 
should be left alone to do its series operations as usual.

How about expanding 'in to cover more than just objects?

I imagine:
	access help.gif 'size ; == 48x48

I think that might slow down IN... not sure.

i don't propose changing select. i propose enabling it for more datatypes.

in: you can't have a word bound to an image :)

(ie. same as Gabriele's comment about overloading.)

select is an action, so a method to the datatype. in is a native.

What I mean is, every time IN is used, it would then have to check 
if the argument is an image, right ?

yes, and it would behave like a completely different function in 
that case, which is bad imho

Ok, so we agree on IN.

select instead is already dispatched because it's an action, and 
it would not change its behaviour (returns a value)

A: From a tech pov, yes.

I can't think of an example where select is dispatched differently...

actually, select currently doesn't need being an action, afaik. as 
it is basically second find

so maybe it was made an action to allow things like this in the future 
:)

Ah ok.. yes.. mmm...

(though, there is an action that already does this: PATH. but it's 
not exposed.)

Ah yes, maybe that could be used.

i'd guess path is going to stay this way for speed (internal only), 
but select could be a good interface to it.

I guess so. :)

>> copy/part skip mold get first [help.gif] 13 5
== "48x48"
(Only works for sizes taking up 5 chars, but it's a start.)

But why the heck do you wanna do it? help.gif/size is so easy.

Maybe size? could be changed to work on images too!?

I don't know the name of the image

you'll see soon where it's used :-)

SIZE? is a function using INFO?

INFO? is a funciton working on ports. It's easy to do the same for 
images.
image-size?: func [img] [img/size]

anyway, problem was solved by gabriele's function. thanks, by the 
way

>> image-size? get first [help.gif]
== 48x48

precisely what I'm using now

oki

ops, I skipped Gabriele's post. There it was! :)

I'm not sure this is ready for announcement as it's still a prototype, 
so I'll put it here: http://www.hmkdesign.dk/rebol/toolbar/toolbar-demo.r

it's a toolbar with a simple dialect to alter the sequence of the 
buttons. the space between the buttons is flexible.

I like it and you thought also about the text to the buttons.

Yes, looks good.

It even resizes correctly! This will give apps a decent professional 
look.