World: r3wp

This is to indicate new messages in a forum

fonts selector opens behind 

user interface" window" ... odd, does the same thing happen with 
color selectors from the same window? What happens when using the 
various requestors from %tour.r? What View version are you on? Anyone 
esle ever seen anything like this?

DBase approach is IMO good.

 ... Is there a concise reference somewhere online I can work off?

Any way to selectively change the row colors on a table?
 Not at present.

REBOL/View 1.3.2.4.2 16-Mar-2006 Core 2.6.3
Same problem for color selectors 
Using the requestors from %tour.r is ok.
(with REBOL/View 2.7.5.4.2 18-Mar-2007, i have the same problem)

OK, so the problem is with popups that call popups. When the second 
requestor (font or color) is called does it *initially* appear behind 
the calling requestor, or are you saying that clicking on the calling 
reqestor *allows* the calling requestor to come to the foreground 
and obscure the second popup? (This later behaviour is what occurs 
on Win & Mac).


Secondly, is the second popup modal (i.e. after it appears can you 
still interact with the first popup)? On Win & Mac the popup is truly 
modal (apart from the windowing issue, which I think can be solved 
by use of the 'parent option).

Graham - why don't you use grid? Is it incompatible with current 
rebgui version? It is not as powerfull as Henrik's grid, but surely 
few light years ahead of table. You've got very simple usage help, 
but workable imo ...

Ashley, the second requestor appears between the calling requestor 
("user interface") and the main window ("tour") and i can't interact 
with the calling requestor ("user interface').

Grid ?  Never thought of it.

No examples of grid given ... and Ashley has marked it as needing 
more work.

Frank, could you please test this fix for me. Edit %rebgui.r and 
replace the following:

	either parent

with:

	either any [dialog parent]


This *should* force the popup to appear and remain on top. Thanks.

table/select-row is still missing the no-action refinement.  Is it 
not needed?

In my version I have it. IMO it's required.

I put it back into mine as well.

Ashley, it works fine, thx.  Back on thursday....

IMO it's required
 ... agreed. Added to both table and text-list.

Graham - IIRc I sent you very brief doc, which shows some usage. 
Even with such doc, you are able to have xy times better grid than 
table is. But - I have to check with Cyphre and I already asked him 
for upgrade, as his grid worked with his RebGUI version, and I would 
like to use official beta 2 definitely ....

Build 74 uploaded to SVN. Includes the following additions:

1) New action object used as follows:

	box "" red
		on-click		[
			print "click"

   system/view/focal-face: face	; required to pick up scroll events
			system/view/caret: face/text	; required to pick up key events
		]
		on-alt-click	[print "alt-click"]
		on-dbl-click	[print "dbl-click"]
		on-scroll		[print scroll]
		on-key			[print ["key" event/key]]
		on-over			[print "over"]
		on-away			[print "away"]
	;	on-focus		[print "focus"]
	;	on-unfocus		[print "unfocus"]

2) New layout keywords added as follows:

	text "Test" text-color blue
	text "Test" bold
	text "Test" italic
	text "Test" underline


3) New 'examine function added to provide detailed information about 
a widget:

	>> examine table

Also a number of fixes:

1) Multi-row Shift hilight selection fixed (pekr)
2) Dialog has parent option by default (Frank)
3) Keystrokes on a button no longer passed along (Graham)
4) request-password enhanced to allow following:

		request-password/check [if (length? text) < 6 ["Problem"]]

5) /scroll option removed from display

6) /min-length & /max-length refinements removed from request-password

7) /no-action option added to select-row function of table & text-list


WARNING: These changes are wide-reaching and have not been fully 
tested ... some things may have been broken. Full documentation in 
preparation.

very nice, going to SVN now  to download new build ...

Ashley...you are da' man.

As RebGUI is aproaching 1.0 release, I would like to know your opinion 
on following - how do you construct and optimise your GUI? So far, 
if you look at tour.r, it reminds me of one big dialog configuration 
box. Not sure what to do about it, maybe it is a given, as widgets 
we have do suggest such layouting. This debate could open discussion 
about eventual addition of potentially missing widgets. My questions 
are:


- are you missing kind of MDI application scheme? Parent window, 
containing one or more child windows, which are not able to being 
moved away from its parent. We used that design much, but I am not 
sure anymore it is vital, as with latest system, we use two monitor 
set-up, and by simple accelerator key we can navigate window being 
moved between displays. Having MDI available, we would probably need 
rebol/view native windowing system. So - is anyone missing something 
like that?


- do you somehow optimise your display? Isn't it like following? 
- with using tabs, everything is in memory, whereas it eventually 
is not needed? How do you divide your application, if you would like 
to have kind of load-on-demand aproach?


What styles do we miss, to further help us have more complete GUIs? 
I created screenshot of potentially two usefull widgets:

http://www.xidys.com/widget-drop-tab.jpg
http://www.xidys.com/widget-vertical-tab.jpg


Especially with the second one, I think it could be usefull. It is 
used by many applications. It is kind of mixture of tab and tree, 
but not necessarily with multi-level aproach, just one level of nesting, 
mostly represented by icons, text, or icons plus text. I would like 
to know your opinion.

Pekr, whre can I download the new build?. No luck finding SVN
Bloodie beginner!

PeterD - ok, I can zip it and send it to your email - please give 
me your email address ...

Thanks, please send it to: [peter-:-danek-:-com]

I like the verical tab !

Pekr; If this is an open question, and not just to Ashley,


I use what I'm given.  In that I build apps (not many so far) using 
the toolkits I see in front of me.  I'll definitely retrofit my existing 
Fire and Rescue Management app with a Menu once the flurry of RebGUI 
development slows down a bit (and please don't slow down, love the 
flurry).


Unless my systems crash, I spend zero time optimizing, wait I take 
that back, I try and follow my own style guides while I'm writing. 
 There is the odd backtrack to get a tab panel to line up nicely 
inside another.  Other than fixing glaring visual ugliness, no optimizing.


I design with a 'small town business model'.  I hand deliver applications.


If I go and snag a feature that goes quirky during my initial testing, 
I dump the widget and look for another.  My 0.4.0 build of RebGUI 
had sticky persistent drop-list's so I used labels and a special 
requestor.  I'm not sure I'll retrofit these.


The easier things are out of the box for me, the happier.  Give me 
the tool, describe how it works and I'm satisfied (when it's as elegant 
as REBOL, RebGUI and RebDB).

well, vertical tab - beware - those are not rebgui examples, just 
external apps - for inspiration :-)

Understand, I like the "real estate handling" part of such a widget.
Is it http://trac.geekisp.com/rebgui/?

I'm using http://svn.geekisp.com/rebgui

Pekr, thanks 4 the zip

you're welcomed ....

Petr, well I use one main window, it has one PANE (box) which will 
have all data-form specific parts. This PANE is changed dynamically 
depending on the user choice. I hope to have an english demo available 
of my application that I can provide for download. IMO the concept 
is quite simple to use, and simple to progam.

Build 75 uploaded to SVN. Fixes some problems introduced in build#74 
and improves widget documentation. See here for a complete list: 
http://www.dobeash.com/RebGUI/widgets.htmland also the updated %tour.r 
Widget and Function Ref tabs.

now if area could scroll by hiliting by mouse, most "bugs" would 
be fixed for me :-) Well, not me, it was Bobik who reported it to 
me, as for me, being keyboard guy - I am ok with ctrl + A :-)

hmm, maybe drop-list and-edit list could work with keyboard (arrows, 
scroll wheel) too, but those are all imo minor features missing ...

Do you think that it would be possible for tour.r, to include e.g. 
one tab, showing how focusing works, including buttons? E.g. by default 
some element would have focus and you would be able to tab-focus 
between most ui elemetns?

Can I use multiple level sort on a table?
If yes how?

IIRC: No, only one column at the moment.

tour.r/functions/request-font, double click some of entries:

** Script Error: action has no refinement called on-dbl-click
** Where: wake-event
** Near: p/parent-face/action/on-dbl-click p/parent-face

dbl-click for table & text-list broken by build#74. On the list to 
fix.

Build 76 uploaded. Fixes above problem and includes further documentation 
improvements.

from where can I download ?

trac.geekisp.com/rebgui

that does really not help - to anyone :-)

... and I must laugh, as we still think, that most ppl are able to 
sort out, what to actually do. That is total mistake, however, and 
prevents many from even trying rebgui.

I even don't remember, how I managed Tortoise to work, at least in 
semi-automatic mode - choosing files manually, doing "save as" ....

isn't it possible to do some automated builds to .zip file? PeterD 
- I can sedn you new version from time to time ....

http://trac.geekisp.com/rebgui/browser/get-rebgui.r?format=raw

Download and run this script .. it downloads it all for you.

Or, spend 10 mins learning how to use SVN and join the rest of us.

that works for small group - other than that - it is not simply constructive 
aproach ...

I can't imagine sourceforge would not offer package downloads - that 
aproach simply sucks