AltME groups: search

I just want to not have it wrap inside a single line.

Let me rephrase: if it did a replace/all on the *displayed* data.

what determines the size of the bar ? Sometimes I see it go half 
way across a layout, and sometimes fully across.

As widgets are placed a max-width value is kept. At the point a bar 
is placed its width, unless otherwise specified, is assigned the 
"current" max-width. For the typical case, where a bar appears on 
a line by itself and further lines will not increase in width, this 
is fine. In other cases, like a bar in the middle of a line, you 
should give it an explicit width.

Is the drop down list of a fixed size?  Can that be made proportional 
to the bounding functional group or window?

I'm also coming around to your POV on table data format (each row 
being a block) as that allows non-displayable columns to be present. 
(I'll probably add a "blocked" type option to RebDB for my own purposes)

Has anyone tested it against AbiWord yet? Does it let you insert 
(and scale?) images into a new document?

I've got round that by using a column width of .001.  It doesn't 
even create a divider in the table heading.

I find a frequent need in other applications to close down popup 
windows with the escape key.  So, perhaps an option like this for 
RebGui windows?

CTX-REBGUI/COLORS is an object of value:
	window          tuple!    236.233.216
	widget          tuple!    244.243.238
	edge            tuple!    127.157.185
	edit            tuple!    255.255.255
	over            tuple!    255.205.40
	menu            tuple!    49.106.197
	btn-up          tuple!    200.214.251
	btn-down        tuple!    216.232.255
	btn-text        tuple!    77.97.133

CTX-REBGUI/EDIT is an object of value:
	...
	tabbed          block!    length: 5
	hilight-on-focus block!   length: 2
	caret-on-focus  block!    length: 4
	action-on-enter block!    length: 3
	...

ctx-rebgui/widgets/set-sizes unit-size font-size


Plus many widgets have various option flags to control some aspect 
of their behavior.


Probably not skinning in the true sense but enough to change basic 
scale, colors and behaviors to cover the major use cases as they 
have been presented to me thus far. Skinning that lets you change 
"look & feel" to the extent that the GUI can mimic native Windows, 
OSX, C64, etc could be done but at what price in complexity and delivery 
time? And what percentage of folks would just stick with the default 
look & feel anyway. Another way of saying this is to ask whether 
it is a good idea to put 80% of your effort into satisfying the needs 
of 5% of your user-base?

In fact I find it nicer than traditional OS look. and RebGUI tries 
to mimick OS a bit.

Right at the beginning of RebGUI I asked if anyone had good pointers 
to a consistent graphical style that we could follow (other than 
WindowsXP, Mac OSX, KDE, etc) ... in the ensuing silence I chose 
to go what I'm familiar with, XP. I'm still keen to have a modern 
looking REBOL style that doesn't look too out of place on Windows, 
Mac or Linux; but I'm not a gfx guy. Jaime's BEER interface (the 
GUI config front-end) is about the best I've seen far.

So, that's a direct compliment for RebGUI.

Making the GUI look right and not just a copy of something else is 
tricky. I often think about it. I also had to deside with Canvas, 
both for the tool panel and the requesters. I went with a very basic, 
clean style for the requesters, maybe even a bit boring.

I see two needs. One is for 'normal' application like business application, 
where the GUI shouldn't for any sake come in the way. A basic, clean 
look is needed for that. The other is 'special' application, that 
would benefit from something more eye-candy like. Examples are a 
visual remote control, or a music player.

I'm wondering, if users on the different platforms, that REBOL runs 
on, would find it very strange to use an application, that doesn't 
use the normal GUI look for that platform. I remember some guy (a 
developer, I think) many years ago, that would trash an application 
immediately, if it didn't use the OS own GUI.

In the 90'ies 3D styles were in, and it was overdone. It's interesting 
to see the GUIs choosen for games. Star Wars Galaxies use a solid 
colour for the edge of buttons, no 3D at all. Like the original Macintosh 
did.

The fundamental thing which makes one GUI better than others is consistency. 
 period.   design is all about making the looks and feel work for 
target a target audience, but if its inconsistent accross the experience, 
then its instantly unusable for anyone. 
.

I am inclined to agree that consistency is important in GUI design 
(imo. down to the last detail, it reflects competency), but *the* 
most important thing is that form meets function, and a part of this 
is selecting the best possible visual metaphor for the task at hand. 
 While widgets are a means to this end, it's all too easy to overuse 
them.

Now having said that, style is important too.  To most observers, 
WinXP looks better than Win2k looks better than Win98 looks better 
than Win95 looks better than Win3x looks better than ... etc.  Now, 
if you go back the way and use a Win95-style app in WinXP (even the 
Rebol security requester) your (or at least my) first reaction is 
'what's wrong with this app'?

I've thought much lately about the difficulty in introducing a third-party 
style into any given OS environment (which we as cross-platform developers 
must consider short of using native libraries) and it is difficult. 
 The subtleties of eg. OS X and WinXP are far different, so is there 
a happy medium?  I'd like to think so, but having tried /View on 
OS X, I'm not so sure that my previous attempts at platform-neutral 
GUI style are as successful as they could have been (though anti-aliased 
fonts may be a key missing feature).

as for me, I can accept different look, even a bit different app 
logic, but not behaviour - keyboard navigation ...

On the one hand, I think that 'form follows function' allows some 
deviation from platform-native style, though this is recommended 
more on a per-application basis (ahem, declaration of interest here). 
 On the other, we can select certain graphics based on platform (system/platform) 
... sorry Petr, still on a riff here ...

Carl's idea, that e.g. 'list style has to allow borderless design 
is pretty right. Go and look at MS - they WILL come to our living 
rooms with some devices, and you would not want your OS to pop-up 
- but apps will be important. Well, I speak of a different target 
market, but ...

that some kind of apps do not strictly need to keep OS metrics, as 
OS is then just a medium - irrelevant ...

I work with 300 users, met thousands, I don't agree with you too. 
Someone created a myth imo ... I think that who pays most attention 
is - computer geeks to have something to talk about :-) Each IS here 
has its own set of logic. I am after consistency, but not necessarily 
consistency with OS as a crucial point of app UI usability ...

just to not understand me wrong - I reak KDE (or was it GNOME) material, 
few referenced here articles on that topic, I can agree, but I just 
don't think that different design is a show stopper. at Devcon, there 
was a mention of Skype - how does IM messengers keep most other OS 
apps usability logic? :-)

shadwolf
	tabpanel with scrollable header - being added to 0.3.8
	menu - see note below
	listview - being added to 0.3.8

 treeview – data structure should be simple & consistent with other 
 widgets ... sub-blocks are the obvious way to go but I'll leave the 
 implementation choices to you ;)

Menu Widget


I am of the opinion that a menu widget is more trouble that it is 
worth as:


1) Its use is being discouraged in modern UI design (toolbars have 
made them obsolete to a great extent) - they feel just so Win95 these 
days

2) Mac OS X does not use them at all (at least at the application 
window level)

3) A fully-fledged menu widget is practically a UI in its own right 
with menu entries having icons, toggles, key shortcuts and various 
other mini widgets

4) The underlying REBOL popup system needs fixing first (this also 
impacts the edit-list, drop-list and context-menu widgets)

5) It's just too complex to meet the definition of a simple RebGUI 
building block widget - our time is better spent on other widgets 
that are required

6) How many users clamour for menus these days? Most folks I've met 
prefer pressing a single button / icon and positively detest multi-level 
menu selection

All my opinion, so feel free to disagree.

UI Design


Chris / Pekr touch on very important points here ... we have to live 
with the fact that we are trying to create a cross-platform UI. This 
UI must:


1) Look & feel relatively familiar to users on Windows, Mac and Linux

2) Be internally consistent (e.g. RebGUI widgets behave in a consistent 
manner, have a similar look to each other, etc)

3) Be externally consistent where expected (e.g. scroll buttons at 
each end on Windows, grouped on Mac; tab-panel look, etc)

The way to achieve this, IMHO, is:


1) Don't try to mimic one particular OS too closely (i.e. try to 
pick a neutral look - I think users of an OS are more tolerant to 
something that looks different as opposed to something that looks 
like it belongs to another OS)

2) Adopt the lowest-level of common functionality across OS's where 
possible (e.g. down arrow functionality is pretty well defined)

3) Make allowances for minor, but common, differences (e.g. tab-panels 
are rendered quite differently between Windows and Mac, system fonts 
differ, buttons appear quite different)


So in practical terms I want to gradually move away from a WindowsXP 
look and start adding a few conditional look & feels depending upon 
OS. These will not fool anyone into believing a RebGUI app is native, 
but at least Windows users will not be left feeling it's a Mac / 
Linux app or vice versa.

menu: I agree, what I like a lot are circular context menus (right-click). 
There icons are arranged in a circle around your mouse cursor. Makes 
selecting the function very fast and is totaly easy to use. Adding 
a tooltip feature to show a short text in case of a mouse-over makes 
sense. More I wouldn't add.

Look & Feel: Getting close to OS look but still let it look different 
is a good idea. Users won't expect exact behaviour. The GUI must 
be simple to use. That's it. Tooltips are IMO a very good quick-and-dirty 
help-feature.

Shadwolf/Tree-Widget: I used Cyphre's one. The main trouble I found 
out is changing the tree. A path access structure would be nice. 
Things like: add-entry tree/1/2/3 "New Entry" or with a named path: 
my-tree/material/copper/price or so.

I'm looking forward to see a tree-widget in RebGUI. This will make 
it mostly complete for a good bunch of applications.

As Ashley gave us right to disagree, here is a slightly different 
POV :-)

To menu or not to menu. Menu widget, as well as tree one, is a case 
for subdialect. Just go and look at Cyphre's one. You just use sub-language 
to define it - item, action, icon, accelerator key, position in structure 
(block of blocks) etc.

I agree with Robert, that RebGUI is almost complete. That is still 
the main obstacle with VID, it is feature incomplete. Although there 
are some styles out there developer can use it, it simply does not 
come with standard rebol distribution. I am a bit disappointed, that 
Gabriele said in RT Q&A group, that we will at least know, WHAT actually 
is planned for VID and that we will know it "soon". But if "soon" 
means two months from conference just to tell what is planned, then 
how "soon" such plan can be realised, right?

just my 2cents regarding menus: what I really would like as well 
is what Robert told about, circle menus. They're far better than 
rectangular menus (in most cases anyway used for  context menus). 
The big advantage is, if done correctly that one can use them blind 
via forming a habit. This means of course that the content must not 
change (anyway a principle a good UI should obey). So one can simply 
right click (or whatever action to activate the menu) and go with 
the mouse in a certain direction and release, all in a fraction of 
a second and be sure to have selected the right item. For beginners 
the menu can appear and be visible, but for somebody who formed a 
habit it doesn't even have to be long enough visible to actually 
see it - because the whole item selection was faster than that it 
could appear.

One of the drawbacks is, that one can't put as many items as in a 
rectangular menu, best is 4, but maxium probably 8 items if there 
are 8 sectors for the circle. But I like to think about it in that 
way that one can form the mouse menus more levels (probably only 
two make sense), in that way that after selecting one item a second 
circle appears which can offer more choices. And because this can 
get habitual again it's very userfriendly for both experts and beginners 
without forceing either to something. For instance I think the useability 
of Operas mouse gestures is an example for tree menus which don't 
even appear. But in principle one could think that upon pressing 
the right mouse button a circle appears and moving to the item downward 
opens another menu so that moving again to the right selects the 
close window item. The only problem with submenus might be that it's 
kind of hard to find a good middle way for the distances the mouse 
cursor has to travel and error tolerance.

Wouldn't that be really something worth implementing in Rebgui ? 
:-)

I gonna try to implement these menus sooner or later, but looks as 
right now it might be rather later. :-(

Also I would like to agree with Pekr, that icons and bubble help 
aren't really always the best ways to represent things. One could 
argue (and agree with some studies or opions) that icons are not 
helpful in learning an interface and as Pekr told, once you know 
them you don't know them because they have a good symbol or picture 
in them, but because you spacially remembered the position and can 
go straight to the point you know the sought for command is. Same 
with bubble help. Actually it's just kind of way to explain your 
bad icons, because else nobody knows what they are doing. 

So I agree that bubble help should be there in order to have them 
because people will still use a lot of icons and have to explain 
them, but better use a compromise as done with Opera, where you have 
the fancy icon but can turn on the textdescription of the icon, so 
that it appears below. Then you know what the button means, but have 
the fancy picture too. Stupid thing is just that you lost some screenspace 
to the BAD picture above the GOOD textual description. :-) Ok some 
people tell me now vice versa. But really one should think about 
what a small icon tells. The designer of course knows there meaning 
- but he's not the only later user.

there is a master thesis or something about this I once read, I try 
to find it ... other than that there was one Rebol guy who tried 
to do it, but it was slow

Since i am weak on math: Has someone a formular to find the right 
piece for the mousecursor?

and about the example: unfortunately I never used one - just that 
you have a pie which is put into pieces and because one knows where 
is north and south and so on, one can use it without even looking 
at the menu. (of course it can't be too finegrained, because who 
can move the mousepointer within an angle of a view degrees ?)

so Pekr: I don't know whether you use Opera, but I just imagined 
they could use some kind of pie menu in the background for their 
mouse-gestures, you just don't see them. Maybe that's a bit simpliefied 
but I really think that in general it is not such a bad model

Very cool. Does not need to be a pie, we could use text-facesaround 
the mouse?

what do you mean ? I don't understand. I almost forgot how I like 
these things. :-) Actually the fastest zooming I have seen - I know 
the piccolo toolkit a little bit, and I don't remember it to be that 
fast with so much text

and I would like to have a Rebol UI done the zooming way, but after 
my little tests I found it to be too slow for larger amount of data, 
especially text - but I thought about something similar but with 
steps, so no smooth zooming, this should be possible with Rebol

pretty smooth - maybe I have to try it one day ... what I did was 
put a lot of text in Carls first test of the transformation matrix 
example, where he wanted to know if the behavior is correct - and 
if you have a lot of text and zoom into it, it gets slow - but there 
are people here who know better (and might prove me wrong) - for 
me it would be too nice if somebody proves me that the same stuff 
as in the link is in sufficient speed possible with Rebol, even if 
there has to be some clever arrangement of the objects to be shown 
- I mean that objects not visible don't get rendered

That Zomit interface works poorly with a touch pad.

Or a mouse in my case. ;) Anyone have any links / screenshots to 
some good [non-HTML] implementations? (Windows or Mac OS X)

I guess so, Second LIfe has also pie menus. 

Graham: this didn't mean that there are other ways to use menus and 
of course depending on the input device there are better ways. If 
you have keyboard shortcuts for everything you can even be faster 
in doing things. If you have a scroll wheel zooming into is pretty 
natural as is paning with a extra button - but didn't anybody feel 
that in this zoomit demo one could surpisingly well use the interface 
and especially with what speed ? (just compared to putting the same 
functions to a traditional context menu)

Also one should just try to use mouse-gestures in Opera - after using 
them you always want to use them - even though I often out of habit 
do the same in IE or somewhere else and it doesn't work - the most 
important thing to note for me is that it's worth having an interface 
one can form habits in using it - only then usage will be very fast. 
If one puts the one or other stumbling block into it, it will never 
flow, you always have to concentrate on what you're actually doing. 
Just imagine driving a car and having always to think about how to 
steer or shift (for many of the european people :).

Take a look at: http://www.think-cell.com/and watch the Flash, there 
you see the best circular menues I have every used so far.

If you want take a look at the manual, more screen shots.

Ashley, I'm going to send you a screenshot from my installation.

- I thought the discussion was more or less about traditional menus 
at the top of the window or screen. I think context menus are very 
helpful as they support nicely the object-verb pattern and as long 
as they are designed the way that they don't change unexpectedly, 
they are good and the user can form habits (Jef Raskins book "The 
Humane Interface" is a lot about this stuff)

- and they should support this kind of blind usage - then they're 
a big leap I think

I've never been a big fan of traditional context menus as they tend 
to get overloaded (you know things have gone too far when they are 
scrollable and have sub-menu's!) and the "target area" for selection 
is just too small (selecting the 3rd item quickly requires good mouse 
targeting). The first problem is an [application] design issue, but 
the second is solved nicely by this style of menu. 


Having said all that, I'll probably add two widgets: context-menu 
and bubble-menu which will be functionally and declaratively identical 
but with different look & feels.  Besides, I'm intrigued by the design 
challenge of this particular widget - I'm thinking multiple faces 
(one for each menu option) with a draw effect for the bubble and 
text ... hmm, but how to only register mouse clicks within a circular 
area ... and how to have pixels outside this area be transparent 
...and ...

One one trick could be a big sensor over the whole window.

And Chirs had a similar problem for non-rectangular faces. The idea 
was use a shadow-bitmap where colors represents choices.

Ashley, have you reconsidered allowing images to be inline rather 
than a file! type only ?

No announcement. ;) I think it was introduced around 0.3.2 when the 
layout function was split off into a separate script.

Lot of changes scheduled for 0.3.8 - aim is to get it out within 
a week.

How about adding a slider to the title-group widget to allow scrolling 
of the text in the title-group ?

Just cross-posting Geomol's styles: http://home.tiscali.dk/john.niclasen/canvas/newstyles.r
Might be a nice base for RebGUI.

Nice clean look. The "button-group" widget (buttons numbered 1 - 
4) would make a good addition. Good idea that.

You mean there's a hover visual notification?

I didn't know "frame" was a shortcut for "edge [...]". How long has 
that been in VID? Nice code BTW, I think I'll add it.

It's nice, but it's not really a style.

Is there an easy way to change the image in a title-group, *and* 
have the pane holding the text change accordingly ?

Is there a way to do menus in RebGUI?

min-size: This feature is only applied after the first try to resize 
the window. Than it's used, at startup time, the window has a "default" 
size. Whereever this size comes from.

table: if a column has the width of the sort arrow, it's no longer 
possible to change sorting order after clicking once.

tab-panel: will investigate
min-size: from the display users guide:

2.1.2 Min-Size

Specify a minimum OS window resize size.

display/min-size "Example" [
    tight
    text 80 blue "Some text" #W
    return
    box 80x40 #WH
] 400x400

Note


The min-size limit will only be enforced upon a window resize, and 
the size is inclusive of an OS specific number of border / title 
pixels. Also note that if any widgets are resizeable (#H and #W) 
and min-size has not been specified then RebGUI will assign a default 
value equal to the initial window size.


table: Already noted by Graham (arrow does not share label feel) 
- will add to list

Most of those issues are with RebGUI / View itself not Graham's application. 
Next release of RebGUI, which corrects a large number of outstanding 
issues, is waiting on the imminent release of View 1.3.2 (which among 
other things fixes the 'parent option).

we discussed this point  at the treview begining  ...  we have  [[ 
widgets desc ] [  datas to apply to widgets ]] this struct allows 
dynamic datas changes and sortings with low cpu use. treeeview is 
over  code is tiny and all is there to add more dynamic widgets  
but as  we  want to make a grid widget i don't see the meaning of 
adding to treeview the capability to get edit fields  -> note: actual 
fields can be turned as editable on a certain  key + mouse shortcut 
instead of have a special editable widget. Last source are on  http://www.rebolfrance.info/articles/regui-cooking-widgs

actually i'm fulltime dedicated to get a job so i'm not a lot around 
there anymore  but i stay tunned time to times and if you get major 
problems you can yeld me by mail etc...

shadwolf, I'm having a bit of trouble integrating listview52. Copying 
the code and removing all "ctx-rebgui/widgets/" paths gives the following 
error:

** Script Error: Invalid path value: edge
** Where: view
** Near: show face/pane/1/pane


which is odd as your code never explicitly refers to edge. As you 
are more familiar with the code, could you have a quick look at merging 
it into your copy of %rebgui-widgets.r (v 0.3.7) and upload the working 
result.

How do I use the offset for a widget? Where to put it? I want to 
do the following:
wid1 50x50
return
wid2 50x50
return
wid3 50x50


and now I want to place the next widget right to wid1 and inline 
with wid1.

tab-panel: Is it possible to specify a color for the tab text?

How is the default size for a group-box determined? IMO it should 
default to the min-size to include all contained widgets.

I don't think there's a guide

And for the labels? Is there a trick too?

Robert, in answer to your first question:

display "" [
	field 50x50
	return
	field 50x50
	return
	field 50x50
	at 52x0
	field 50x154
]

display "" [
	field 50x50
	field 50x154
	at 0x52
	field 50x50
	return
	field 50x50
]


(the later does not work correctly under 0.3.7 - adding a simple 
"max-height: 0" to the 'at rule in rebgui-layout.r fixes this under 
0.3.8).

tab-panel: Is there a way to add an action block that's executed 
before switching to a new tab? IMO this would be very handy. For 
example I want to show/hide screen elementes depending on which tab 
the user clicked.

if you want to change the layout of a tab in the action block .. 
you can.

Yes, but this makes a bit complicated. I need to show two tables 
if the user clicks two specific tabs. And hide them if the user clicks 
ANY other tab. And I want to avoid adding an action [hide tab1 hide 
tab2] to all other tabs.

Because if I have a change, I need to touch a lot of code to keep 
this in sync.

I know, I can write a function and just add action [hide-tab] but 
even this needs to be added to all tabs.

I also have a common set of buttons that are shared by all tabs. 
 I detect which tab is visible, and perform the relevant action

I originally had only one action for a common button, and the action 
for that button was revectored on clicking the tab .. but that got 
too complicated too quickly

So the buttons are displayed outside the tab and have a context sensitive 
action block?

Is there a way to specify an input-pattern that is only allowed for 
fields? Like number etc.?

Ok, next one: I need to start an action as soon as a field looses 
the focus. Is this possible? I need to trigger a re-calculation.

How adding this is a generic pattern of function calls? IMO very 
useful:
	inbound-action
	widget-action
	outbound-action

That plus a lot of other problems with area have been fixed in 0.3.8.

Better than GPL:


RebGUI is a community project that is free for both commercial and 
non-commercial use. Dobeash Investments Pty Ltd retains copyright 
on the name RebGUI and the concepts embodied in the display function 
as well as all associated documentation other than that which covers 
REBOL/View Facets.

Code submissions, in particular widgets, will 
be accepted and credited to the author under the condition that they 
carry these same licence conditions.

WOuld like a textface which does that automatically.

focus would look for a face/focus function while unfocus would look 
for a face/unfocus function. So the code might look like:

	...
	field unfocus-action [do-validation face/text]


the validation, if it failed, might shift focus back into the field 
the user tried to leave. Something like that I guess.

Would there be a way so that the default action is triggered by an 
unfocus event ?

how i understand this bug ashley RebGUI widget compositor expect 
to find a edge field in this object and as it doesn't it crash

odd problem i don't see a solution ...

Given that it worked stand-alone, my guess is that one of the make's 
was referring to "something" in the global context (face, feel, pane, 
etc) which enabled it to work. Regardless, it's a very obscure error.

events: IMO a very, very important thing to add to RebGUI. Think 
about your apps. I always need this feature and most frameworks etc. 
don't support it well. The problem is, that if you have to add it 
yourself, the code becomes hughe and complicated for maintenance.

Adding a focus / unfocus action sounds like a good way to do it.

A way to set default focus / unfocus action would help keeping the 
code clean. With this I could change the default action on the fly 
and all new widgets would than use the new version. Makes building 
up forms a lot simpler.

Anyway, so how to solve my problem at the moment? I'm stucked without 
a solution to this.

How's this for focus / unfocus trigger logic?

1. Add two user-definable action handlers to ctx-rebgui

	app-focus-action: func [face] [true]
	app-unfocus-action: func [face] [true]

2.Modify the ctx-rebgui/edit focus and unfocus functions:

	unfocus: has [face][
		if face: view*/focal-face [
			unless face/unfocus-action face [return false]
		] 
	...

	focus: func [
		"Focuses key events on a specific face."
		face [object!]
	][
		unless unfocus [return]
		if face/show? [
			unless face/focus-action face [return false]
	...

3. Extend the standard rebface definition

4. Add the following to the layout function:


 focus-action: either attribute-focus-action [make function! [face 
 /local var] attribute-focus-action] [:app-focus-action]

 unfocus-action: either attribute-unfocus-action [make function! [face 
 /local var] attribute-unfocus-action] [:app-unfocus-action]

which would then let us write code like:


 ctx-rebgui/app-focus-action: func [face] [face/text: form random 
 1000]

	display "" [
		field
		field focus [face/text: form now/time/precise]
		field
	]


The logic is simple: "Execute the default focus / unfocus functions 
(which in turn default to true) *unless* a focus / unfocus function 
has been provided for the face. When a focus / unfocus event is called 
execute the assigned handler function *first* and only proceed if 
it returns true."

Does this meet the design requirement?