World: r3wp

Roll-your-owns are often inferior to the OS default on recent OS 
X, but were not necessarily so on earlier versions of OS X before 
it was polished. Some developers are still better than Apple in that 
respect. BTW, the worst of the roll-your-own developers on OS X nowadays 
is Apple - they don't follow their own UI conventions anymore.

well, I remember that - that is why I asked the group what did you 
mean by that. By then - it is even less OS compatible way and even 
more free-form way ... it is not just skinning ...

I think there does have to be a balance.  Ultimately, what is more 
important?  The compositing engine or the language?

On other platforms the system standards are often bad, useless or 
missing. Windows and Linux come to mind.

Adobe Lightroom - where is your OS native look? :-)

Look and compare Windows XP to Windows Vista - have you looked e.g. 
at file requestor? It is FUNDAMENTALLY diffeent, more like different 
OS to different OS ....

Petr, I agree -- OS native isn't everything.

Chris, please, what was your idea about layout being one-way definition, 
and that it is different to html plus css? I can't remember it ...

That is why I said run-everywhere-applicable. I don't want View developers 
to be limited by my cell phone.

But, it is better than most roll-your-owns.  Do you have Adobe's 
UI designers to hand in your projects?

Brian, I think I get what you're saying -- roll-your-own at a sub-language 
level.  I think that's fair.

if things are abstracted via dialect, I am ok with that, if there 
is another layer, configuration one. It is like we are coding UBICOM 
CPU, and in the configuration part we choose, if we use hw UART, 
or sw emulated one - the app (code) does not care, still the same 
code ...

I mean that the specification of a menu dialect is not the same as 
its implementation. The specification can be cross-platform as applicable, 
but the implementation is paltform specific. Just make sure that 
decent UI designers are available to the platform implementors and 
you should be fine.

End developers would just declare their menus in the cross-platform 
dialect and trust the dialect processor to do the work. Unless they 
don't, and decide to replace the dialect processor, or do something 
completely different.

Petr, I really don't recall specifics of arguments I made years ago. 
 My thinking has evolved, and I may not be able to make the same 
argument today.

CSS tells a browser a) how gobs (rebol terminology) should look, 
and b) how gobs fit together.  As the UI model (or DOM) is altered, 
the browser readjusts but still remembers how things fit together. 
 In View, you have to define these relationships programatically 
(and therefore delve to a lower level than you intended)

could it be solved in layout?

It could be solved by a less static layout engine. That would mean 
rewriting VID and View. Good thing that is being done anyway.

would it be a benefit to have it awailable?

Chris: linux does not have a menu system.

While I don't understand the Linux desktop world all that well, would 
it be fair to say it'd require flavours -- Gnome, KDE and Custom? 
 Regardless, my hypothetical example (or what ever language-level 
solution is employed) should work in a manner consistent with the 
host environment (where possible, otherwise Rebolly consistent) whichever 
platform version of /View I download.  Where I think I misunderstood 
Brian is that *in my Rebol script* I do not want to say -- unless 
find [2 3] system/platform/4 [... implement a custom menu system 
of which I have to pick or design my own ...]

Many years ago, before Rebol, I designed a language called MIDAS 
(Machine Independent Demonstration and Animation System). Unlike 
most acronyms, this really was exactly what the language was for.


It had a lot in common with Rebol, and worked on lists of words or 
data.


Its goal was simple, to work backward from what we know all systems 
need in order to demonstrate and present UI and animations (video). 
 We were reinventing the wheel, every time we made something.


I knew for example that there had to be a screen, although some systems 
might be Bitmaps, some might be bitplanes (the Amiga), and some where 
character maps (C64).  That the system might or might not have double 
buffering, etc


The idea was to have the language work backwards from the goal, and 
to have code that would force all the media assets to conform.

So for example, you have an image, and you want to show it.

Show image.jpg

I designed this as P-code, but the point is the same.


You would then execute the program MIDAS on the code in the first 
pass.  It would ask you questions about parts of the code.  The image 
here would be in question.  So an images process batch would be created 
for each image.  Allow the image to be processed from the original, 
or built by hand (in the case of the C64 which only had a few colours 
per 8x8 square).


The reason I'm explaining all of this is that the Menu system you 
describe is the same issue.  Most menuing systems are the same, or 
close enough.  The worst case is some special handling, for shortcuts, 
or for allowing items to be checked inside the Menu (the Amiga had 
this, I loved it!).

But the code should look effectively the same.

Yes.

The cool function MIDAS had where the drawing functions, which kicked 
ass.


All drawing functions generated XY pairs, which could be embedded 
inline.


So a Circle on the C64 would make 320x240 based pairs, while the 
Amiga might make 640x480.  This made the functions very fast. 

You could also use this to make paths that objects could follow.

I suggest cheating. Start with this cool round menu and say "wel, 
platform lacks it anyway :)

Why GOB isn't a great name


Gob is commonly-used word in Britain and Ireland  Your Gob is your 
mouth. Gob Shite is a particularly Irish experssion to be used when 
somebody is talking rubbish. To Gob on somebody means to spit on 
them. A Gob refers to a portion of flem ejected from the mouth through 
the action of Gobbing (Spitting).

why not face! ?

short, known ...

Lets not try to rename GOB now. What's that going to achieve ? Confusion, 
fighting - we are not going to agree on a new one easily. Then, at 
the end, RT will probably not like our name. There are probably lots 
of docs with "gob" in them now. Renaming would cause rewriting them 
all. - Not worth it.

lot's of docs? What docs? :-)

Instead of arguing, I propose we spend our time doing something productive, 
like reversing caret-to-offset and fixing that long-standing issue.

of course we can't push Carl to rename it, but the truth it, that 
it sounds a bit weird :-) And we know that Carl cares for naming 
conventions, right? My proposition was - that if 'feel stays, we 
can stick to what we have - feel, face, facet ..... and if face is 
gone? Currently it is not a datatype, but an object, so my proposition 
was easy - juste let's doc that from R2 to R3, face became a datatype 
:-)

but as for me - the name is not all that important to me.

rebol already has some funny names, like 'attempt, 'feel, 'what, 
but if gob! has a negative connotation, perhaps it would be a good 
idea to look for something else. still, GOB is in family with BLOB 
and BOB and other data related words. What about GROB?

Bah - everything new is wierd.

anton, isn't this a simple matter of a search/replace in the global 
source tree of rebol 3? if there is a time to make a deal out of 
it, it should be now.

I agree with Anton on changing names. In fact, I have totally changed 
my mind about renaming REBOL or any parts of it. The reason is that 
it would make obsolete all the documentation, etc. It would be like 
throwing all that work away, and would cause terrible confusion. 
I was perhaps the most strongly in favor of a name change, but after 
thinking about it more deeply I've decided I was wrong. Also, I think 
that REBOL has been around long enough that a fairly long number 
of programmers have at least heard of it. And now that R3 is coming 
out, it is very likely that a lot of people will start to give it 
more attention. So this is not the time for change.

Louis - correct, and that is why I think it should be called face!, 
so the name would stay, it would just change its type from object 
to datatype :-)

but this is one word in R3... there are no docs yet on it. I would 
assume that the naming and design phase of R3 is not yet entirely 
complete. so if there is a time to rename things, this is the best 
time to do it.

in paint programms its called layer?

ah, layer, I like it. Most ppl working with photoshop or in general, 
will know it .... how is it called in web world? a box? (css)

I remember box in some old ZX Spectrum basic :-)

Well, if there are no doc yet, then a change may be in order. But 
for names already in docs I hold to what I said.

layer would imply that we have paint-functions like alpha. which 
we have :)

Anton, better now when all that needs fixed is RT's internal docs 
and source than hundreds of uses in the wild.  It really is an unfortunate 
name.  And there are some obvious replacements (over which there 
is no point in squabbling, we will not sway any decision).  Personally 
I think cell! or cel! would fit the bill.

face is not the same thing as gob.

vid will probably deal with faces, which in turn will refer to gobs 
for actual display.

a gob is just a graphic object, it does not contain a feel for example, 
and so on.

gabriele, how far is there from an image! to a gob! ?

(there are docs - not many, but not zero either. but i don't think 
that's the real problem with the change.) anyway... i'll tell Carl 
about this.