AltME groups: search

remember there is also a difference between skinning and actual GUI 
design, e.g. the layout of elements on screen. One can have a beautiful 
skin on an annoying interface. The same goes the other way around.

I'm just thinking about making sure we have identified the current 
use cases and have a way to build them.  I personally have no idea 
what is involved in building the GUI engine so if I am speaking out 
of line, I apologize.

About the new VID widgets look&feel, Carl stated at the DevCon that 
he would like to have something between Windows and OSX widgets look. 
So, I think that we could submit our own graphic design propositions 
to RT. A big image with a static example of each class of widgets 
would be enough I guess, "live demo" would be even greater. For the 
VID engine design, I'm trusting Gabriele's skills and his ability 
to gather the best ideas and feedbacks from the community. Anyway, 
if you don't like the upcoming new VID, nothing is stopping you to 
make your own one ;-).

Henrik, that's one of the reason i'd want to have automatic layout 
- most programmers are so bad at layout that even a program can do 
better if it follows good rules.

We should get someone to formulate some formal design rules into 
the engine of a layout dialect.

Gabriele, how high level would you carry auto-layout? I have myself 
thought about creating standard layouts, certain combinations of 
faces that are common, not just for yes/no dialogs, but, say, a two-pane 
or three-pane layout. Something that strongly encourages you to put 
a menu at the top, generic content in the middle and buttons at the 
bottom, where for example OK/Cancel/Retry buttons also are laid out 
in a specific sequence. Never got around to it though.

Silly example:

view layout [
  three-panel [
    menu [File Project Edit Show History]
  ] [
    ordinary VID code here
  ] [
    buttons [OK Cancel]
  ]
]

for now it seems that VID is just a bucket to randomly throw widgets 
in at your own whim. this should of course not go away, but higher 
level structures would be nice to have. there could be Dialog, Two-pane, 
Three-pane, Preferences (which provides a list in the left side and 
switchable pane in the right side).

anton, it's the same, just different wording. perhaps it would be 
better to say that several grouped panes would be a specific level, 
but a pane with menu/content/bottom button-panel could be an even 
higher level.

Oops I missed a level of nesting. Oh well, we agree on the basic 
idea.

in a sense, yes, but they are more complex than those currently defined 
in VID

It's a shame that menus have to be reinvented -- every system View 
runs on has a menu structure built in, and I'd rather use that than 
rolling our own.  Especially on OS X.  Our interface could be eg. 
a dialect attached to a window containing features common in menu 
systems: view/menu layout [...]["File" ["New" ["Document" "Template"] 
"Open" ctrl #"O" (does this) "Open Recent" get-recent-docs]]

I'd buy into hooking into native OS menus.  Ashley's menu widget 
is working out ok

in my small test passes so far.  But it was a fairly long wait and 
I did waste a good

week trying to track down a menu system before sticking with tabs 
for the FirM app.

And it presumes RebGUI will be an easy include for R3, and using 
RebGUI...

Java does a good job of making platform-specific menus with a cross-platform 
API that requires no changes. It may be good to look at.

The trouble is that it'd require an abstraction of the key features 
of all menu systems -- another excuse for delaying a new View.  Perhaps 
our representation is a dialect, though it might also be an involved 
object hierarchy, as faces/gobs are.  However, any effort to get 
this right will benefit every View application immeasurably thereafter.

gob! is such an unfortunate datatype name.  Is there no other word 
-- cell! atom! -- however innapropriate (I know Carl gives words 
careful consideration) that would make sense and be taken seriously 
in a verbal discussion?

gob (graphical object) reminds me of blob (blitter object) on Amiga. 
It's not a bad name, with atom or cell, the name is open do different 
interpretations, with gob, there's no confusion, you just have to 
learn it's graphical object. Maybe it's not self-evident but still 
good name I think.

blobs are binary large objects where I come from...but I like gob 
too.  My nerd brain

immediately thinks graphical object seeing gob!  And from an end-user 
perspective,

like showing code to a construction boss (or a new developer), they 
won't be dealing

in gob! until they are ready anyway.  (I don't think..same as struct! 
or bitset!).

OS menus? why that? It imo completly breaks View way of being a free 
form compositing engine. I don't agree with the idea at all ... Later 
on, such abstraction can be created ....

menus: may i propose that we keep menus out of vid in the first release 
(unless we can get to an agreement on them) and then we try to form 
a group in the community to propose a change to View to support them 
natively? Then RT can evaluate the change and decide what to do.

Chris - re gob! - it is short, but really feels weird :-) IMO it 
could be called face! - we were used to it. It could just be considered 
as faces are now a datatype and that those are organised in different 
internal way ... but imo there is no place for such change, the decision 
was made ...

a similar way to support system level menus could be added. then 
you can decide if you want to use that or create your own with gobs 
(we should provide them as a default style/whatever, but maybe it's 
something that can be left out of the initial july release... dunno)

there are various level of os-neutral... look at how java looks java 
and behaves java everywhere (and that's not always a nice thing)

during first run, I would welcome to have trouble free and extensible 
VID replacement, with most (all) of limitations/defficiencies of 
current model being fixed. For the july release, that is. It would 
not even have to fix them all with first release, but engine should 
be designed so it will allow us to finish it later in a good way, 
no hacks ...

if R3 is to take advantage of OSX GUI, it would have to be made compatible 
with .nib files, the file in which menus are stored. The GUI is a 
separate file in the application bundle.

..is there anything better/easier/welll-thought  than Interface Builder 
3.0 (Leopard os x) ? that is the only thing that make great looking 
apps for a programmer, qurtz composer, core image and now core video 
8-)

We cannot move forward until we can stop reinventing.


I kinda second that. My problem is, that I want a 'pure', simple 
and well thought out foundation to work from. I often find myself 
reinventing, because what's already there isn't good enough. A positive 
thing is, that REBOL is such a nice language to reinvent in, because 
there's a short way from idea to solution.


There was talk about menus. For Canvas RPaint, I built a menu-system 
from scratch. It's 5-6 k of REBOL source and means, that I don't 
have to reinvent menus any longer. Unless some customer wants menus, 
that looks and feels 100% as hosting OS. That's the downside.


When is something good enough, so we don't have to reinvent? Maybe 
progress comes from reinventing to some degree?

If the idea of REBOL in the long run is an OS (or virtual OS or whatever 
it's called), it might be a good idea to separate as most as possible 
from host OS.

Henrik, yes it's easy to implement the menu-system in other programs. 
You give it a datafile with a format like:
[
	"Picture" [
		"Load..." [off "^^L" []]
		"Save..." [on "^^S" [RPproc/save-picture]]
		separator []
		"Flip" [on menu [
			"Horizontal" [on action [proc/flip-bitmap-horiz]]
			"Vertical" [on action [proc/flip-bitmap-vert]]
		]]
...
and you have a menu.

Yes, that's the idea, when I can release Canvas for all versions 
of View. I plan to release info about developing such a monster in 
some way, maybe as a book, not sure.

Maybe it will be a good idea to do it as a book with a CD with all 
the building blocks for developers to use.

The format of the datafile is string - block, string - block, ..., 
as you can see. For menu-lines, the block holds
on/off - whether the menuitem can be selected or not (ghosting)

menu/action/string - king of menu-item. If a string, it's the keyboard 
shortcut.

block - for actions, it holds the name of the function to call. For 
menus, it holds the sub-menu.

A separator in a menu is made with
separator []

I think, this basic design can cope with all my needs for a menu 
system. The visual layout of it can differ. So far, I've made two 
versions, AmigaMenu.r which show it as original menus seen on the 
Amiga, and CanvasMenu.r, which is maybe a little nicer look.

pekr, I find it highly necessary, because of the aforementioned lack 
of high level structure. It's not a luxury, but meant as a guideline 
to how to make your program look and act. I've changed the structure 
of my programs over the years too many times, because there was no 
real way to standardize this. Every REBOL programmer must come up 
with his own standard for this, which IMHO is a lot of unnecessary 
work.

Henrik - who not let it just be a style? Just like tab-view is container 
for other stuff? You could start the hierarchy with - view layout 
[app-window split-window 3 [list-box .......]]

This is also nice menu: 

do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=menu-system-demo.r

Pekr, it's highly likely that people will settle for a guide, if 
one is provided with REBOL and it's made in a reasonable way. There 
is a reason why most OS'es have interface guidelines, namely to encourage 
consistency. The good thing with a guide is that you are not forced 
to use it, and it's not meant to restrict you, but help you develop 
your software faster, since all those design decisions are already 
made for you. If you want to build a custom dialog, it would be very 
nice if you have the basic arrangement already available, so you 
can settle for creating content for the dialog.

pekr, it _is_ a style. maybe we are just naming them differently 
and we agree after all. :-)

pekr, it probably depends on what type of UIs you develop. Is it 
large programs or just smaller scripts with a GUI slapped on? I see 
guides only as beneficial, when developing larger programs.

Should I do a screenshot of MS Outlook? And then some other app, 
using their dev. tool? Those look different in that respect! So, 
what I just said is - the trend is towards moving away from traditional 
looks, more so with inclination to web based like apps ...

Yes. And I don't agree with those design philosophies. :-) It may 
have something to do with those programs being so amazingly huge 
and have 2-digit sized development teams, so the program itself will 
reflect what the team is doing. MS is known to reinvent the wheel 
for each product. This is a bad trend.

If I try to make a MacOSX program in Cocoa, I'm actually pretty restricted 
in what I can do in terms of UI guidelines. I have to follow their 
menu system and structure. I have to follow their windowing system 
behaviour. I have to have an icon in the dock and I can do certain 
specific things with the icon. If I choose to, I can even let MacOSX 
handle loading and saving of data and preferences for me and handle 
the aspect of multiple documents for me.

I could probably code my own stuff, but since Apple have spent years 
designing these UI elements and guidelines, I see no reason to do 
that, since it provides a high amount of consistency. It's actually 
pretty hard to make something that looks shoddy or amateurish, unless 
you start drawing up your own graphics elements and ignore existing 
guidelines, which would be a huge waste of time. MacOSX is exactly 
being touted as being a fast environment to develop in, because many 
of the tough design decisions have already been made.

Henrik, the link above state exaclty what you say: The NIB (stands 
for NeXTStep Interface Builder) file is a loosely coupled, standalone, 
user interface definition. It wouldn't make sense to double-click 
a button and immediately be taken to a code-behind. Instead, you 
have to create a controller class, and then ctrl-drag from the button 
to the controller and then pick the outlet you're going to use (something 
like click: or calculate:). To me, as a huge fan of the MVC pattern, 
this makes perfect sense. And it seems so elegant in its simplicity, 
and so incredibly cool in the fact that it is truly enforcing good 
design simply by the way the IDE works.

why? it's simply adding a layer above VID to guide how to handle 
certain dialogs and multiple groups of widgets. it doesn't have to 
be more than a few kb's of code in total.

think of it as a layer above VID as VID is a layer above View. imagine 
how it would be to code layouts without having VID in REBOL...

well, I wouldn't mind seeing a way to store UI skins centrally, so 
there would be a way for the user to customize it, like you can with 
MUI on a per application basis.

Between Cyphre, Geomol, and Christian, we have three solid menuing 
systems to analyze as prototypes. If someone wants to write an interface 
to native OS menus, that can probably be written as an extension 
to R3. The only critical thing would seem to be the ability to attach 
an OS menu to a REBOL window.

Petr, just to be clear, system menus are OS neutral.  Every platform 
that View runs on has a menu system that is essentially the same. 
 The mode of access may be different platform to platform, but how 
different in function is a Windows menu to an OS X menu to an Amiga 
menu?  All I would like is a standard way to utilise them.

Let's specify menus with a dialect that does not assume where they 
will be put, and then implement that dialect in a platform-specific 
way, with a cross-platform REBOL native fallback.

This seems to me a similar issue to using native file requesters. 
 Why reinvent a complex pattern in a way that is substandard and 
unfamiliar to users?

(and 'substandard' is not meant as offence to those that have developed 
such styles in View, but when you replicate a WinXP menu, then deploy 
on OS X, it looks substandard)

I would only have the REBOL native style be the default on platforms 
that don't have a decent native style. That means platform-by-default 
on OS X but perhaps REBOL-by-default on Windows - there's a reason 
that MS uses custom controls on Windows. Let the platform implementor 
decide the default.

It's not just View apps that suffer in this way -- Inkscape is a 
formiddable application that looks at home on Linux, looks patchy 
on Windows and looks like an emulator window on OS X.

Because trying to do it in a cross-platform way can be very complicated 
and force you into a lowest common denominator scenario. The question 
for me comes back to whether you're trying to emulate a native OS 
look in general or not. If you are, then the menus should match; 
if not, the menus won't match your app. And given that every web 
site seems to have a different nav system and menu look these days--and 
people seem OK with that, even if it's not good UI, and doesn't leverage 
existing knowledge--it's not a problem.

If you create a slick OSX look for your app, do you want a W2K menu 
attached to it?

Text description and a hot-key?

Breaks?  Which applications exploit more than these and how much 
of a benefit does that bring?

But then I prefer a mouse to a keyboard (hand injury).

Office 2007 does have some rudimentary menus.  Just not a menu strip.

It wouldn't work on my cell phone though - no mouse, no touchscreen, 
just a keyboard, action keys and a navigational pad.

At one point I started working on a generic app framework, and may 
revive it at some point.. On the menuing front, the idea is that 
an app has various "actions" you can trigger, and which may be represented 
on a menu. e.g. 


browse-hq [id: 'browse-hq text: "REBOL" action: [browse http://www.rebol.com]]

run-core  [id: 'run-core  text: "Core"  action: [call-str %/c/rebol/core/rebol]]

run-view  [id: 'run-view  text: "View"  action: [call-str %/c/rebol/view/rebol-link]]
run-shell [id: 'run-shell text: "Shell" action: [call "cmd.exe"]]

quit      [id: 'quit      text: "Quit"  action: [quit]  hot-key: 
#"^q"]


Then creating a menu is basically just listing the actions that should 
be on it.

run-menu-v [
    browse-hq
    -
    run-core
    run-view
    -
    run-shell
    -
    quit
]


Commands (actions) could be loaded in contexts, and you can reference 
them specifically if you want.

run-menu-h [
    [horz]

    browse-hq | run-core run-view | test/run-shell | test-2/nested-obj/quit
]

A menu dialect is more the REBOL way, anyways.

Again, what I propose is a way to manage system menus as a core part 
of View.  Effectively it'd be view/menu layout [...] [... menu spec 
...].  On Windows, this would attach a OS menu bar to your window 
(as optional as having a window title bar).  On OS X, it would enable 
functionality on the OS menu bar specific to the viewed window.  
This way, you have a familiar, cross-platform though native-integrated 
menu system.

Of course -- you can reinterpret any dialect in Rebol.  But priority 
would be on a dialect that works with native menus.

I'm more thinking of a way to register a standard dialect (I believe 
R3 has such a thing - implied by Carl's slides). Then let the platform 
implementor register the default dialect implementation, and let 
the developer register their own alternative for their app if they 
like.

On platforms with decent system menus, yes. That should be deicded 
on a per-platform basis. This dialect would be for specifying what 
to put into the menus, not how to do it. The dialect implementation 
would be doing the work.

Don't get me wrong, I'm all for choice.  But the shortest route should 
bring you to the most intuitive features first.  Imagine downloading 
Rebol and in a one liner create a UI that utilises system menus/requesters.

I can type -- request-file -- on any fresh View installation and 
have a fully-featured file requester that a user of that system would 
be familiar with.  I want the same with menus.

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 ....

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.

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.

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'.

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

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

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.

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)

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.

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.

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).

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.

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

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?

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.

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.

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)

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.

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! ?

image! to gob! - they're completely different. a gob is a C structure 
that holds the necessary information to display something, like a 
piece of (rich) text, or a shape, or an image.

gobs are also arranged in a tree, similarly to how faces are.

face is the closest thing to a gob, but a gob is a much simpler object 
than a face. n gobs may be needed to obtain the functionality of 
a single R2 face.

I wonder why its not obvious to people that a gob is a single draw 
stroke.