Re: [9fans] Evolving rio / GUI development

Re: [9fans] Evolving rio / GUI development

[Ben Huntsman]

Just a joke, my friend.  I knew that.

>>> George Gensure<werkt@csh.rit.edu> 2/22/2005 10:12:51 AM >>>

>yet, motion graphics of sign-language.  That way, it'd be truly universal. har har.
>  
>
Sign language differs not just by spoken language, but also by country 
and region (ASL vs. BSL), with dialects changing often more starkly than 
does spoken and definitely than written language.  Not exactly a 
universal solution.

-George

Re: [9fans] Evolving rio / GUI development

[Ben Huntsman]

I've got an idea: what about having "icons" be Egyptian... or better yet, motion graphics of sign-language.  That way, it'd be truly universal. har har.

Is it just me, or does this look like it's going to turn into a flame war really quick?

Re: [9fans] Evolving rio / GUI development

[George Gensure]

>yet, motion graphics of sign-language.  That way, it'd be truly universal. har har.
>
>
Sign language differs not just by spoken language, but also by country
and region (ASL vs. BSL), with dialects changing often more starkly than
does spoken and definitely than written language.  Not exactly a
universal solution.

-George

Re: [9fans] Evolving rio / GUI development

[Brantley Coile]

> I've got an idea: what about having "icons" be Egyptian... or better yet, motion graphics of sign-language.  That way, it'd be truly universal. har har.

What do Chinese use as icon?

  Brantley

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Ben,

Tuesday, February 22, 2005, 8:06:01 PM, you wrote:

BH> I've got an idea: what about having "icons" be Egyptian... or
BH> better yet, motion graphics of sign-language.  That way, it'd be
BH> truly universal. har har.
Maybe future people say: 'Ben Huntsman - great programmer of 21
century, which first suggest use motion graphics, which we use
nowadays...' ;-)

BH> Is it just me, or does this look like it's going to turn into a flame war really quick?
It's right, we need stop that!

I found frame(2) useful for writing gui (typescript) program, I try it...
I sure we not need any changes in Acme or other program, we just need
new program and toolkit for it's creation (maybe frame(2)/libcontrol)...
As result I can say I change my opinion in some part...
It's Plan 9 style and this great!

The End?
--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> I found frame(2) useful for writing gui (typescript) program, I try it...
> I sure we not need any changes in Acme or other program, we just need
> new program and toolkit for it's creation (maybe frame(2)/libcontrol)...
> As result I can say I change my opinion in some part...
> It's Plan 9 style and this great!
>
> The End?

Is this a black joke?

Kenji

Re: [9fans] Evolving rio / GUI development

[andrey mirtchovski]

>> The End?
>
> Is this a black joke?
>

I think Sergey meant to say "I like the Plan 9 way now, we can end the
discussion".

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Andrey and others

Wednesday, February 23, 2005, 4:34:45 PM, you wrote:
>>> The End?
am> I think Sergey meant to say "I like the Plan 9 way now, we can end the
am> discussion".
Yes, like that... This is 'The End' for me in this thread, because
this thread not produce any 'reasonable output'...

The End of End ;-)
--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Kenji

Wednesday, February 23, 2005, 10:28:20 AM, you wrote:

KO> Is this a black joke?
Not understand you... please explain... what you mean?
Maybe you can't understand my English... sorry...
--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> KO> Is this a black joke?
> Not understand you... please explain... what you mean?

I've been feeling negative sense from your posts here, and finaly
you wrote it, then, I responded such.   Now, I suppose it was my
miss-understanding.

If you are Rob/Russ/Jim/Dave whom we know are contributors of Plan 9,
and write sometime negative, it'll never happen though, then, I can
accept it sincerely.   However, ...  this is the real point I responded
such.

Kenji

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Kenji

Thursday, February 24, 2005, 3:04:57 AM, you wrote:
KO> I've been feeling negative sense from your posts here, and finaly
KO> you wrote it, then, I responded such.
8-| negative?

I don't want to change rio... maybe only add some (little, as ALT-TAB)
stuff...

I found textual interface useful too, but I am sure others type of
interfaces (user) can live in Plan 9 too. Creating libcontrol proved
this... but it need to be improved... or porting libtk...

libframe is like toolkit for creating textual interfaces, and I say:
I try it...

KO>  Now, I suppose it was my miss-understanding.
I try writing more carefully, and this not happen again...
--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Ronald G. Minnich]

you have not lived until you've seen 4 year olds who can barely do their
ABCs navigate all the windows icons such as "open file", "close file",
etc.

Imprinting.

ron

Re: [9fans] Evolving rio / GUI development

[YAMANASHI Takeshi]

> window)... At least we need something like Atl-TAB to change active
> window by keyboard...

Plan 9 is the first environment that taught me how to use mouse properly.
I was once a lover of Alt-Tab window switching too, but I just don't need
that now and click at the target window, keeping all windows shown on
1280x1024 desktop and hiding them rarely.


> What need to do people who have only 800x600?

use smaller fonts maybe? :)
--

[9fans] Evolving rio / GUI development

[g01495]

9fans,

I have some questions and some points -- I am interested in the
general consensus regarding interfaces to computers in general and how
Plan 9 fits into this.

There currently exists a large contrast in the way interfaces are
presented on different operating systems.  "modern" operating systems
such as GNU/Linux, Windows, MacOS provide an interface largely
disconnected from the underlying operating system.  They also put a
great deal of effort into cosmetic changes, and are beginning to use
hardware acceleration of the GUI using OpenGL framebuffer cards.
Ideas like three dimensional interfaces are counterproductive as the
paradigm can't be applied to the current technology.

rio on the other hand provides a minimal interface to the applications
on the system.  I believe this is the right thing to do, but I believe
some things are missing.

The idea of an interface itself is very complicated and difficult to
develop.  The general idea hasn't really changed in decades.

I find rio very usable, but I also find I spend alot of my time "using
rio".  When I say this I mean moving windows, organizing the screen,
hiding windows, resizing things.

Where will rio (or it's successors) end up going?

What does everybody else think about this?

Re: [9fans] Evolving rio / GUI development

[Russ Cox]

> I find rio very usable, but I also find I spend alot of my time "using
> rio".  When I say this I mean moving windows, organizing the screen,
> hiding windows, resizing things.

This is interesting.  Why don't you find yourself spending a lot
of time using the other window managers?

I wonder if it is similar to the reason people find themselves
spending a lot of time using the mouse but not the keyboard:
the mouse is easier to use so your brain is free to do other
things like wonder when you'll be done.

(Argument about mice vs. keyboards can go to /dev/null.
We've already been through that multiple times.  Here's one:
http://lists.cse.psu.edu/archives/9fans/2002-April/016946.html)

Russ

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Fans,

g01495> I find rio very usable, but I also find I spend alot of my time "using
g01495> rio".  When I say this I mean moving windows, organizing the screen,
g01495> hiding windows, resizing things.
I use riostart to setup my workspace (other word in English to say this?)
1. acme -l $home/acme.dump
2. stats -lm
3. clock
4. taskbar
And I can use this four(!) window for full work. If I need shell
window I just right click on my taskbar, work on it and then kill
it... As I see people who develop winwatch and rio never manage many
window too.

g01495> They also put a great deal of effort into cosmetic changes, and are beginning to use
g01495> hardware acceleration of the GUI using OpenGL framebuffer cards.
How much people work on Plan 9? Who can do this (and who have time for
this)?

g01495> The idea of an interface itself is very complicated and difficult to
g01495> develop.  The general idea hasn't really changed in decades.
What you can suggest? Use 3D desktop? In 2D display?

RC> This is interesting.  Why don't you find yourself spending a lot
RC> of time using the other window managers?
Because other more advanced (more friendly to user).

RC> I wonder if it is similar to the reason people find themselves
RC> spending a lot of time using the mouse but not the keyboard:
RC> the mouse is easier to use so your brain is free to do other
RC> things like wonder when you'll be done.
With 99% accuracy may say: people who read this, usually use keyboard ;-)

RC> (Argument about mice vs. keyboards can go to /dev/null.
RC> We've already been through that multiple times.  Here's one:
RC> http://lists.cse.psu.edu/archives/9fans/2002-April/016946.html)
I found keyboard very useful, but when I can (like in OS Windows ) all
task do with keyboard or mouse it's great, but when some task I do by
keyboard and some only by mouse it's very hard (example: hiding
window)... At least we need something like Atl-TAB to change active
window by keyboard...

SS> I beleive a lot depends upon what resolution you run the display at,
SS> I run at 1080x1024 which is just enough. 1024x768 on my laptop is painfull
SS> Ideally I would run at 1600 odd but my monitor just isn't sharp enough.
What need to do people who have only 800x600?

AM> i rarely manage rio either. i do much more 'managing' of windows
AM> inside acme, where there are some strides made with automatic cursor
AM> placement and windows resize. i suggest you look there for
AM> inspiration.
Interesting idea! If acme can handle Image it can be used for more
things... why it don't do it?

Other thing which I wont add to this post:
We need port of libtk or equivalent for Plan 9 (previously to say "we
have libcontrol" firstly try use it).
When we have complete GUI we can faster develop application!
--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[McLone]

On Wed, 16 Feb 2005 21:15:57 +0200, Sergey Reva <rs_rlab@mail.ru> wrote:
> How much people work on Plan 9? Who can do this (and who have time for
just look on Freedesktop's cairo -> glitz -> (debrix|xserver) -> DRI
and u'll understand.
Sure they [still] have monolithic tree, XAA drivers and such.... but
i'm telling it's not easy to do now, at least from HW support PoV.

> RC> This is interesting.  Why don't you find yourself spending a lot
> RC> of time using the other window managers?
> Because other more advanced (more friendly to user).
complicated configs != user-friendly
simple/mainstream ones ~= unuseable IMO

> SS> Ideally I would run at 1600 odd but my monitor just isn't sharp enough.
> What need to do people who have only 800x600?
w00t? 800x600 nowadays?
* You must be kiddin'. Even used cards/CRTs can do 1024x768x75+hz!
* Turn it on, work couple'o'hours, then report. [different OSes]

--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

>> Because other more advanced (more friendly to user).
M> complicated configs != user-friendly
Most of modern GUI have gui configurator

>> SS> Ideally I would run at 1600 odd but my monitor just isn't sharp enough.
>> What need to do people who have only 800x600?
M> w00t? 800x600 nowadays?
M> * You must be kiddin'. Even used cards/CRTs can do 1024x768x75+hz!
M> * Turn it on, work couple'o'hours, then report. [different OSes]
Now I work at 1024x768@85Hz (CRT 17"), and my hardware can do more.
I got this hardware only in 2004... It's still many users who can work only at
800x600 in 14"-15". But may be you right - we need look to future...

KO> Young and talented programmer can try this, however, it must be painful
KO> and brain consuming thing I think.
Many programmers can do this, but after his work we get many
incompatible GUI's, as result we got manu programs, may be good but
uses different gui library...
I see this in Linux. I have three variant of any program (mean gui
program): one for KDE, one for Gnome and one which not use this library... (maybe i mistake somewhere?)
--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> I see this in Linux. I have three variant of any program (mean gui
> program): one for KDE, one for Gnome and one which not use this library... (maybe i mistake somewhere?)

To me these things look like same, but just variants.

Kenji

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

So what we do now?
How it need look this new gui?
As library or as server?
Skined or most simple and fast?
Control library + window maker or all in one?
Or just improve libcontrol and stop on this...

--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> So what we do now?
> How it need look this new gui?
> As library or as server?
> Skined or most simple and fast?
> Control library + window maker or all in one?
> Or just improve libcontrol and stop on this...
>

how about no new gui
the old one ain't smellin' yet

Re: [9fans] Evolving rio / GUI development

[Ronald G. Minnich]

On Thu, 17 Feb 2005, Tiit Lankots wrote:

> how about no new gui
> the old one ain't smellin' yet

well, you folks all seem to be able to fit all your windows tiled. I just
plain can't. I've to two 21" LCDs and with the CAD systems etc. I use
there's no room at all to tile everything. It just doesn't work, hence my
need for multiple desktops and other such things.

With multiple desktops, as much as I like rio, I find it easier to use
flwm and swap around with CTRL-F[1234] etc.

So, yes, rio is a fine and wonderful thing, but I don't buy it as the
be-all and end-all of window managers.

YMMV is always the case.

ron

Re: [9fans] Evolving rio / GUI development

[boyd, rounin]

> YMMV is always the case.

hide & /dev/label

;)
--
MGRS 31U DQ 52572 12604

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> YMMV is always the case.

My (somewhat sarcastic) comment was more referring to the probability
that no excellent new idea will likely be unraveled here, so
nothing will be (re-)implemented, either. Plan 9 has a strong intrinsic
opposition to change; this is mostly good beacuse of obvious
reasons. But some experimentation would'nt hurt. I just can't see the
mechanism of this happening, short of reimplementing the whole shebang.

Re: [9fans] Evolving rio / GUI development

[Russ Cox]

> My (somewhat sarcastic) comment was more referring to the probability
> that no excellent new idea will likely be unraveled here, so
> nothing will be (re-)implemented, either. Plan 9 has a strong intrinsic
> opposition to change; this is mostly good beacuse of obvious
> reasons. But some experimentation would'nt hurt. I just can't see the
> mechanism of this happening, short of reimplementing the whole shebang.

The mechanism is, and always is, someone writes code.
Of course, that's not nearly so easy as whining on 9fans.

Russ

Re: [9fans] Evolving rio / GUI development

[Fco. J. Ballesteros]

> Plan 9 has a strong intrinsic
> opposition to change; this is mostly good beacuse of obvious
> reasons. But some experimentation would'nt hurt. I just can't see the

Then just go ahead and experiment!

These days we run what we call Plan B. That's an experiment
on Plan 9, the system behaves differently and we're learning
what we like of the system, and what we do not. In particular,
what we like is that the system mounts resources automatically
and that it makes it easy to adapt to changes. What we don't like
is mostly that during the auth stage, a missbehaving fileserver may
lock your system.

Before this, we experimented with redirfs, which was a previous attempt
to do this at user-level, and it didn't quite work, because not all files
were automatically mounted and failover could fail :-), doing this in the
kernel has simplified things a lot.

Regarding the UIs,
we have what we call omero (another experiment), it's a mixture of
a window-toolkit and a file server, that handles all the graphics by
its own. The application creates files to build its UI, and the fs takes
care of the mouse and everything else. This allows you to replicate
and move around UI components without placing the burden in the
application.

During the construction of omero we tried two nice experiments, one
was mouse cooked mode, which I now consider as a mistake, after
experimenting with it. The other, which I consider a big success, is
defining the left control, start-button, left-alt as mouse 1, 2, and 3 buttons.
We use the menu for composing (old alt), and capslock as control.
This made it very nice to use 3-button interfaces (like acme and omero)
in laptops.

Probably sometime this year we'll consider both the system and omero
stable enough to try and talk about how to bring this stuff into Plan 9, if
anyone cares. Even if others consider that it's not worth placing this
kind of stuff in Plan 9, some things might still be useful, like the mouse
buttons thing.

My point is that experimentation is a good thing, so go ahead. Of course
it's perfectly nice for others to say `we won't use the resulting code', but
that's why it's an experiment, isnt it? It may also be that those that
refuse to use the resulting code might teach you a better way of doing it,
which is even better.

good luck

PS: Sorry about the long mail :-)

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> Then just go ahead and experiment!

Perfectly sound advice, given an ideal universe. Alas, in a realistic
universe, there
	a) are only 24 hrs in a day, of wich I'd like at least 8 use for sleep;
	b) is a little 3 year old girl I can't tell
	"sorry honey, no playing as of today, daddy likes plan 9 more now"

I envy peope who actually have time to spare.

P.S. Sorry for the rant. Feel free to disregard.

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> Regarding the UIs,
> we have what we call omero (another experiment), it's a mixture of
> a window-toolkit and a file server, that handles all the graphics by
> its own. The application creates files to build its UI, and the fs takes
> care of the mouse and everything else. This allows you to replicate
> and move around UI components without placing the burden in the
> application.

How do you think that recent GUI programming style is too difficult
to understand for non-computer science students.   We need GUI
only for user interface, and it should be very easy to deal with, and
can be used from all of the languages without special enbedded portion
of those tools.

Once upon a time, programming was a fan for many scientists because
it was not so difficult.    They have to just care of the precisenenss of
their own parts.   Now a days, I think most of them are buying some
commercial products and students don't know how to make it from
scratch.   It will soon make this world darker I fear.

Does your Plan B help such?

Kenji

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

GUI is a term invented by people who sell them.

i was very impressed in the mid 80's that my secretary
at the labs totally embraced the mux/jim jerq that was
put in front of her (maybe it was 56xx).

(mux/mpx -> rio, jim -> sam).

i knew the lads were on to a good thing.  I think seeing
a face when e-mail arrived made the entire building more
efficient.  e-mail was more efficient than a phone call.
i don't think i ever called a co-worker in those days
except for a "I'm really hungry, you said dinner was on".

20 years on i am using programs which i know are
technically very goood and useful (i'll quote adobe audition).

ok, i'll rant on.  HST is gone so someone has to do it.

audtion is quite useable - i've been doing a soundtrack with it,
but open it up and you have half a dozen mysterious windows
and even more click on menus up the top, many options
being sub-menus and so forth.

now if it was written in a different thread of software development
then it would be a small window in rio with a small menu to
open/save/etc.  great, i choose "wave" from the menu and get to
sweep out a wave window.  just what i wanted. it has an
appropriate menu.  etc.  i choose "multitrack" i get something
more complex which will need very specific mouse interaction ...
but plan9 has no problems with that.

such windows need GUIs - dragging a selection on a wave,
but it's kinda different huh?

end of rant.

brucee

On Mon, 21 Feb 2005 11:54:16 +0900, Kenji Okamoto
<okamoto@granite.cias.osakafu-u.ac.jp> wrote:
> > Regarding the UIs,
> > we have what we call omero (another experiment), it's a mixture of
> > a window-toolkit and a file server, that handles all the graphics by
> > its own. The application creates files to build its UI, and the fs takes
> > care of the mouse and everything else. This allows you to replicate
> > and move around UI components without placing the burden in the
> > application.
>
> How do you think that recent GUI programming style is too difficult
> to understand for non-computer science students.   We need GUI
> only for user interface, and it should be very easy to deal with, and
> can be used from all of the languages without special enbedded portion
> of those tools.
>
> Once upon a time, programming was a fan for many scientists because
> it was not so difficult.    They have to just care of the precisenenss of
> their own parts.   Now a days, I think most of them are buying some
> commercial products and students don't know how to make it from
> scratch.   It will soon make this world darker I fear.
>
> Does your Plan B help such?
>
> Kenji
>
>

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> such windows need GUIs - dragging a selection on a wave,
> but it's kinda different huh?

GUI not necessarily means controls/widgets; sometimes the whole is bigger
than the sum of components. Our society is literate, i.e., text-based,
no matter how hard certain groups try to change this. Take a look around,
basically every GUI has some textual info attached to an action that
can be performed. Even in 100% graphic icons the mind has first to
form a textual "token" before it can recognise what it is. The framing
of a button is just syntactic sugar so that you -god forbid- would not
actually have to think what's written there.

In "all-text" systems there of course remains the problem how the user
is supposed to pick active snippets from the general flow. Typescript
systems have this one solved rather elegantly IMHO, by making everyhing
active. The whole universe is your playground.

Graphics should support text, not vice versa.

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Tiit, Kenji, Nemo, and others

TL> GUI not necessarily means controls/widgets; sometimes the whole is bigger
TL> than the sum of components. Our society is literate, i.e., text-based,
TL> no matter how hard certain groups try to change this. Take a look around,
TL> basically every GUI has some textual info attached to an action that
TL> can be performed. Even in 100% graphic icons the mind has first to
TL> form a textual "token" before it can recognise what it is.
IMHO text/language only represents thoughts, images most fastest way to recognize
something, text one of images. If your say 'disk' only who known English
(ok, this word in many languages sounds like 'disk' but it's only example)
can understand you, but when you show 'disk' anyone understand you.
If in Acme 'Get Put send' change to button you lose nothing.
TL> The framing of a button is just syntactic sugar so that you -god forbid- would not
TL> actually have to think what's written there.

TL> In "all-text" systems there of course remains the problem how the user
TL> is supposed to pick active snippets from the general flow. Typescript
TL> systems have this one solved rather elegantly IMHO, by making everyhing
TL> active. The whole universe is your playground.
Plan 9 my first system with typescript system, and first impression was
great, but now I see many things is missing (buttons, lists etc).

Example:
If I need cad system, how I can create it in typescript system?
Or maybe you suggest type all command in console ;)

KO> Once upon a time, programming was a fan for many scientists because
KO> it was not so difficult. They have to just care of the precisenenss of
KO> their own parts. Now a days, I think most of them are buying some
KO> commercial products and students don't know how to make it from
KO> scratch.
It's good for people who 'write code', it's every time have
work... I am sure 'programming user' is utopia...
RO> It will soon make this world darker I fear.
We can't stop this :-)

nemo> Regarding the UIs,
nemo> we have what we call omero (another experiment), it's a mixture of
nemo> a window-toolkit and a file server, that handles all the graphics by
nemo> its own. The application creates files to build its UI, and the fs takes
nemo> care of the mouse and everything else. This allows you to replicate
nemo> and move around UI components without placing the burden in the
nemo> application.
Can I see it?


--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Fco. J. Ballesteros]

> Can I see it?

http://lsub.org/who/nemo/export/omero.gif

What you see is done so it could work on Plan 9 as well, so I
hope this is not too far off-topic ;-)

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> http://lsub.org/who/nemo/export/omero.gif

Hmm, it looks like same to our masv scheme, somewhat different
looks though.   I'm now stopping this line because it does not help
us (not pro-programmer) from tieing too much tightly us to "GUI
programming", too.

GUI programming should be separated from main programming stream,
I now think.   It is because the main purpose of programming is not make
GUI, which is just for user interface.   Or most importantly, it should not
add any of difficult things to programming, I believe.

Kenji

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

Sorry, I forgot this.

I'm not abusing you, nemo.
Everyone should try what s/he believes it's nice.
Fortunately, none knows what must be the best one in this case.☺
After times of tries, we may find better one for Plan 9 which is
the test base for new things, I believe.

Kenji

[-- Attachment #2: Type: message/rfc822, Size: 3762 bytes --]

From: Kenji Okamoto <okamoto@granite.cias.osakafu-u.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Evolving rio / GUI development
Date: Tue, 22 Feb 2005 10:16:23 +0900
Message-ID: <2e7956d0fc4673cd2ccaa1a057955f86@granite.cias.osakafu-u.ac.jp>

> http://lsub.org/who/nemo/export/omero.gif

Hmm, it looks like same to our masv scheme, somewhat different
looks though.   I'm now stopping this line because it does not help
us (not pro-programmer) from tieing too much tightly us to "GUI
programming", too.

GUI programming should be separated from main programming stream,
I now think.   It is because the main purpose of programming is not make
GUI, which is just for user interface.   Or most importantly, it should not
add any of difficult things to programming, I believe.

Kenji

Re: [9fans] Evolving rio / GUI development

[Matthias Teege]

> GUI programming should be separated from main programming stream,
> I now think.   It is because the main purpose of programming is not make

Yes!

> GUI, which is just for user interface.   Or most importantly, it should not

It is the interface to a human.  It should be programmed by poeple who
know how humans "work" and not from people who know how computers
work.

Matthias

Re: [9fans] Evolving rio / GUI development

[Gorka Guardiola]

> Example:
> If I need cad system, how I can create it in typescript system?
> Or maybe you suggest type all command in console ;)


Autocad started as a lisp interpreter I think and many professionals prefer the
commands to the placing stuff with the mouse or at least combine both...


											G.

Re: [9fans] Evolving rio / GUI development

[lucio]

> Autocad started as a lisp interpreter I think and many professionals prefer the
> commands to the placing stuff with the mouse or at least combine both...

Dotty (from graphviz) still operates on that principle.  So it's not
as if there is only one scheme of things.

++L

Re: [9fans] Evolving rio / GUI development

[Skip Tavakkolian]

>> Autocad started as a lisp interpreter I think and many professionals prefer the
>> commands to the placing stuff with the mouse or at least combine both...
> 
> Dotty (from graphviz) still operates on that principle.  So it's not
> as if there is only one scheme of things.

My preference for the whole gui approach would be to have it cleanly
separated from the applications.  Following /dev/draw's model, ideally
a filesystem would enforce the GUI↔application interface.  A
refinement (not a new idea either) is to tie the whole "chrome"
filesystem to a language like tk/tcl; tcl or lisp/scheme would not be
my choices.

If the chrome could be cleanly detached from the underlying functions
and could be changed easily, look-and-feel development could continue
well past the time when it's functionality is complete.  If someone wanted
eye-candy, he could develop it.  Perhaps generalizing the interface is
not possible and would require specialization to specific problem
sets.

Re: [9fans] Evolving rio / GUI development

[Chesky Salomon]

On Mon, 21 Feb 2005 16:37:37 -0800, Skip Tavakkolian <9nut@9netics.com> wrote:
> My preference for the whole gui approach would be to have it cleanly
> separated from the applications.  Following /dev/draw's model, ideally
> a filesystem would enforce the GUI↔application interface.  A
> refinement (not a new idea either) is to tie the whole "chrome"
> filesystem to a language like tk/tcl; tcl or lisp/scheme would not be
> my choices.
> 

Searching the archives...
On Fri, 6 Sep 2002 20:34:16 -0700, Russ Cox wrote:
> 'How I ported the [Mozilla|Konqueror]
> HTML rendering engine to plan9 and 
> made it fit well with the rest of the system.'

2½ years from challenge to concept... ;-)

--Joel

Re: [9fans] Evolving rio / GUI development

[Skip Tavakkolian]

Something with finer graphics controls, more transparent and
less obtuse than the Struts model.

"or how to reimplement CICS for Plan9"

>> My preference for the whole gui approach would be to have it cleanly
>> separated from the applications.  Following /dev/draw's model, ideally
>> a filesystem would enforce the GUI↔application interface.  A
>> refinement (not a new idea either) is to tie the whole "chrome"
>> filesystem to a language like tk/tcl; tcl or lisp/scheme would not be
>> my choices.
>> 
> 
> Searching the archives...
> On Fri, 6 Sep 2002 20:34:16 -0700, Russ Cox wrote:
>> 'How I ported the [Mozilla|Konqueror]
>> HTML rendering engine to plan9 and 
>> made it fit well with the rest of the system.'
> 
> 2½ years from challenge to concept... ;-)
> 
> --Joel

Re: [9fans] Evolving rio / GUI development

[Ronald G. Minnich]

On Mon, 21 Feb 2005, Gorka Guardiola wrote:

> Autocad started as a lisp interpreter I think and many professionals
> prefer the commands to the placing stuff with the mouse or at least
> combine both...

There's no universal rule. One of the nicest CAD systems I used was the
Altera system, which let you easily intermix text and graphics symbols as
you needed. You could create an include file from a graphics symbol, and
you could easily create a graphics symbol from AHDL code. The worst
systems are the ones that give you ONLY pictures or ONLY text.

The one thing I've observed in the last xy years is that some people love
those graphical systems and some people hate 'em. The most versatile
people learn to use both text and graphical aspects of the tools -- which
is why really good engineers like the Linux versions of the CAD tools as
opposed to the Windows versions -- you get way more options with the Linux
versions. For one thing, on Linux, you can shitcan all the various
'Wizards' and get in there with grep and sed and Makefiles and build a
project.

ron

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> Example:
> If I need cad system, how I can create it in typescript system?
> Or maybe you suggest type all command in console ;)

You don't have to confine yourself to text. I just think that text
should be the primary medium.

Re: [9fans] Evolving rio / GUI development

[lucio]

> IMHO text/language only represents thoughts, images most fastest way to recognize
> something, text one of images. If your say 'disk' only who known English
> (ok, this word in many languages sounds like 'disk' but it's only example)
> can understand you, but when you show 'disk' anyone understand you.

Try an icon for "beauty", or "intelligence".

++L

Re: [9fans] Evolving rio / GUI development

[Matthias Teege]

>> IMHO text/language only represents thoughts, images most fastest way to recognize
>> something, text one of images. If your say 'disk' only who known English

That is not true.  Start your Mozilla, and move the cursor over some
icon.  If you wait some seconds, you'll get a long description of the
icon.  Why?  Why do I need a description of an icon if it is the
"fastest way to recognize"?  The fundamental rule of user interfaces
is adaption.  A good interface must be monotone/consistent, modeless
and there must be only one way to solve a problem.  It must support
adaption.  It must be like Acme without a tagline (and with graffic
and WYSIWYG support ;-))

A textual interface is the most user friendly today (textual != cli).

Matthias

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Matthias,

Tuesday, February 22, 2005, 10:07:36 AM, you wrote:
>>> IMHO text/language only represents thoughts, images most fastest way to recognize
>>> something, text one of images. If your say 'disk' only who known English
MT> That is not true.  Start your Mozilla, and move the cursor over some
MT> icon.  If you wait some seconds, you'll get a long description of the
MT> icon.  Why?  Why do I need a description of an icon if it is the
MT> "fastest way to recognize"?
But after reading description you known what mean this icon.
This is like learn new language - you read word in dictionary once.

Example:
Long time (while I not read 'man acme' :) I can't understand what is
'Look', but if it have tool-tip i need just stop mouse over them...
MT> The fundamental rule of user interfaces
MT> is adaption.  A good interface must be monotone/consistent, modeless
MT> and there must be only one way to solve a problem.  It must support
MT> adaption.  It must be like Acme without a tagline (and with graffic
MT> and WYSIWYG support ;-))
That is right!

MT> A textual interface is the most user friendly today (textual != cli).
cli?
--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[boyd, rounin]

> 'Look', but if it have tool-tip i need just stop mouse over them...

tool-tips are definitive proof of the failure of a user interface design.
--
MGRS 31U DQ 52572 12604

Re: [9fans] Evolving rio / GUI development

[David Tolpin]

On 22.02.2005, at 18:00, boyd, rounin wrote:

>> 'Look', but if it have tool-tip i need just stop mouse over them...
>
> tool-tips are definitive proof of the failure of a user interface
> design.

man is like a tool-tip. It explains what a command does when it is not
obvious for a casual user from the command's name. Just less convenient
to reach.

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

>> tool-tips are definitive proof of the failure of a user interface design.
>
> man is like a tool-tip. It explains what a command does when it is not
> obvious for a casual user from the command's name. Just less convenient
> to reach.

You've just proven Boyd's point. If an explanation requires an
explanation, don't you think that the orginial explanation is a failure?
"What we seem to have here is a failure to communicate."

Re: [9fans] Evolving rio / GUI development

[David Tolpin]

On 22.02.2005, at 18:15, Tiit Lankots wrote:

>>> tool-tips are definitive proof of the failure of a user interface
>>> design.
>> man is like a tool-tip. It explains what a command does when it is
>> not obvious for a casual user from the command's name. Just less
>> convenient to reach.
>
> You've just proven Boyd's point. If an explanation requires an
> explanation, don't you think that the orginial explanation is a
> failure? "What we seem to have here is a failure to communicate."
>

I did not prove anyone's point. A symbol, whether textual or pictorial,
is not an explanation of self. It is a name; a name needs an
explanation. A tooltip is a good way to introduce an explanation; in
particular when someone coming from a non-american-english environment
trying to use an interface.

It is also nice for people who use alternative signaling system for
interaction, those visually impared do. They listen to the tooltip for
the first time, and then attach a tone or a tune which they recognize
easily to the icon or to the abbreviated name.

David

Re: [9fans] Evolving rio / GUI development

[lucio]

>> 'Look', but if it have tool-tip i need just stop mouse over them...
>
> tool-tips are definitive proof of the failure of a user interface design.

Agreed, specially when they need to be available in zillions of
alternative languages.  I have the occasional laugh at StarOffice when
it pops up unexpected German messages.  I do have an old copy, but it
makes a fine example.

And of course you never know whether you'll get a tool-tip or not.

++L

Re: [9fans] Evolving rio / GUI development

[Charles Forsyth]

>>MT> "fastest way to recognize"?

>But after reading description you known what mean this icon.
>This is like learn new language - you read word in dictionary once.

it is more like learning a new language that changes spelling and meaning
with every person (application) you meet that speaks it.

as the experience with international language-less signs suggests, it's hard to
design images that convey messages with complete accuracy.
it's worse when the conventions change (as part of international
standardisation, for instance).
that nasty looking green-and-yellow wire
must surely be the live and dangerous one ...

Re: [9fans] Evolving rio / GUI development

[Martin C.Atkins]

On Tue, 22 Feb 2005 14:09:59 +0000 Charles Forsyth <forsyth@terzarima.net> wrote:
>..
> that nasty looking green-and-yellow wire
> must surely be the live and dangerous one ...

Especially since yellow is nature's warning colour (examine a handy bee).

Martin

--
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] Evolving rio / GUI development

[Gorka Guardiola]

> Try an icon for "beauty", or "intelligence".


Interesting. And why do you need a button/tag with that on?. What exact
program are you thinking on?. Just curious...


								G.

Re: [9fans] Evolving rio / GUI development

[lucio]

> Interesting. And why do you need a button/tag with that on?. What exact
> program are you thinking on?. Just curious...

I only thought of it later: what about "volume" or "intensity"?

I was merely countering the suggestion that icons are better than
words, where in my opinion words are far more powerful symbols than
images, even though the latter are more descriptives.

Different levels of abstraction, really.  The more remote (abstract)
the symbol, the firmer the supporting social convention has to be to
support it.  I take that (I'm no educated philosopher) to imply that
fewer ambiguities are possible.  Mathematics makes a nice extreme
instance.

++L

Re: [9fans] Evolving rio / GUI development

[Skip Tavakkolian]

>> Interesting. And why do you need a button/tag with that on?. What exact
>> program are you thinking on?. Just curious...
>
> I only thought of it later: what about "volume" or "intensity"?
>
> I was merely countering the suggestion that icons are better than
> words, where in my opinion words are far more powerful symbols than
> images, even though the latter are more descriptives.
>
> Different levels of abstraction, really.  The more remote (abstract)
> the symbol, the firmer the supporting social convention has to be to
> support it.  I take that (I'm no educated philosopher) to imply that
> fewer ambiguities are possible.  Mathematics makes a nice extreme
> instance.

I was thinking along the same lines, then I remembered something
from Bill Bryson's latest book; he was talking about the chaotic notations
and abbreviations that were used for elements before a
Swedish scientist came up with a reasonable approach that became
the standard. If it's standard, then everyone gets it.

The most exact icon I've ever seen is the "bullet in the forehead"
button in an early version of Inferno's debugger.  I thought the
blood dripping was a nice touch, removing any doubt.

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

I find the "oh my god, what does that wonderful icon mean!" and
the phone calls involving talk like "yeah it's that kinda blue one
with the squiggle on it" rather entertaining/demeaning.

brucee

Re: [9fans] Evolving rio / GUI development

[C H Forsyth]

>>The most exact icon I've ever seen is the "bullet in the forehead"
>>button in an early version of Inferno's debugger.  I thought the
>>blood dripping was a nice touch, removing any doubt.

absolutely!

Re: [9fans] Evolving rio / GUI development

[fgergo]

On Wed, 23 Feb 2005 00:17:11 +0000, C H Forsyth <forsyth@vitanuova.com> wrote:
> >>The most exact icon I've ever seen is the "bullet in the forehead"
> >>button in an early version of Inferno's debugger.  I thought the
> >>blood dripping was a nice touch, removing any doubt.
>
> absolutely!

Any chance of putting it and the others back into wm/deb.
I suppose it is from version 0.1. I only have 0.2, but it already had
different icons. They are not that expressive.

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

they are in the original distribution.  and then someone who didn't
even know how to run emu decided they were politically incorrect.
the originals are much better than the VC inspired things that appeared.
tho i think someone had a laugh if you examine them closely.

i have a smiley "kill thread" t-shirt.

brucee

> Any chance of putting it and the others back into wm/deb.
> I suppose it is from version 0.1. I only have 0.2, but it already had
> different icons. They are not that expressive.

Re: [9fans] Evolving rio / GUI development

[lucio]

> I was thinking along the same lines, then I remembered something
> from Bill Bryson's latest book; he was talking about the chaotic notations
> and abbreviations that were used for elements before a
> Swedish scientist came up with a reasonable approach that became
> the standard. If it's standard, then everyone gets it.

Talk about going around in circles.  But Bill Bryson vs Andy Tanenbaum
is a rather neat stand-off.  My Tanenbaum literature is presently
hidden, so I can't check the number of n's in his surname :-(

++L

Re: [9fans] Evolving rio / GUI development

[Rob Pike]

> If it's standard, then everyone gets it.

C++ is standard.  I don't get it.

-rob

Re: [9fans] Evolving rio / GUI development

[Gorka Guardiola]

>> If it's standard, then everyone gets it.
>
> C++ is standard.  I don't get it.
>
> -rob


Are you standard?.

			G.

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

rob is a derived class.  fortunately he chooses his friends wisely.
i've been C++ing a bit lately (don't blame me).  i just can't wait
to see what features are needed for the next standard.

brucee

On Wed, 23 Feb 2005 14:19:43 +0100, Gorka Guardiola <paurea@lsub.org> wrote:
> >> If it's standard, then everyone gets it.
> >
> > C++ is standard.  I don't get it.
> >
> > -rob
>
> Are you standard?.

>                        G.
>
>

Re: [9fans] Evolving rio / GUI development

[Brantley Coile]

	C = 89;
	print("%d\n", C++);

	What's the deal?  I still get 89?
	Now, if the name had been ++C I would've looked at it.  :)

	Brantley

> rob is a derived class.  fortunately he chooses his friends wisely.
> i've been C++ing a bit lately (don't blame me).  i just can't wait
> to see what features are needed for the next standard.
>
> brucee
>
> On Wed, 23 Feb 2005 14:19:43 +0100, Gorka Guardiola <paurea@lsub.org> wrote:
>> >> If it's standard, then everyone gets it.
>> >
>> > C++ is standard.  I don't get it.
>> >
>> > -rob
>>
>> Are you standard?.
>
>>                        G.
>>
>>

Re: [9fans] Evolving rio / GUI development

[Ronald G. Minnich]

On Thu, 24 Feb 2005, Bruce Ellis wrote:

> rob is a derived class.  fortunately he chooses his friends wisely.
> i've been C++ing a bit lately (don't blame me).  i just can't wait
> to see what features are needed for the next standard.

static dynamic virtual casts

ron

Re: [9fans] Evolving rio / GUI development

[Rob Pike]

public: volatile friend boyd;

-rob

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

Indeed perhaps the best aspect of C++ coding is embedding
puns in the code  Haven't had this much fun since COBOL.

- virtual pure brucee

On Wed, 23 Feb 2005 10:37:24 -0500, Rob Pike <robpike@gmail.com> wrote:
> public: volatile friend boyd;
>
> -rob

Re: [9fans] Evolving rio / GUI development

[Ronald G. Minnich]

On Thu, 24 Feb 2005, Bruce Ellis wrote:

> Indeed perhaps the best aspect of C++ coding is embedding
> puns in the code  Haven't had this much fun since COBOL.

blast. We need a PERFORM verb.

ron

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

what about the lonely "try" keyword?  what if all you need is
a "penalty goal".

this is getting silly, back to work.

brucee

On Wed, 23 Feb 2005 09:06:56 -0700 (MST), Ronald G. Minnich
<rminnich@lanl.gov> wrote:
>
>
> On Thu, 24 Feb 2005, Bruce Ellis wrote:
>
> > Indeed perhaps the best aspect of C++ coding is embedding
> > puns in the code  Haven't had this much fun since COBOL.
>
> blast. We need a PERFORM verb.
>
> ron
>

Re: [9fans] Evolving rio / GUI development

[Skip Tavakkolian]

class brucee : { real friend class brucej; }

Re: [9fans] Evolving rio / GUI development

[David Leimbach]

On Thu, 24 Feb 2005 00:39:44 +1100, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> rob is a derived class.  fortunately he chooses his friends wisely.
> i've been C++ing a bit lately (don't blame me).  i just can't wait
> to see what features are needed for the next standard.
>

Fixed width integer types? :)

I've been ripping off software from boost to generate them at compile time using
template metaprogramming junk.  It works on LP32 and LP64 systems so far that
I've tested but it'd just be nicer if the standard would specify types

There is a really decent book on dealing with a bunch of C++
annoyances [if you must]
called Imperfect C++ that lists a bunch of problems and workarounds.

Dave
> brucee
>
> On Wed, 23 Feb 2005 14:19:43 +0100, Gorka Guardiola <paurea@lsub.org> wrote:
> > >> If it's standard, then everyone gets it.
> > >
> > > C++ is standard.  I don't get it.
> > >
> > > -rob
> >
> > Are you standard?.
>
> >                        G.
> >
> >
>

Re: [9fans] Evolving rio / GUI development

[Richard Miller]

> Fixed width integer types? :)

Actually quite a useful feature for hardware compilation (i.e. when
the output of the compiler is a VHDL chip description).  For example,
see http://www.sle.sharp.co.uk/research/scd/bach.htm

Re: [9fans] Evolving rio / GUI development

[Dave Lukes]

Yes, de facto:-).

On 23 Feb 2005, at 13:19, Gorka Guardiola wrote:

>>> If it's standard, then everyone gets it.
>>
>> C++ is standard.  I don't get it.
>>
>> -rob
>
>
> Are you standard?.
>
> 			G.
>

Re: [9fans] Evolving rio / GUI development

[Steve Simon]

> I was merely countering the suggestion that icons are better than
> words, where in my opinion words are far more powerful symbols than
> images, even though the latter are more descriptives.

Tis interesting that perceptually words are both symbols and
text - in order to read at more than a couple of hundred words
per min (roman script) you have to read words by pattern matching
and much of that through peripheral vision. People rarely read
the characters of a word unless its one they don't recognise.

[aside: We could have a bizzar icon that pops up when
you hover the mouse of Acme's Tag labels...]

-Steve

Re: [9fans] Evolving rio / GUI development

[Andrew Simmons]

>
>[aside: We could have a bizzar icon that pops up when
>you hover the mouse of Acme's Tag labels...]
Would this be bizarre enough?

http://www.juergenspecht.com/documentations/?number=1&photo=39#photo

Re: [9fans] Evolving rio / GUI development

[lucio]

> [aside: We could have a bizzar icon that pops up when
> you hover the mouse of Acme's Tag labels...]

ROFL!  Now, that's thinking "outside the box"!

++L

Re: [9fans] Evolving rio / GUI development

[Martin C.Atkins]

On Tue, 22 Feb 2005 23:47:40 +0000 "Steve Simon" <steve@quintile.net> wrote:
> Tis interesting that perceptually words are both symbols and
> text - in order to read at more than a couple of hundred words
> per min (roman script) you have to read words by pattern matching
> and much of that through peripheral vision. People rarely read
> the characters of a word unless its one they don't recognise.

Strange you should say that. I saw an article earlier in the week
that suggested that most of the success of "speed reading" courses is
to train people to do word-by-word pattern recognition. The unstated
conclusion would be that such courses are not so effective for people
who already read that way!

I wonder if people who read that way are also, on average, less good
at crossword puzzles/scrabble/etc? (Or have to learn these as a
separate skill?)

Martin
--
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] Evolving rio / GUI development

[Fco. J. Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 266 bytes --]

I don't think it does, if I understand what you said.
Doing UIs with omero is a bit simpler than doing them
with rio (same for acme). But it still requires programming.
Also, we are using the oberon/acme style of interaction (although
we got graphics as well).

[-- Attachment #2: Type: message/rfc822, Size: 3222 bytes --]

From: Kenji Okamoto <okamoto@granite.cias.osakafu-u.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Evolving rio / GUI development
Date: Mon, 21 Feb 2005 11:54:16 +0900
Message-ID: <1831e14deca9e2a1e4c2c185f4979bcd@granite.cias.osakafu-u.ac.jp>

> Regarding the UIs,
> we have what we call omero (another experiment), it's a mixture of
> a window-toolkit and a file server, that handles all the graphics by
> its own. The application creates files to build its UI, and the fs takes
> care of the mouse and everything else. This allows you to replicate
> and move around UI components without placing the burden in the
> application.

How do you think that recent GUI programming style is too difficult
to understand for non-computer science students.   We need GUI
only for user interface, and it should be very easy to deal with, and
can be used from all of the languages without special enbedded portion
of those tools.

Once upon a time, programming was a fan for many scientists because
it was not so difficult.    They have to just care of the precisenenss of
their own parts.   Now a days, I think most of them are buying some
commercial products and students don't know how to make it from
scratch.   It will soon make this world darker I fear.

Does your Plan B help such?

Kenji

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> well, you folks all seem to be able to fit all your windows tiled. I just 
> plain can't. I've to two 21" LCDs and with the CAD systems etc. I use 
> there's no room at all to tile everything. It just doesn't work, hence my 
> need for multiple desktops and other such things. 

I think you mean virtual multiple deskops judging from andrey's comment
on this.

To me, I 'm not so good to remember the image in my head, that kind of
multiple desktops doesn't work well either.   It works for me, only to keep
web browser in a virtual desktop, and another work for another desktop etc.
In this sense, I'm doing completely different things for each desktop, and 
I'd be better to concentrate to use my brain only one for one thing at a time.
Although take a rest by using web browse is a usual play to me, too.☺
However, this is not a serious problem, if we think the computer for something
work.   However, if it doesn't make any problem, it's not bad to have virtual
desktops in Plan 9, I agree.

If we need many windows (need not be a desktop, I believe), probably I'm
doing one thing, and need to check multiple data at once.   In this case,
I'm sure tiling scheme can be used for this from my experience with marsv.
We just need a mouse operation to expand/shrink one window etc.   If
I want to see much larger data in a window, I believe I have to buy more
big physical medeia.☺ 

On the other hand, multiple tiled window scheme has a big advantage that
it can show us all the levels of possible operation in a desktop.  This makes
user easier to choose reasonable command from the windows.   No deep
hidden command which usually makes problem, and selling kindergarten
like teaching book.☺
How do you think of this?

Kenji

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> Although take a rest by using web browse is a usual play to me, too.☺
> However, this is not a serious problem, if we think the computer for something
> work.   However, if it doesn't make any problem, it's not bad to have virtual
> desktops in Plan 9, I agree.

When I wrote this, I was reading "why Europa has strike-slip fault things paper", and
failed to concentrate myself.    After had a lunch and joyful playing talks, I rethinked
"hide" operation must be enough for this purpose.   Is there any other reason why
we should have virtual desktop for Plan 9?

Kenji

Re: [9fans] Evolving rio / GUI development

[Bruce Ellis]

Totally correct.  Label and Hide are enough for me to cope
with a few machines at once.

Gee ... open a big window and cpu somewhere, run rio.
Virtual desktop?  Call it what you like.

brucee

On Fri, 18 Feb 2005 16:10:27 +0900, Kenji Okamoto
<okamoto@granite.cias.osakafu-u.ac.jp> wrote:
> > Although take a rest by using web browse is a usual play to me, too.☺
> > However, this is not a serious problem, if we think the computer for something
> > work.   However, if it doesn't make any problem, it's not bad to have virtual
> > desktops in Plan 9, I agree.
> 
> When I wrote this, I was reading "why Europa has strike-slip fault things paper", and
> failed to concentrate myself.    After had a lunch and joyful playing talks, I rethinked
> "hide" operation must be enough for this purpose.   Is there any other reason why
> we should have virtual desktop for Plan 9?
> 
> Kenji
> 
>

Re: [9fans] Evolving rio / GUI development

[Rob Pike]

On Fri, 18 Feb 2005 16:10:27 +0900, Kenji Okamoto
<okamoto@granite.cias.osakafu-u.ac.jp> wrote:

> When I wrote this, I was reading "why Europa has strike-slip fault things paper", and
> failed to concentrate myself.    After had a lunch and joyful playing talks, I rethinked
> "hide" operation must be enough for this purpose.   Is there any other reason why
> we should have virtual desktop for Plan 9?
>
> Kenji
>

This is one of the greatest mail messages I ever received.

-rob

Re: [9fans] Evolving rio / GUI development

[McLone]

On Fri, 18 Feb 2005 12:50:13 +0900, Kenji Okamoto
<okamoto@granite.cias.osakafu-u.ac.jp> wrote:
> We just need a mouse operation to expand/shrink one window etc.
In *box i bind mousewheel[s] or buttons 4-5 on window borders/title
for that. Highly useful.

--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: [9fans] Evolving rio / GUI development

[rog]

> So, yes, rio is a fine and wonderful thing, but I don't buy it as the
> be-all and end-all of window managers.

winwatch helps, but i have to say, i do find available screen space
restrictive (and i'm running at 1400x1050). i run with acme
taking up all the horizontal space and 95% of the vertical
space, leaving a strip along the top for access to windows.
winwatch is useful.

> With multiple desktops, as much as I like rio, I find it easier to use
> flwm and swap around with CTRL-F[1234] etc.

so, like a fool, i thought "this'll be totally easy to do with rio; i'll just
place a filter onto its keyboard input that switches windows when it
sees a function key".

there sure are some sticky bits lurking under the surface in plan 9 if
you swim where others haven't swum before...

i kinda got it working, but it's not really usable.  here are some
gotchas i encountered along the way:

1) you can't make a full screen window in rio (1 pixel less in each dimension)
2) you can't make a borderless window in rio.
3) creation of a badly sized window fails silently.
4) there's no way of finding out the current available screen (*not* display)
	size when running rio in rio.
5) screenids run out quickly when you've got multiple clients creating screens
	(see /sys/src/libdraw/window.c:/25). most people don't notice
	because most windows are created by the same draw client.
	try:
		cpu
		for(i in `{seq 1 25}){window -m lens}
	perhaps screenid should probably be seeded somewhere random-ish
	(e.g. milliseconds^pid) and increase by prime multiples.

	at the least, the loop should at least detect that it's gone over the end
	and return an appropriate error message.
7) if you give rio an init command, it puts it in a new note group, so
	if you kill off the window within which rio is running, the
	command hangs around, thus:
8) managing recalcitrant groups of processes where the process names
	are all very similar is hard, particularly if you're running rio.
	very very easy to kill off your main window manager.
	there's no easy way to find out what processes are
	grouped together (perhaps ps could be able to print noteids, which
	helps a bit).

[if others consider any/all of the above to be bugs, i could
do patches, depending on what's considered the right way to fix
them.]

it's not worth posting my code.
conclusion: if you want to do this, modify rio itself!

'course there are other issues to solve too here, like:
if the plumber creates a new window, where should it appear?

i think rio can definitely be improved. that "sticky" menu has caused
me to unintentionally delete windows sooo many times, for one.

Re: [9fans] Evolving rio / GUI development

[arisawa]

rog said:

> i think rio can definitely be improved. that "sticky" menu has caused
> me to unintentionally delete windows sooo many times, for one.
>

me too.
I want "undo" for sticky menu.

Kenji Arisawa

Re: [9fans] Evolving rio / GUI development

[Sam]

> rog said:
>
>> i think rio can definitely be improved. that "sticky" menu has caused
>> me to unintentionally delete windows sooo many times, for one.
>>
>
> me too.

Me three, due to Hide and Delete being right next to
each other.  Swapping Delete and Resize mitigated this
for me.

I also list hidden windows in the b3 menu in reverse
order so the most recently hidden window is right beneath
Hide.

Triviality, but helpful.

Sam

Re: [9fans] Evolving rio / GUI development

[rog]

> Triviality, but helpful.

actually these kind of details are crucial to a good user interface.

as observed by rob: ``A user interface should not only provide the
necessary functions, it should also *feel* right.  In fact, it should
almost not be felt at all; when one notices a user interface, one is
distracted from the job at hand.''

this is why acme is so deliciously usable - it gets the little things right;
in particular it is not modal, so one can develop "muscle memory"
for the commonly performed tasks.

this can't be said of rio.
actually, i'd quite like to see an implementation of rio with pie
menus. it's just a pity they're so awkward to implement
(and that it's not clear what to do with menus of open-ended size).
anyone out there implemented pie menus in the past?

Re: [9fans] Evolving rio / GUI development

[Russ Cox]

> this can't be said of rio.
> actually, i'd quite like to see an implementation of rio with pie
> menus. it's just a pity they're so awkward to implement
> (and that it's not clear what to do with menus of open-ended size).
> anyone out there implemented pie menus in the past?

i think the right thing to do is eliminate the menus entirely.

on button 2, we have cut, paste, snarf, send, plumb, scroll.
on button 3, we have New, Reshape, Move, Delete, Hide.

if we get rid of the menus, then in a text window we can use
chords for cut, paste, snarf, button 2 for send, button 3 for
plumb.  that leaves scroll.

for window management, Reshape and Move are already
handled via the window border, leaving New, Delete, and Hide.
if there's no b3 menu then a new window can be created
by just dragging out a rectangle with b3 when you start
on grey background.  that leaves Delete and Hide.
the hidden window menu can go on b1.

so scroll, delete, and hide.  if windows had a title bar (heresy!)
like acme's tag lines, then those could go there.

just an idea.  what i'd really like is to be able to move
windows between rio and acme, not just make them look
similar.

russ

Re: [9fans] Evolving rio / GUI development

[g01495]

On Thu, 3 Mar 2005 13:27:30 -0500, Russ Cox <russcox@gmail.com> wrote:
> for window management, Reshape and Move are already
> handled via the window border

i like the reshape functionality -- i prefer it over using the window
borders, i find most of the time i and up both moving and resizing a
window and it's useful to do this in one operation, also i find using
the window borders can sometimes be a bit awkward.

Re: [9fans] Evolving rio / GUI development

[Charles Forsyth]

if i'm just tweaking a window's size or shape, i tend to use the borders.
otherwise i use Reshape, but that could be started a different way.
at the moment, though, i'm stuck in console mode trying to work out which
bit is wrong in the ATI on this A22.  now i know why they gave it
realistic names such as Rage, Fury, etc.

Re: [9fans] Evolving rio / GUI development

[arisawa]

Russ said:

> so scroll, delete, and hide.  if windows had a title bar (heresy!)
> like acme's tag lines, then those could go there.
>

good idea.
I think current menu of rio is residuum of 8 half window of Plan 9
version 2.
If rio has a tag line that is similar to acme, then we can have many
other
things there: label, search, undo,...

Kenji Arisawa

Re: [9fans] Evolving rio / GUI development

[rog]

> just an idea.  what i'd really like is to be able to move
> windows between rio and acme, not just make them look
> similar.

i agree.

i thought about this before and looked into the acme data structures a
bit.  at the moment, you've got multiple Columns, but only one Row. i
didn't go any further into it, but i reckoned it might not be too hard
to make acme multi-window capable, and have one Row for each separate
window that it creates.

then maybe you could drag an acme window onto the rio background and
have it create a new rio window; you could move other windows there
too.

if you enabled graphics-style windows in acme (which i haven't looked
into but rob says isn't hard), then you lose a lot of the need for rio.
in fact you could run acme as your window manager and nest rio
inside a window inside it, and further acme windows inside that.
maybe that's going a bit far :-)

one difficulty i have is when editing code in a deeply nested
directory.  i wonder whether in the above scenario, one might allow a
Row window to have a filename tag; any windows in it would display
relative pathnames if under that directory.

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

>> just an idea.  what i'd really like is to be able to move
>> windows between rio and acme, not just make them look
>> similar.
> 
> i agree.

 I don't.☺

I think rio should be as simple as possible, because it's a solid base
window system for Plan 9, and we need a simple shell running window
system for an emergency.

> to make acme multi-window capable, and have one Row for each separate
> window that it creates.

Mutiple window capable acme?  what for?
I suppose we need multiple windows when we do different things
in that windows, conseqentry I don't need such.    Different works on
different windows, this is simpler.   It's easier and clearer to have multiple 
acmes on a rio window system.☺

> in fact you could run acme as your window manager and nest rio
> inside a window inside it

I also thought this possibility once, but just nest rio inside acme...
However, I now think it's no use.

I may be away from here for a couple of weeks, so my response
to this may delay, sorry.

Kenji

Re: [9fans] Evolving rio / GUI development

[Scott Schwartz]

> anyone out there implemented pie menus in the past?

No, just Don Hopkins. :)

http://www.bx.psu.edu/~schwartz/tkpie.shar.gz

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

TL> how about no new gui
TL> the old one ain't smellin' yet
What you mean in term 'GUI'?
Yes, with large monitors we can forget about window switching, but now
most of Plan 9 programs have only console version! When you want
create application with buttons, entryes, list boxes you need draw it
by self...

RM> With multiple desktops, as much as I like rio, I find it easier to use
RM> flwm and swap around with CTRL-F[1234] etc.
See! People need advanced window manager!

AM> with rio i can sit behind somebody else's terminal and use it without
AM> having to read a 100-page manual on their key bindings, virtual
AM> displays configuration, focus behaviour and menu buttons.
Show at least one GUI which need 100 page manual... most of it have
intuitive interface, and 'rio' too.

--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[boyd, rounin]

> Show at least one GUI which need 100 page manual...

X11
--
MGRS 31U DQ 52572 12604

Re: [9fans] Evolving rio / GUI development

[McLone]

On Thu, 17 Feb 2005 21:17:06 +0100, boyd, rounin <boyd@insultant.net> wrote:
> > Show at least one GUI which need 100 page manual...
> X11
w/o toolkit and WM? You must be kiddin'.
*unuseable*

--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: [9fans] Evolving rio / GUI development

[andrey mirtchovski]

> Show at least one GUI which need 100 page manual... most of it have
> intuitive interface, and 'rio' too.

The only "intuitive" interface is the nipple. After that it's all learned.

                                                  -- bruce ediger

Re: [9fans] Evolving rio / GUI development

[g01495]

On Thu, 17 Feb 2005 22:00:20 +0200, Sergey Reva <rs_rlab@mail.ru> wrote:
> TL> how about no new gui
> TL> the old one ain't smellin' yet
> What you mean in term 'GUI'?
> Yes, with large monitors we can forget about window switching, but now
> most of Plan 9 programs have only console version! When you want
> create application with buttons, entryes, list boxes you need draw it
> by self...
>
> RM> With multiple desktops, as much as I like rio, I find it easier to use
> RM> flwm and swap around with CTRL-F[1234] etc.
> See! People need advanced window manager!

Maybe the ability to create a container frame.  The interface could be
similar to ``win'' and Acme, but allowing you to run any type of
application within the frame.  You could create this frame, associate
applications with it, and click within the frame to toggle between the
applications it's managing (which could be any type of application,
graphical, etc).

This could be useful as you could tile your windows initially and
assign applications to each container as required, similar to ``tab''
functionality many UNIX WM's have.

This would increase manageability on displays with many clients.

Re: [9fans] Evolving rio / GUI development

[Rob Pike]

You might want to read the paper I wrote long ago called
"A Concurrent Window System.".  8½ and rio arose from those
ideas, although they sacrificed a lot of the generality.

-rob

Re: [9fans] Evolving rio / GUI development

[McLone]

On Thu, 17 Feb 2005 16:02:33 -0500, Rob Pike <robpike@gmail.com> wrote:
> "A Concurrent Window System.".  8½ and rio arose from those
> ideas, although they sacrificed a lot of the generality.
why WM is in Rio? can they be divided? or we'll got another X?

-- 
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: [9fans] Evolving rio / GUI development

[Russ Cox]

> > "A Concurrent Window System.".  8½ and rio arose from those
> > ideas, although they sacrificed a lot of the generality.
> why WM is in Rio? can they be divided? or we'll got another X?

They already are divided.  Insofar as the analogy holds, rio is the
window manager and /dev/draw is X11.  Graphics can be used without rio:

slay rio | rc
acme

Russ

Re: [9fans] Evolving rio / GUI development

[Ronald G. Minnich]

I tried doing rio-in-rio to do multiple desktops but it got clunky fast.

(that's why I was trying to figure out how to do borderless windows and
failing badly :-)


ron

Re: [9fans] Evolving rio / GUI development

[rog]

> (that's why I was trying to figure out how to do borderless windows and
> failing badly :-)

name the window image starting with "noborder".
i don't think this is documented.

Re: [9fans] Evolving rio / GUI development

[geoff]

I use rio-in-rio all the time: use cpu to start a cpu-server window
and run rio in it.  Then each window swept there is automatically
on the cpu server.

A practice that I've found useful to keep track of unhidden windows
is to make sure that each window's upper left corner remains visible
(at least within its innermost rio) even when other windows obscure
portions of the window in question.

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> Yes, with large monitors we can forget about window switching, but now
> most of Plan 9 programs have only console version! When you want
> create application with buttons, entryes, list boxes you need draw it
> by self...

You have libcontrol.
But what I've discovered - after moving to Plan 9 - is that a text-based
user interface is intrinsically more powerful than a mostly grahpic one.
A typescript system is like a user-programmable GUI except you don't
have to program it! Give it a try.

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Tiit,

Friday, February 18, 2005, 2:15:53 PM, you wrote:
TL> You have libcontrol.
ok, how much program you write with it? Where list boxes in this
library? Does it maintained?
TL> But what I've discovered - after moving to Plan 9 - is that a text-based
TL> user interface is intrinsically more powerful than a mostly grahpic one.
TL> A typescript system is like a user-programmable GUI except you don't
TL> have to program it! Give it a try.
In some case yes, and all OS have console, and many user use it
(including me), but gui most intuitive and simples

--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> In some case yes, and all OS have console, and many user use it
> (including me), but gui most intuitive and simples

Console != typescript, not even close.
Think Acme (or Oberon).

Re: [9fans] Evolving rio / GUI development

[Sergey Reva]

Hello Tiit
Friday, February 18, 2005, 3:18:41 PM, you wrote:
TL> Console != typescript, not even close.
TL>> A typescript system is like a user-programmable GUI except you don't
TL>> have to program it! Give it a try.
Oops! Sorry, not fully understand english, what meaning typescript in
your post?

--
http://rs-rlab.narod.ru                            mailto:rs_rlab@mail.ru

Re: [9fans] Evolving rio / GUI development

[Tiit Lankots]

> Oops! Sorry, not fully understand english, what meaning typescript in
> your post?

A typescript system is one, where any text on the screen is just that -
text, and can be edited, etc. At the same time, any text on the screen
is a potential command waiting to be executed. Acme is pretty much a
definition of a typescript system. It has had Oberon (obviously) as one
of its prime inspirations. It is amazing how powerful these things are.

Re: [9fans] Evolving rio / GUI development

[McLone]

On Thu, 17 Feb 2005 07:50:14 +0200, Sergey Reva <rs_rlab@mail.ru> wrote:
> >> Because other more advanced (more friendly to user).
> M> complicated configs != user-friendly
> Most of modern GUI have gui configurator
...which just isn't enought for, say, fvwm2. Yes GUI configurator can
do basic settings, like focus policy etc, but what if you need
"personalized desktop environment from scratch"?

> incompatible GUI's, as result we got manu programs, may be good but
> uses different gui library...
> program): one for KDE, one for Gnome and one which not use this library...
don't forget that only Motif is "full" toolkit; neither Qt nor GTK
can't do X resources IIRC

--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for translit

Re: [9fans] Evolving rio / GUI development

[andrey mirtchovski]

with rio i can sit behind somebody else's terminal and use it without
having to read a 100-page manual on their key bindings, virtual
displays configuration, focus behaviour and menu buttons.

rio gives you great functionality.  throwing that away because it
doesn't implement your particular pet-peeve is like cutting the forest
to make more room for fresh air.  (and no, this comment isn't directed
towards ron, he has his own version of rio with virtual displays and
focus-follows-mouse.  that's what happens when you're the ruler of
minions ;)

Re: [9fans] Evolving rio / GUI development

[Steve Simon]

I find I hadly use "rio" at all. The only window I hide is
my vnc session which itself only ever holds IE6 (yea, I know).

I beleive a lot depends upon what resolution you run the display at,
I run at 1080x1024 which is just enough. 1024x768 on my laptop is painfull
Ideally I would run at 1600 odd but my monitor just isn't sharp enough.

High resolution displays are wonderfull and allow you room
to just put things anywhere and still see them, think of the
traditional desktop metaphor - how would you cope with a 3 foot square
desk?

-Steve

Re: [9fans] Evolving rio / GUI development

[andrey mirtchovski]

i rarely manage rio either. i do much more 'managing' of windows
inside acme, where there are some strides made with automatic cursor
placement and windows resize. i suggest you look there for
inspiration.

Re: [9fans] Evolving rio / GUI development

[McLone]

On Wed, 16 Feb 2005 11:37:45 -0700, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
> i do much more 'managing' of windows inside acme, where there are some
> strides made  with automatic cursor placement and windows resize.
Strides? Hmm. For me acme's placement heuristic seems almost natural
and indeed convenient.

--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for emgrish

Re: [9fans] Evolving rio / GUI development

[McLone the Great]

On Wed, 16 Feb 2005 11:45:14 -0600, g01495@gmail.com <g01495@gmail.com> wrote:
> I find rio very usable, but I also find I spend alot of my time "using
> rio".  When I say this I mean moving windows, organizing the screen,
> hiding windows, resizing things.
I won't comment rio, used it not so long; but for X window...

17'' all around, at 1152x864 or 1024x768; almost all windows -
fullscreen, so i'm using mostly Ctrl+A because of nested screen(1)s
and Win+A because i bind virtual desks to it. In case of 1280x1024 or
better, i use Alt+Tab etc, so good task-switch-previewer is a must [as
in MacOSX/Aqua]. Personally i dislike window hiding - shading is for
me. Also i found tabbed windows useable [as in fluxbox-stable] on
high-res displays

My X wm's often driven by keys, not mouse. I have bindings in
{open,flux}box or {bad,evil}wm to place windows in a smart way, so
they don't move in a merely weeks.On a mouse i use wheel.
Win32/gnome's/kde's etc. WMs/DEs all unuseable as for me, and i don't
need no taskbars/icons/applets. Think "CUI freak".

> What does everybody else think about this?
to think not in a main[stream] "slab" is a task for chosen one.
Especially when one talks about GUIs.

--
wbr,                        |\      _,,,---,,_           dog bless ya!
`                       Zzz /,`.-'`'    -.  ;-;;,_
McLone at GMail dot com    |,4-  ) )-,_. ,\ (  `'-'
  net- and *BSD admin     '---''(_/--'  `-'\_)   ...sorry for emgrish

Re: [9fans] Evolving rio / GUI development

[Kenji Okamoto]

> Where will rio (or it's successors) end up going?
> 
> What does everybody else think about this?

Rio is aimed just to devide the whole window to some smaller ones, 
and multiplex the keyboard/mouse events for the focused window.  
That's all I believe.
There are some other neat things in rio, however, I suppose it's just for
minimum.

Then how to make GUI programs for Plan 9?
I think this is still open to everyone.
Why? probably, rob had no time or got older?☺

We have control library (control(2)), however, I think there is no good
consensus that it's should be the upper level GUI library for Plan 9.
(Sorry Sape, I'm not abusing you. _o_)
Regarding this, look at inferno which has the GUI developed in the same
laboratory, and uses one button GUI interface (Tk) different from that of acme.   
When I saw it first, I thought they probably had no enough time to make 
completely new GUI scheme, however, now, I believe that they believed 
it's enough!   I don't think its enough though...

In short, we have no good agreement regarding what should be the Plan 9 
GUI programming and/or user interface, I believe.

Young and talented programmer can try this, however, it must be painful
and brain consuming thing I think.   First of all, they have to forget any
existing GUI scheme.☺

Please correct me if I'm wrong.

Kenji