AltME groups: search

Louis - yes, and - some of guys are for years begging for suggestions 
in certain areas, not being sure those are being heard and implemented.

4 - 6 months ago I asked in one blog reaction, Carl to blog about 
the plan towards View itself. IIRC it was supposed to come, and that's 
it. Some things were not decided even at the time of devcon (e.g. 
if draw dialect will merge with effect one). View kernel development 
seems to be implemented with no certain vision - we just know we 
wanted richtext, and view being less resource hungry and faster in 
blitting :-)

Lets change that aspect then Pekr.  A formal group, with the associated 
sense of

authority...that may or may not be ignored, but it'll be 'authoritative' 
and hopefully

less ignorable.  But for Gabrieles immediate need...I say let the 
snowball roll  :)

Brian - I understand your motive for such group. I even understand, 
that it could work, but - there is one thing needed for sure - RT 
to respect such body. And to actually respect it for more than few 
months :-)

what did this bring you?

1) I clearly feel (in most of people who post) that there is a sense 
of uselessness of the community that needs to be addressed.  I am 
not talking about specifics.  just a general sense of being ignored. 
  for my part, I expect it so am not bitter.  I just hope for the 
best, in any case I can already just use gobs and ignore view3, I 
have my engine pretty much finalised and working within an app.


2) communication FROM RT is insufficient.  having you as an official 
RT person will most probably change that, cause I regard you highly 
in your communication talents.  you genuinely want discussion  :-)


3) more specifically, people do not ONLY expect/want a PITS model 
for the gui,  

4) people want more access to internal without fighting,  


5) it seems to me that the community is not expecting a quick release 
of VID and some have expressed that they'd rather wait a bit for 
it than get something too simple.


6) there seems to be disapointment that RT will be feeding us the 
solution, I think after devcon I feel that a few people would have 
tought it would have been a bit more community driven, but then, 
that could be more my skewed vision.

That would have to be determined.  I say it's worth a shot.  It can't 
be any less 

effective than what we have today.  None of us can dicate to RT, 
just hope and
wish and dream, and maybe report (back and forth)  :)

But because of that nature, Rebol lived in the PITS area .... we 
are quickly done with ideas :-) That is fine ... but that is the 
paradox too - it lead us to situation, when we are not used to work 
on longer term things ... maybe the only one being rebol.org group, 
rebgui, and now rebolweek group - kudoz to those ppl.

I am often fascinated at how people forget about steel  :-)   ... 
its been there for what 5 years, and has steadily improved.  but 
just like RT I am one man army, so community is deficient  :-(

And I truly believe we are pretty lucky.  The blog may seem a little 
one-way, but Carl

does respond.  And though maybe not verbalized, those tidbits probably 
are having

an influence.  At least that's the impression I've been getting over 
the last few months of

my reinvolvement in the field...and it seems to be getting better 
everyday.  And I've 

discovered that unless you put in four hours a day...the amount of 
information generated
is impossible to keep up with.  :)

you seem to be able to counter both pekr and my negativity quite 
well.  ;-)

the difference I think is in how information flow to and back.  proximity 
removes the need for a lot of structure, yet it also has some drawbacks. 
 distance doesn't allow much to happen without structure and time.

I have applied.  And yep...most coders are far more removed from 
the designers....

brian, know that you have been promoted by me directly to Carl.  
I explained about your good natured humour and capable work habbits.

Its possible next time, we should start with a more "specific" topic, 
so it doesn't stray to far... I think the main issue here was that 
there was no real direction at its outset.. it was mainly... ok, 
tell me anything... and it just flowed that way.


now that its out, its done.  we should now concentrate on specifics. 
  :-)

I got Max's summary, and will watch this group for more. If you want 
me to collect yours, please post it in this color so I can find them 
easily.

max, well, i wasn't looking for input today, since we have nothing 
to comment on yet. i just stated that i wanted to have input on vid 
as soon as i could show something to give input on... and this is 
the reaction i got :)

I would like to be a part of the early access group, but not for 
VID. My GUI experience is founded in quite different environments 
and my input about GUIs would be more along the lines of API cleanup 
and other low-level stuff. For the major design issues, I defer to 
Carl, Gabriele, Cyphre and the other capable people here - I trust 
your judgement.


I would like to help with some of the other parts of REBOL 3 though. 
My main interests are in language design, interoperability issues 
and platform integration, particularly Windows platforms and derivatives 
since that's what I need to use most of the time.

And rebcode? ;)

as long as the GOBs in R3 allow event trapping and event redirection 
ill be happy :)  Also some info on the planned / implemented? Richtext 
layer would be appreciated

And I look forward to trying it out.

Do we need a GUI designer to join us with regards to the next VID 
implementation?  Would Carl be willing to pay for the services of 
a designer?  I know a few guys who work for the local office of Adobe 
and do interface design for their products.

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

reflective user interfaces, that is, ones that are able to edit themselves
 ... are such changes able to be saved, and if so where?

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

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

Which and how many patterns?  Can we create patterns without low-level 
code, and are the layouts managed after the point of composition?

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

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?

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

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

keep in mind that R2 already supports the system tray in windows, 
and the way it does could be easily used for the same thing on linux 
kde or gnome.

hmm, difficult decision. IMO we have to start with new VID and its 
design first. Then we can hook platform specific things. E.g. I am 
curious, what you think how rebol uses native OS dialog windows for 
each "view/new" .... that e.g. becomes trouble with plug-in. Would 
anyone welcome rebol (VID) level windowing?

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)

java is extremely slow at gui...an application I used which used 
their layout engine and graphics would take 2 second on my computer 
when resizing the applicaiton.  just for fun, I built the same layout 
in glayout (VID) and it would resize in .1 seconds (on the same computer).

so java really sucks at GUIs.

Gabriele - but that is the exact problem, no? There was plan to limit 
amount of opened dialog windows to e.g. 5 of them. And then - it 
looks ugly, if your app is placed in browser container and suddenly 
there is dialog window popping up, which is added to your OS app 
bar, and what is worse, it can be catched by ad-block tools. That 
is what could be imo solved by VID level windowing ...

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

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

http://chanson.livejournal.com/tag/interface+builderand http://rubycocoa.sourceforge.net/Documentation

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?

The question is whether we want to integrate into the OS or not? 
Almost each OS does menus, systray notifications and window handling 
differently.

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.

nice and simple. are you going to publish it?

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.

my preference is to have general enough VID ... and I don't agree 
to e.g. separate multi-pane window, menu, etc., into another layer 
... it is not imo necessary ...

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 - but I can imagine more than 10 such styles, how you build/divide 
canvas for your app :-( And last years, we have apps appearing, which 
simply don't adhere to some system rules anymore ...

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

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

but I think we just want the same ;-) My intention is just to have 
it available as nested styles, no new concept, if we can make it 
that way. But some aspects of certain look & behavior could be rebol 
specific and cross platform imo.

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.

I've seen it, and I hate it.

And when we talk about split-window (app-window), we can even talk 
about native VID windowing :-)

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.

well, listening to raising requests to be tight to os-native widgets 
(not only windows behavior), I start to think that it would be better 
to scrap View altogether, and to go with some other UI toolkits, 
as gtk, qt, or simply to wrap OS ones ;-)

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.

.... and ... not sure it is possible or if it would be vital, but 
Chris requested future VID being CSS like, simply put that widgets 
would be separate from styling. But not sure it is possible. The 
trouble is, that once layout is decomposed into view objects, there 
is no way back. There is nothing like DOM ....

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.

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)

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.

Text description and a hot-key?

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

I think this chat also applies to the general interface to apps, 
and how you expose commands. e.g. how you would programmatically 
control an app; think ARexx.

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
]

Yep.  And if something more complex is required, roll-your-own.

We're talking about 2 different things here. The dialect would be 
the same cross-platform - the implementations would be different. 
You could roll your own implementation of the standard dialect. You 
could even ignore the parts of the dialect that have no equivalent 
on your platform, so lowest common denominator can be set pretty 
high, particularly if some features are declared to be optional. 
You could even embrace-and-extend the standard dialect with your 
own extras in your implementation.


Or you could go the Office 2007 route and change the paradigm - new 
dialect.

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.

Or the developer could ignore the menus altogether and go with something 
completely different, not menus at all.

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.

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

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.

And that reflects on the impression an app makes.

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

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

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

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

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

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)

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

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.