World: r3wp

I disagree.  Nested tabs are not the same as multiple row tabs.  
With the former you can effectively book mark a deeply nested page 
.. the latter you can not

bad design
 vs "good design" is just a matter of opinion ...

there is no intrinsic rightness or badness

I agree that the tree view has replaced multi-line tabs in recent 
years.

There might be slightly different usability issues with nested vs. 
multiline tabs. Multiline tabs are plain confusing (where is the 
right button?), where nested tabs can be disorienting (where am I 
or what mode am I in?). I've built an app in VID Extension kit using 
the latter method, and the app can sometimes be disorienting to use, 
so I had to help out by using different colored backgrounds.

Doesn't the tab colours help orient you?

actually not, since some tabs contain nearly identical UIs. people 
are not used to looking at the tabs at any other time than when selecting 
them.

Well, I have several hundred screens in my app ... not sure what 
else I can do to organize them

Also the nested tabs allows me to refer to a particular screen by 
a path notation

I was surprised at how "narrow-scoped" some users are, when working 
in a program, almost down to a single face, not noticing the larger 
context or organization of the program, particularly if the program 
has many modes (tabs). I think that its important to design UIs around 
clearly marked mode of operation, or even better: Have mode-less 
operation.

Are nested trees any better?

MS approaches this by using a "control panel" of icons

I prefer flat list that can be searched, when there are no other 
options. Old MUI preferences windows on the Amiga and the KDE configuration 
or MacOSX settings program comes to mind.

Each icon then deals with a particular subsystem

Not sure abou that approach as then the user ends up with lots of 
open windows

Right. The problem is usually that an item you are looking for, doesn't 
reside in the subsystem that you think it does, so when there is 
no other way, at least provide a flat structure search.

So, what are the exemplar GUIs in dealing with lots of information?

What does the mac do forinstance?

there is usually a method for searching for what you want. a typical 
mac app even allows searching all menus in the menu bar.

The modern version of the system dialog does a list on the left instead 
of tabs. It might look like a column of links in a left-side navbar, 
but it is basically the replacement for the tabs.

I do not like multiline tabs either, and they violate some of the 
rules of good GUI design.


Sure Graham, good and bad design are matters of opinion; however, 
they are based on what "most users" can understand and efficiently 
operate.  If a GUI causes a user become "lost" or do the wrong thing, 
then it's not a good design.

I don't like multiline tabs either but they're not the same as nested 
tabs :)

There is now Carl's blog upon how to easily list styles in R2. I 
posted corresponding R3 code, although it might be preliminary:

foreach [name obj] guie/styles [print [name "-" obj/about]]

But - I would like the GUI team to think about following aspects:


Imo the guie/styles list is highly insufficient. Imagine you want 
to auto-inspect (load) list of styles into your GUI designer. What 
you get now is a flat list of styles, where apart from 'table, you 
have its sub-styles like 'table-cell, 'table-row, 'table-header, 
etc. I am not sure that in the case of an IDE, you want to see those 
styles listed. OTOH those are legitimate styles, from which you might 
want to derive something, or just being able to change their aspects. 


So, I propose to resolve this situation somehow. The implementation 
is up to gurus, just few wild ideas:


- use tagging - tag style as 'main/root/parent, whatever - but - 
that introduces another field to the styles? Maybe not, because I 
expect some tagging system being available anyway?


- create guie/widgets, e.g.: guie/widgets: [table [table-cell table-header 
table-row] - that way we will be able to list just/only widgets as 
table, not having the list poluted with widget internals


- the above aproach might not work well in the case, when you aproach 
styles more as a CSS, not as widgets. Because - even e.g. 'table-cell 
might be derived from a totally different style, e.g. a box, or field, 
so I have no idea of how to keep track of those dependencies, but 
this is the area I leave for gurus to think about. E.g. someone changes 
box style and your table is influenced and user might be confused, 
why it happened. But I expect style/parent or something like that 
being available?

Maybe we need two separate things - style grouping (use gui/widgets 
for that), and style hierarchy - tree or other map of styles, their 
inheritance and dependencies (maybe this is what Rebolek now referst 
to as an object browser?)

Tags can be used, they are implemented.But, IMO, if you need a list 
of styles for a GUI builder, you better make a list manually.

> Imo the guie/styles list is highly insufficient. Imagine you want 
to auto-inspect (load) list of styles into your GUI designer. What 
you get now is a flat list of styles, where apart from 'table, you 
have its sub-styles like 'table-cell, 'table-row, 'table-header, 
etc. I am not sure that in the case of an IDE, you want to see those 
styles listed.


We already have and use tagging. The styles you mention should be 
tagged INTERNAL, if they are not already, as they are part of compound 
styles. So it's up to an IDE to discern that properly 


It might be possible to make a helper function that filters in only 
end-user styles, but we'll see how important that becomes.

dunno if having guie/widgets grouping would allow us to e.g. extract 
some style and its related code into separate file? I expect it not 
being so easy to isolate style/widget completly, as other stuff as 
event handling etc. might be involved.

But it's important to note that all styles are equal citizens in 
the R3 GUI. Tags are used for conceptual separation.

Rebolek - making list of styles manually is not imo acceptable. It 
should be auto-inspectable.

I propose to use guie/widgets then, to group related styles. By related 
I don't mean derived, but more of a compound styles - table is good 
example ...

As Henrik said, INTERNAL tag can be added to styles like table-row 
etc.

Actually, I will do it right now...

OK, I've provided you with some idea, now it is your team's take 
to discuss. Maybe such proposal could go into the long R3 GUI doc, 
before dismissed right away :-)

I need to finish the compound style document, so you can see how 
they are done.

OK, INTERNAL tag - at least something ... although it means two things:


1) adding INTERNAL tag to the style does not provide you with info, 
which widget it is related to

2) for listing only non-internal tags, you have to write special 
code to filter all internal styles away :-)

1) because one style can be related to several styles and new user-designed 
styles and also can be used dynamically by a style, depending on 
the situation.
2) a few lines of code.

Current list of tags (subject to change):

; set at stylize time
style-tags: [
	internal		; the style is intended for internal use
	panel			; the style is panel of other faces
	compound		; the style is a compound of part styles
	field			; the style is a field with editable text
	state			; the style is a user interactive state changing item
	action			; the style is a user interactive action item
	info			; the style is an indicator
	tab			; the style is part of tab navigtion

 auto-tab		; the style automatically tabs away on a specific event
	select			; the style contains user selectable text

 keep			; the style retains highlighting and caret after unfocusing
]

; set at layout and any other time
face-tags: [
	default			; the face is the window default
	focus			; the face is in focus
	disabled		; the face is disabled
	frozen			; the face is frozen
	dirty			; the face is dirty
]

; set at window creation time
window-tags: [

 form			; windows containing a validatable form or other field or 
 state faces

 inform			; windows containing only text or images and no validatable 
 faces

 popup			; windows containing a menu or selection, which when interacted 
 with, results in immediate return of a value
]

ad 1) I can understand that, and that was also one of my worries 
in my initial post. However, as a designer/programmer, wouldn't you 
find usefull to have:


- something like tree-view (or node based visual display) of styles 
and their dependencies?


- wouldn't it help your orientation to have some list like guie/widgets, 
grouping particular styles, just for your info? So that you know 
that e.g. table is being built using xyz styles?

I am just asking - so no offense please :-)

1) One internal style may be related to more styles.

2) Is this really a problem? I see no benefit of having such a simple 
function as part of R3GUI - because R3GUI doesn't need it.

I see no use forguie/widgets, style dependencies can be covered in 
documentation.

Henrik - tags - very nice!

1) It's possible to make the style tree, when the styles are being 
initialized. In fact I already have this as a separate script, but 
it has not been used lately.

btw - when I derive style by 'stylize, is there the 'parent field 
being set, so that the hierarchy can be created?

Tags are really trivial. They are just a list of words and we have 
a few TAG functions to set/unset/inspect them during runtime. It's 
entirely up to styles or the higher level code to use tags correctly 
and this is for example done with face navigation.

'stylize hierarchy, not at this time, I think. it would be easy to 
implement if we need it.

The hard part about tags is to name the right ones, so they won't 
overlap too much.

Was just trying out the r3-gui.r3 script and found out the fonts 
are hard-coded for Windows. I changed them to some Amiga fonts and 
the hello world GUI popped up. We'll need to find some way of handling 
fonts on non-Windows platforms via freetype to keep that script generic...

Thanks for info. Passed on to Carl.

ssolie - IIRC Cyphre reported here, that he has FreeType support 
done for A110, he just has to release it. That should help platforms 
like OS-X, Linux, Amiga IIRC .

Pekr: I'm using Cyphre's patch along with my own changes which enables 
the FreeType support on Amiga to function.