World: r3wp

That's RT's problem, not mine.  (figuratively)

Well, once R3 comes out, the community will be helping with the platform 
implementation - RT will be focusing on the core of REBOL, and that 
has no UI at all, just an API. Remember which group you are asking 
this question in.

I'm more in the platform implementor camp. I rarely need to write 
UIs, but I need to write UI toolkits on occasion.

I understand that, and that's a good thing.  But try advocating the 
Rebol language with these nuances.  "It's write-once, run-anywhere, 
except that feature, you're going to have to build that yourself 
on this Linux distro"

No, I'm saying that for end developers REBOL will be write-once run-everywhere-applicable, 
but to make that happen the platform implementors will need to do 
a lot of planning and work. If you, as an end developer, still want 
to roll your own menus or have none, then the platform implementors 
need to take that into account as well and not hard-code their menu 
implementations.

And if you want to run some Linux distro that is not running Gnome 
or KDE, or even X, then you may have to come to terms with the fact 
that Linux doesn't have standard system menus, or any UI at all. 
All that is provided by the toolkits, and if you are not running 
one of the toolkits that REBOL has been ported to already, then you 
will either need to switch platforms or become a platform implementor.

You don't get me to system menu, never. That will be absolutly ugly. 
I would agree to that only in a sense of REBOL-as-a-tool menu, kind 
of menu as REBOL console has. Can you imagine general VID UI design, 
or even RebGUI design (which is much more OS-look friendly), to have 
system native menu? That would destroy look of an app imo. And as 
I said - many new apps go for more free-form UI ....

And that doesn't even take my cell phone or bootable REBOL into account. 
I will run REBOL on my cell phone if I have to port it myself.

Petr, yes I can imagine it.  A system menu would be more appealing 
to me eg. on a RebGUI app than a RebGUI custom menu.

See, Pekr's in the roll-your-own camp. I'm in the make-the-ui-fit-the-platform 
camp, even if that means changing the paradigm altogether.

those of you who want OS native look, go and link Core to OS, easy 
as that imo. REBOL should have its own style, cross platform. IMO 
slight difference to OS is exagerrated, if substystem works in compatible 
enough way - common shortcuts, etc. And those who say otherwise, 
are exagerrating too. And if MacOS-X ppl are refusive to slightly 
different apps, then those are intolerant freaks.

I will run REBOL on my cell phone if I have to port it myself.
 - that should be my sig :)

Brian, I'm not sure how many View apps would work on a cell phone 
anyhow.  View is so literal that I've had problems running apps on 
800x600 screens because the author has a bigger screen.

Petr, it isn't about OS X users being intolerant, rather it is about 
production quality.  Most roll-your-owns are inferior to the OS default.

And that reflects on the impression an app makes.

Differences in operating systems may not be much, but differences 
in modes of interaction between different platforms can be immense. 
It would be inappropriate to run View at all on my cell phone - no 
mouse, no touch screen. But you can still do UIs, just different.

Then why are you suggesting that my Views apps be limited by that?

Chris - OK, but where do we end? Mozilla uses XUL, IIRC Firefox linked 
to native widgets. Then let's scrap View - what is it good for? Just 
use Core, link to OS, fair enough - no custome styles? Why those, 
if target OS does not provide them? What comes next? Someone shooting 
fields looks ugly too? Look at html forms - 1 think line fields are 
modern. Non shadowed. We will end with hybrid.

Regardless, I've made an argument in the past that View be less literal, 
and open to interpretation by different media.  Hence a 'CSS approach'.

1 pixel thin line ...

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? :-)