World: r3wp

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.

I've got one question. There's face/faces for all faces that are 
part of a face. There also needs to be some container for faces that 
are part of face but are not visible (hidden) right now. Currently 
it's called face/cache, but I think the name should be different. 
Any ideas?

face/hidden ?

Thanks! Native speaker is always appreciated when chosing right names 
for words :)

I'm considering a rewrite of the validation prototype as there are 
some parts missing with regards to initial state.


Have there been any considerations on how to use the DIRTY tag? I 
have some ideas on when DIRTY is set:


- The user creates an edit in a field, changes setting in a radio 
group, etc. It would not be enough to focus the face, but a specific 
action would have to be taken.

- When the user deliberately moves the edit back to the original 
state, the field is still dirty, so we can observe which fields were 
manipulated.

- Using a function DIRTY?, we can observe whether a field or a panel 
is dirty.

- It's not possible or logical to set the DIRTY tag programmatically 
(other by forcing it in with TAG-FACE face 'dirty)

It would be cleared when:


- Using a function CLEAN, we can unset the DIRTY tag in a face or 
panel of faces. This would be the only way to unset the tag.

- When the user deliberately moves the edit back to the original 
state, the field is still dirty, so we can observe which fields were 
manipulated.

 - I don't like this one. Than we should have a manipulated flag. 
 As dirty means: changed.