AltME groups: search

I use the group box as a visual container and not a functional one

1) display mod - just by adding "view-face" at the end of the function 
I presume? Does that give you what you need? (I was thinking of adding 
a "no-show" type refinement for folks who wanted display to return 
a face *without* doing a view - to-image being the main usage case)


2) Window options - needing to set these implies a new widget is 
required or you need more control than RebGUI was designed for


3) Group-box is a functional grouping, tabbing between widgets within 
the same group-box is normal behaviour - what is missing is *another* 
mechanism to tab into and out of group boxes

in the radio group though, I have a form already up, and I am pulling 
in data from a file to repopulate the form.

So, in the do block of the window, I am reading the data from a file, 
and then settting all the values.

r: radio-group 30 data [ (blk/5)  "M" "F" ]


Except doesn't this mean I now will need two versions of the same 
layout?  One with compose, and one without?

I see the problem. Perhaps radio-group should treat none and / or 
0 as "no selection" as well?

I was thinking I was going to have to have a real table holding the 
data, and one for display purposes.

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.

Just wondering if it would be useful to allow rebgui and vid to operate 
together.  So, you could do all the easy stuff that rebgui allows 
you to do, and when you needed something it couldn't do, then to 
use Vid instead.

RebGUI and VID should work together as is. I've tried to avoid word 
name / context clashes for this very reason. Following should work:


 display "" [button "VID" [view/new layout [btn "Unview" [unview]]]]

Ashley,  btw, I've been experimenting with RebGui for  project I'm 
working on and it is quite nice. Thanks for your efforts.

Drop-list height is currently set to "min 5 length? items" lines. 
This should probably by extended to include the bounding face and 
the 5 should probably be designer configurable.

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

if used as the first columns.  I.e. I stuff all the non displayed 
columns at the front of column definition, and make their widths 
.001

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?

That was just theoretical question. I always depreciated old button 
flat look etc., but then I waw Bobiks new Tennis app and I have to 
say that if you come with good coloring, gradients, then it has its 
beauty ...

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

I think the interface mockup is outstanding. Was wondering what did 
you use to code it? I havent seen many applications that do not use 
the system scheme and still manage to look that sleek.

Congratulations 
and keep it up.

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've found, that using thick lines (for example around buttons) makes 
it look old and childish/unprofessional. Using thin lines looks modern 
and professional. Also big contrast often makes for an old/unprof 
(I lack words) look, while less contrast makes it look top-notch 
or like an architect/designer would prefer.

Also soft (rounded) vs hard (square) corners and gradients as opposed 
to solid colors. MS and Apple have spent billions to get this right, 
and there is still debate about whether they have! ;)

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.

I love the original NextSTEP look. It's wonderfully grey, boring, 
clean and sober. Boring, because you'll not be distracted and you 
can get work done.

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

Chris - hopefully RT does solve linux and os-x situation with fonts 
....

... and maintain small libraries of OS specific graphics.

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

In that case, you could have agreed with my original point and let 
me finish...

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.

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.

Some time ago, I read article about icons, toolbars, and what is 
wrong with them. I have to say, I do prefer menus, really. I work 
in various environments, seeing tonnes of icons. Robert answered 
the trouble with icons for himself, maybe he even did not notice 
there is the trouble at all :-) Suggesting tooltips - that is the 
first obstacle with toolbars. Basic operations as printing etc. are 
self-explanatory. But! Go, start few apps, which allow you to hide 
menu - use icons only. You will get in troubles instantly, waiting 
for tooltips (=text representation) to explain you the meaining of 
the icon.

Of course, buttons are easy to press. But only once you already know 
what action it will invoke. But then you don't even visually orientiate 
yourself upon icon image itself, the action you take is somehow conscious, 
and you just press some button on toolbar on some position, because 
you simply know, what it does ...

Ok, those were icons vs. menu. As for tree-view, menu, grid data 
blocks. It is still the same problem, of how to efficiently use rebol 
structure (block of blocks) to represent tree (=in the meaning of 
hierarchy here). If we think twice, we can see that similar discussion 
is being held in XML group. We parse XML, and want to store it somehow 
efficiently, being able to navigate to some path(node), to read some 
item, but also to change it 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?

Look at the latest announcements using the word "soon" and extrapolite, 
than you know.

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.

under publications there is the thesis of Stuart Pook "Interaction 
and Context  in Zoomable User Interfaces" ... actually I looked into 
it, I'm not 100% sure this is the one I remember, but I guess so 
... page 54  there is for instance something about these menus and 
before that there is also an investigation of different kinds of 
menus
by the way, did I tell that I like Zooming User Interface ? :-)

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

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

maybe I'm wrong and I didn't try anything fancy, but don't you think 
we might have problems in rendering the same stuff from the page 
you gave the link - I guess these things are accelerated by the graphics 
card and AGG is not, no ?

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

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.

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

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

And to think I had to write my paint module in VID as I thought this 
had yet to be done :(

hmm, my last message got lost probably. I sent it, and then I got 
AltME blue-screen instead of message list for this group, and nothing 
appeared. Kind of short disconnection? :-)

What I just wanted to point out is - those styles do look nice. However, 
they don't seem to reflect mouse-over effect. My question is, if 
we give-up on that. IIRC Chris pointed out, that you have to count 
with such things prior to starting your design. Also - what about 
reflecting in-focus styles? As we know, OS does count with it and 
reflects it visually, what about our Rebol UIs?

effective and short code

i didn't know it neither  ^^ jipé is full of suprise i love those 
 little and  full of trickies codes ^^

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

I can set the pane offset and the para origin manually .. perhaps 
needs an accessor function?

rebol []
stylize/master [
	agg-progress: box white "0%" with [
		pstart: pend: pfunc: none
		progress: 50
		oldprogress: 0
		update: does [
			if (self/progress <> self/oldprogress) [
				self/oldprogress: self/progress

    self/effect: compose/deep [draw [pen none fill-pen linear 0x0 0 (self/size/x) 
    25 1 1 red yellow cyan blue box 0x0 (as-pair self/size/x * (self/progress 
    / 100) self/size/y)]]
				self/text: join to-integer self/progress "%"
				show self
			]
		]
		append self/init [self/update]
	]
	rate 25
	feel [
		engage: func [face action event][
			if action = 'time [
				if (face/progress <= 100) and (face/progress >= 0) [

     face/progress: to-decimal ((face/pfunc - face/pstart) * 100 / to-decimal 
     (face/pend - face/pstart))
					face/update
				]
			]
		]
	]
]
view/title center-face layout/tight [

 agg-progress 250x11 font [size: 11 color: none shadow: none] with 
 [pstart: now/time/precise pend: pstart + 30 pfunc: does [return now/time/precise]]

 agg-progress 250x11 font [size: 11 color: none shadow: none] with 
 [pend: now/time/precise pstart: pend + 30 pfunc: does [return now/time/precise]]

 agg-progress 250x11 font [size: 11 color: none shadow: none] with 
 [pstart: 0 pend: 100 pfunc: does [random/seed now/precise return 
 random 100]]

 agg-progress 250x11 font [size: 11 color: none shadow: none] with 
 [rate: none progress: 50]
] "AGG progress bar"

stylize/master [
	agg-progress-pie: box white "0%" with [
		pstart: pend: pfunc: none
		progress: 50
		oldprogress: 0
		update: does [
			if (self/progress <> self/oldprogress) [
				self/oldprogress: self/progress

    self/effect: compose/deep [draw [pen none fill-pen conic (self/size 
    / 2) 0 (self/size/x / 2) 90 0.5 0.5 red yellow cyan blue arc (self/size 
    / 2) (self/size / 2) 0 (self/progress * 360 / 100) closed]]
				self/text: join to-integer self/progress "%"
				show self
			]
		]
		append self/init [self/update]
	]
	rate 25
	feel [
		engage: func [face action event][
			if action = 'time [
				if (face/progress <= 100) and (face/progress >= 0) [

     face/progress: to-decimal ((face/pfunc - face/pstart) * 100 / to-decimal 
     (face/pend - face/pstart))
					face/update
				]
			]
		]
	]
]
view/title center-face layout/tight [

 agg-progress-pie 100x100 font [size: 11 color: none shadow: none] 
 with [pstart: now/time/precise pend: pstart + 30 pfunc: does [return 
 now/time/precise]]

 agg-progress-pie 100x100 font [size: 11 color: none shadow: none] 
 with [pend: now/time/precise pstart: pend + 30 pfunc: does [return 
 now/time/precise]]
] "AGG progress pie"

There is no menu widget, and none planned AFAIK.

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

As for the GUI issues, I am confident that Ashley and contributors 
will fix those issues and so I have released it as is.  I don't resize 
anyway.

Ashley - I know, that is why I posted reply in this group, to actually 
see the reaction of when next RebGUI release is planned, and what 
it will address :-)

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

Ashley my ask to see those widgets implemented in REbGUI retail as 
it is not to bother you on the contrary the return i get on those 
widget was pretty low... So i think adding them to  retail RebGUI 
 will allow all REGUI fans to see the code to learn some tricks and 
to propose some new things  or bug correcting  ^^ So my ask is more 
 to dynamise and  relaunch the RebGUI process than to be bad with 
you ^^

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

Perhaps Ashley could include them and mark those not fully complete 
as such?

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.

And wid4 has the heigth from wid1 to wid3.

label / field: How to create labels and fields that are all the same 
size, automatically? I want all labels to have the width of the widest 
label and all fields to aligan left. For creating pretty input-forms.

And for the labels? Is there a trick too?

docs: tab-panel and action word isn't very clear to understand. Better 
to provide an example:
	tab-panel data [
		action []
		...
	]

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.

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?

ANd now you release it, sdk is out? :)

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.

Yes, no problems. You can also change and modify without any requirement 
to contribute back. Also, there is no requirement for attributions 
/ acknowledgements.

With regards to actions, I was contemplating adding pre and post 
action triggers that were fired on focus and unfocus respectively. 
I think the existing action / alt-action / dbl-action triggers cover 
the widget-action class sufficiently. Comments?

edges problems hihihih this kind of bug i absolutly don't have on 
my computer and  i don't know why ...

rebface is supose to yet include it and be an empty box lol

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

i use event show to restart the rendering and display then the changed 
content  (colum-countainer ) this all auto table rebuild when script 
simply call show listview-widget

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.

While I'm waiting on listview52 I'll see if I can slip some prototype 
focus / unfous trigger code and bubble-menu in for you Robert. ;)

After reverse, pad pads to the right and not the left as expected 
...( by me that is ! )

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?

Hi. Just looking through rebgui. A question and a comment. (1) In 
the readme.txt file there is a reference to Opera icons but no reference 
to the licensing of those icons. Where can I find the icon licensing 
information please?

(2) I like the table widget with it's sortable columns. But at first 
had problems with trying to sort in the reverse direction because 
I was targetting the sort indicator triangle which does not do anything.

1) These are provided as samples only (for %tour.r) and given that 
I could not find any reference to the licensing of them I added that 
note instead. If anyone has a source of good, free program icons 
then let me know and I'll get rid of the Opera ones.

2) Issue#44 at http://www.dobeash.com/it/rebgui/issues.html

Latest build available at: http://www.dobeash.com/files/RebGUI-038.zip

Issue log: http://www.dobeash.com/it/rebgui/issues.html


*** Unzip this file into your existing RebGUI 0.3.0 distribution. 
Requires View 1.3.1 (1.3.2 preferred) ***


This is mainly a bug-fix release with a new prototype event trigger 
system (see %"Demo - actions.r") and a very early proof of concept 
bubble-menu (see %"Demo - bubble-menu.r").


I'm particularly keen to see whether the event trigger system is 
flexible enough to remove [or reduce] the need for a dedicated (and 
hard to design / implement) one-size-fits-all "field validation" 
system as discussed previously. The bubble-menu demo shows how transparency 
and event detection within a non-square area *could* be done. The 
implementation is not perfect (or anywhere near usable) so I'm open 
to alternate design suggestions! ;)

- still - pop-up system non system friendly (not Rebgui issue, but 
rebol one's)

- I have some difficulcy with leds - If you would not provide me 
with text help, I would very hardly know, what those state means 
- I am not sure such style has place in standard pack ... or just 
- let it transparent for 'not-selected selection, green for 'on selection, 
red for 'off selection ...

- table - still you are able to scroll hilited row "under" the table 
style border - it should know it is at last displayed element and 
start scrolling, scrollers should reflect that. If there is no internal 
track of hilited row/cell, then it is not true grid system (I hope 
not)

- bug with text-list multi selection - there seem to be bug in math 
... press shift, hold it, hilite e.g. 6 rows. Still hold it, press 
some two rows below, it let's hilited only first two rows ...

Ashley, there's still a problem with area fields.  If you start typing 
in the area field in tour.r at the top of the field, when you reach 
the end of the line, and the word wraps, the cursor drops to the 
end of the area field taking you away from the line you are typing.