AltME groups: search

It has a drop directory for playlist updating

Let me state - few weeks ago (actually two months), I started to 
write one document in make-doc format, but did not finish it. It 
was kind of brainstorming about current situation:

- simply put - what to do to promote Rebol?


I started with the fact, that e.g. OSNews.com reports every little 
bit of new version of xy-language related product, while my news 
item about View 1.3 did not get it to their news. New info is, that 
I contacted Tom Holwerda and he told me OSNews does not have any 
problem with Rebol news, and that it is upon us to submit the news. 
I thought that at least for main product releases as View 1.3.x we 
could do it. Of course it would REALLY help, if RT would be a bit 
more sharing about the schedule, because simply sometimes a bit of 
hype does not hurt, so we could attract ppl to new Rebcode, to hopefully 
coming rich-text, faster blitting etc., not to mention Rebservices 
as a separate article. But although rebservices were released, I 
sadly feel about it much worse than I feel about old Rugby! It just 
feels like RT would drop the ball to the community and nothing is 
happening in this field anymore. So actually, what is RT working 
on right now? There should be some communication channel, so that 
us - rebollers would be informed enough to participate in chats following 
the news articles. We have QA channel here, but most often news are 
- "we plan", "soon", and that is not simply acceptable to feel informed. 
So it is from devcon's time, that we "soon" will know, what is the 
plan for VID, not to menthion real implementation schedule - that 
does not work!

I'll third the second request, (which is now the "0"th) ... Don't 
loose any data!!!
and related subrequests ...

- don't drop me out of whatever I'm reading / writing, just because 
altme lost connection ... who cares? But I DO care, if suddenly the 
unread markings are lost

- If I start typing a message in one channel, then go to a second, 
clear the input field, and remember the message for the channel I 
started typing it, so that I can send it later, when I go back to 
that channel

- if I write a message, but don't have a connection, save it, and 
ask me whether I stil want to send, when the connection comes back 
(with a time threshold, send silently 5 minutes later, but not 5 
days) ( Yes, this is debatable, what if I realize, that I _wanted_ 
to send this to a different channel?

OK, it's time again for the twice weekly drive Reichart crazy competition 
to get your favourite bugs fixed ... ;-)

I'll just copy verbatim from one of my last entries ...


I'll third the second request, (which is now the "0"th) ... Don't 
loose any data!!!
and related subrequests ...

- don't drop me out of whatever I'm reading / writing, just because 
altme lost connection ... who cares? But I DO care, if suddenly the 
unread markings are lost

- If I start typing a message in one channel, then go to a second, 
clear the input field, and remember the message for the channel I 
started typing it, so that I can send it later, when I go back to 
that channel

- if I write a message, but don't have a connection, save it, and 
ask me whether I stil want to send, when the connection comes back 
(with a time threshold, send silently 5 minutes later, but not 5 
days) ( Yes, this is debatable, what if I realize, that I _wanted_ 
to send this to a different channel?

Not yet teamwork, but I _can_ be persistant ;-)

My understanding is a world name is kept as long as you use it within 
ten days of your last connection.  However, I have had world names 
that I didn't pay for drop on the same day a world was used.  For 
example, I change between three world names when I loose the one 
I am currently using.  A pain for the users of course, which I assume 
would not happen if I would just spend the small amount to reserve 
the world name.  Otherwise, I'm sure this would be a pretty big topic 
for SafeWorlds.

Tom, did you drop the word colour?

In my experience that meant that you now have to simply drop that 
word and create another world that will respond to the proper port. 
 meaning have your original world running when you register the new 
world.

Im was wondering, does Altme Linux/Debian need more specific testing 
to get out of Beta stage? If you need more Linux testing drop me 
a note.

Maybe, I can drop him a private question via RebDev and ask?

The grand plan of R3 seems years away, though. Since Carl now controls 
 the AltMe source code, I wish he would pick a trusted person from 
the community  to keep the R2 AltMe moving forward. I will probably 
have to drop AltMe as a customer service tool because of issues like 
this 6 meg limit that shouldn't even be an issue.

<sigh> got one while trying to post a message about drop outs... 
irony if there is any in altme.

Reichart, can you confirm that nothing is screwed up on the machine 
running this world, or its internet access... it is seriously breaking 
up.


earlier, I had a drop every 30 seconds, I tried to post a message 
7 times...  graham and I had to chat elsewhere cause it was getting 
just to insane.

I thought that TCP isn't allowed to drop packets, but it sure seems 
to do so. Perhaps REBOL simply is not detecting that error condition.

yes, I see the same thing. I recall there was a sudden drop a couple 
of years ago in general speed and it has been like that since.

I'm thinking of allowing the program to execute rebol sql dialect 
as is .. except I would prevent actions such as alter, drop, delete, 
insert .. ie. only allow selects.  Any danger in that?  I don't think 
it contravenes the license ...

yes well find and index where not what i searched for...ill drop 
an example...hold on a few hours ;-) back ltr...

Which is fastest/best?      

y
 <> ch-db/2/drop

or 

ch-db/2/drop <> "y"

with the constant first it does not have to decide/figure out the 
type of  'drop

To test performance of some code, you can use this function:

time: func [:f /local t] [
	t: now/time/precise
	do f
	now/time/precise - t
]

Example:
>> time [loop 100000 [ch-db/2/drop <> "y"]]
== 0:00:00.34105

Just my 1 cent contribution: there is a bug with the drop-down face 
when no action is set. The 'action facet defaults wrongly to 'show-dropdown, 
making the drop-down to freeze when the user does not override it. 
The fix is simply drop-down with [action: none]

Thanks Mike. Not sure if any of Franks stuff is avail anymore, the 
site that he hosts the scripts on seems to have disapeared. I also 
have my own drop-down style, but for this task the built in rotary 
was sufficient...just

put in a 'wait for a short amount of time and cpu usage may drop 
dramatically. it works well with responsiveness for scrolling large 
panes even if the frame rate drops a bit

I make a listview widget multicolumn multi resizing with drag&drop 
Viewed bar effet like in Win32API and multi widget type capable in 
only 3 weeks and using less than 300 That's the illustration that 
REbgui and VID base concept are pretty good  !!

right now there still are a ton of functionality improvements to 
come, and it'll be even faster than it is now. I want to implement 
dynamic column sizing, graphics in lists, drag'n'drop and proper 
handling of list actions

I think the upgrade utility should drop the acknowledgement "name 
of the file" part as it looks sloppy because I saved the file as 
"view2.exe" because the currently file couldn't be overwritten and 
it said I saved the file as "view.exe".  Just gives a bad impression 
of what else might be buggy.

I think RT could afford to drop support for Win95

IIRC Cyphre has in his drag-drop-demo a find-face-underneath which 
scans the all faces, not only the ones in the parent-pane.

drop the [word!] requirement from the argument and report true or 
false.

about proposals, currently we have only one atom operation to control 
advance in the serie: [skip].
We could had some other atom operations, like DROP,SWAP,ROT,DUP.
(any reference to FORTH language are intentional)

DROP, SWAP, ROT and DUP are stack modification operations, not parse 
advancement operations like SKIP. Don't forget REVERSE and matching 
operations - they advance too.

in an other way, SWAP, ROT, DUP or DROP are not just advance operations 
, they modify the serie too.

Just some ideas for possible usage.


[[item1 item2 | item2 item1 SWAP] ]   ; Put previous two matched 
items in order.
==> [item1 item2]  ; Always sorted.


[ROT [a b c d e]] ;  Rotate items matched by next subrule, if it 
matches. 
==> [b c d e a]  ; 


[start: a [b c] DUP start]  ; Duplicate items from start to current 
parse index.
==>  [a b c a b c]


[a DROP [b c]] ; If next subrule matches, then remove items matched, 
and set parse index back to the beginning of the remove.
==>  [a]

(DROP is just like REMOVE, so not really needed, I think. Just doing 
the exercise to see.)

The above can be categorized by how they fetch their arguments:
- Take two previously matched items/subrules (like SWAP).
- Match the next subrule (like ROT, DROP).
- Use a variable to take the parse index (like DUP).

being able to drop from foreach [foreach [foreach [....]]] in one 
call is sooo usefull soo often.

and I assume that drag and drop will not working using VmPlayer ? 
Thing I tried with an older version and did not work

How do you mean, drag and drop with VMPlayer? Integration with Syllable 
drag and drop, so you can drag and drop from the host system into 
Syllable and the other way around? No, such integration has not been 
done

re:drag and drop, yes that is what I meant, ie drag from a host partition 
to a "virtual" Syllable dir   guess the easiest way to get graphics/sounds 
to Syllable is via email or a web page.The reason for this is to 
test the graphics/sound apps in Syllable but since it comes with 
no sound/video files is the only way to test

We could drop the regular files, but Windows doesn't come with BitTorrent 
built-in, so I don't see how that would not limit the audience more 
severely than just using the most popular strong packer

The most annoying thing about the default configuration is that drag 
and drop works between some apps, but not others. Then it crashes 
the desktop. ROX will detect that and nicely restart, but you can't 
call it stable

by 51, I mean that the drop list does not display below the boundary 
of a group box

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

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.

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.

Depends. You can structure your code so that all the displays are 
in one file and all the business rules / data / action logic in another 
by coding like this:

display "Test" compose/only [
	button (app/labels/save) (app/actions/save)
	drop-list data (app/options/save)
]


and using references to face (and face/parent-face) within your actions. 
This approach achieves a couple of things:

	1) Separation of display from process

 2) code / data reuse (i.e. you can share data / action blocks across 
 multiple displays)

 3) Can reduce the amount of code that is composed as app data / logic 
 can be composed independently of the display
	4) Code is more portable (as face references are generic)
	5) Probably easier to maintain and debug

Problems with this approach are:


 1) "f: field" is easier to reference than "face/parent-face/pane/2" 
 etc
	2) You have to really think about how you structure your code
	3) It's very different from the way we are used to (VID)

Is there a way to re-use widgets like done with 'style in VID? For 
exampel: I have a drop-list specification, I need at several places 
but I don't want to copy the code. I tried it use a (my-drop-list) 
compose word but this doesn't work.

RebGUI goes Beta! With the fixing of some long running area / scroll 
/ slider bugs I've finally reached a stable enough release candidate 
for 0.4.0 Beta; so, from a REBOL/View console:

	do http://www.dobeash.com/get-rebgui.r
	do view-root/public/www.dobeash.com/RebGUI/tour.r


Also note that the demo directory includes a nifty new pie-chart 
widget demo (thanks Robert).


I've also separated the 0.3.x and 0.4.x issues into separate sections: 
http://www.dobeash.com/it/rebgui/issues.html#section-2.3

Changes in this release include:


 Scrolling fixed (all area scroll / slider problems should be fixed, 
 and a couple of minor field scrolling issues were also fixed)

 set-locale function to dynamically change locale files / dictionaries
	pie-chart widget added

 slider width reduced by 1/5 for area, table, text-list, drop-list, 
 edit-list (looks better)

 table column arrows made smaller and darkened, plus right-most arrow 
 moved to table boundary (more space for column heading text)


and an important one from 0.3.9 that I omitted to mention last release:


 drop-list / edit-list now size to the smaller of number of items 
 or available space in the bounding parent face (so no more lists 
 that disappear off the edge of a face / window)

Enjoy!

Robert: "Is there a way to re-use widgets like done with 'style in 
VID? For example: I have a drop-list specification, I need at several 
places but I don't want to copy the code."

Short answer, no.


If you have a "style" that is sufficiently different from the base 
widget (that is used often) then consider:

1) modify the widget's defaults in %rebgui-widgets.r, or
2) modify them inline, as in:

	ctx-rebgui/widgets/<widget>/<facet>: <value>

3) derive a new widget that works exactly the way you want.

margin/spacing: added to the list.


The drop-down widget panel is actually a standard interface element 
on Mac (forget the name of it) which looks surprisingly similar to 
the JPG Pekr posted. A worthwhile addition I think, although hard 
to implement (as it changes the offset of every widget below it and 
forces a window resize).

Because those issues are important to IT folks and totally irrelevant 
to most real world users? ;) Most users don't even know they *can* 
drive a GUI via the keyboard, and if they click on a drop-list they 
*will* pick an item, even it's a blank "no selection" choice (I always 
have the first item of my pick lists as an empty string so users 
can easily click their way out instead of having to press ESC).


  As an aside, what most of my customers were complaining about, until 
  recently fixed, was the fact that drop-lists didn't scale to fit 
  the most items possible ... something no-one here even noticed! ;)

well, drop list is not good example of how to use gui via keyboard, 
I do agree :-) our users are not typical users maybe, as they come 
from terminal SAP R2historically, where there was no mouse :-)

my complaint to drop-list is, that it is kind of menu ... and in 
rebol it is driven via show-popup? And that is broken .... I am used 
to close menu by clicking somewhere else .... it happens occassionally, 
when I unintentionally press right mouse button etc., and I really 
don't want any option to be selected ..... so I just move mouse out 
of the menu, and do a left mouse press ... not so with rebol ....

I put up some preliminary changes to the modal popup handling for 
RebGUI. By manually replacing the original files (but keep them in 
a safe place!) with


 http://www.diefettenjahresindvorbei.de/www/rebgui/rebgui-widgets.r

 http://www.diefettenjahresindvorbei.de/www/rebgui/rebgui-dialog.r


you should be able to try them. You'll notice a different and more 
common behaviour of drop- and edit-lists. For the existing styles 
as can be found in the tour script, I haven't experienced unexpected 
results so far. But I'm curious to hear if incompatibilities arise 
in more complex applications that need to be addressed.

Next one: What's the best way to create "user-selection-dependent-layouts"? 
For example the User select one entry in a drop-down box and depending 
on the value, a different layout should be shown below the drop-list.

Yes, it's in a tab-panel and depending on the selection of one drop-list 
the data-input form that follows the drop-list has to display different 
labes & fields.

How many entries has the drop-list ?  Because if it's small I might 
suggest using another tab-panel. Otherwise I would try to create 
the layout for each selection before the window is displayed.

Or, if most of the time the labels and fields are common, but with 
some differences, I might use the drop-list action to hide all and 
show only those fields which go with the current selection.

Thanks.


 "how's the splitting of widgets into separate files going?" Done, 
 it's all in SVN now: http://trac.geekisp.com/rebgui/browser


Anyone who wants dev access (both source and Wiki write access) just 
drop me a private message and I'll get you a username (same as REBOL3 
username) and password. A lot remains to be done before I open it 
up to full collaborative access, but having a few folks on it means 
we can test the infrastructure / process (in addition to getting 
some changes into RebGUI faster).

Changes like the above are good candidates to start with. ;)

I have the following problem: I need to provide a drop-list with 
two columns. And one of the columns has long texts in it, so that 
you can't read it if the drop-list isn't made extremly wide. Has 
anybody an idea how to best create the GUI for such a selection?

hummm drop down list is a nightmare of coding ... this is typically 
(in my opinion) one of the easyly doable in C/C++ but tricky to do 
with rebol. Tricky but why ?? Mainly because of the speed when you 
have to redreaw the main pane and the scrolling interface

But now I got a problem: I use some drop-lists that have much more 
entries than fit on the screen. When doing this I now get the following 
error, if I use any of my drop-lists:

** Script Error: Out of range or past end
** Where: action
** Near: result: pick data first picked

Here is a short example when it fails:
rebol []

;--- Startup
if system/product == 'Link [

 attempt [call reduce ["d:\rebol\view\rebol.exe" system/script/header/file] 
 quit]

 attempt [call reduce ["c:\programme\rebol\view\rebview.exe" system/script/header/file] 
 quit]

 attempt [call reduce ["c:\rebol\view\rebol.exe" system/script/header/file] 
 quit]
	quit
]

;-- use xpeers framework structure
link-root: first split-path system/script/path
link-root: copy/part link-root index? find link-root "/xpeers/"
append link-root %xpeers/
do link-root/framework/anamonitor300.r
do link-root/framework/slim.r

;-- RebGUI stuff

#include %rebgui.r unless value? 'ctx-rebgui [do link-root/framework/libraries/rebgui.r]

;-- SLIM stuff
slim/open 'debug none ; [mark-my-words]
; mark-my-words/init

unit-size: 4
font-size: 12
tab-size: 120x55

display/min-size "CalcIT" compose/deep [
	label "Land"
	drop-list 60 data ["A" "B"] return
] 1024x768
do-events
halt

We have a drop down in RebGUI that when we click off does not close, 
any hints?

I have made small fix so the drop-list behaves like Reichart wants 
under View 1.3.x. If anyone is  interested you can grab it here:
http://cyphre.mysteria.cz/stuff/rebgui-widgets.r

Works well, although it stll requires a click outside the popup for 
it to be dismissed (not merely moving the mouse pointer off the list 
as some have requested). Also note that this changes the behaviour 
of clicking from one drop-list to another (you have to click the 
new drop-list button twice ... once to dismiss the old list and now 
a second time to activate the new list). Note that the first hide-popup 
in the choose function (line 405) is no longer needed with this change.

I think requiring a click outside is good behaviour, but it is only 
good if that click is not consumed, but passed on (so that the second 
drop-list  activates straight away)..

Might be related to the discussion above:

If I have a 'field that uses an on-unfocus event and I enter some 
test and than click on a drop-down list, the on-unfocus event for 
the field isn't generated.

RebGUI 0.4.2 is up. Grab it the usual way with:

	do http://www.dobeash.com/get-rebgui.r


You may want to delete view-root/public/www.dobeash.com/RebGUI first 
as a number of old files are now redundant.

This build is the latest snapshot of the repository and includes:


 - %rebgui.r is now a single monolithic (72Kb single line) script 
 (individual source files are in SVN)
	- Cyphre's drop-list change
	- Anton's quit [not] when only one pane remains
	- clear-text and show-text fixes
	- led widget fix (failed when encap'ed)
	- language file for Italian added
	- %tour.r Opera icons replaced with Tango Desktop equivalents


Also note that the RebGUI home page has moved to http://www.dobeash.com/RebGUI/
and that all active issues / tickets can now be found (and updated) 
at http://trac.geekisp.com/rebgui/report/1

How about changing drop-list in that it opens the list even when 
the user clicks on the field and not only on the arrow?

Enhancement request posted to trac: there should be a setting to 
switch the drop down and edit lists to popup rather than drop down 
if there is no space below the widget.

I'm setting up a preferences screen for users to assign functions 
to the function keys .. no space at the bottom of the screen for 
the drop down lists :(

Ideally, and this is similiar to what you stated above, drop/edit 
lists that can't otherwise fit their contents by drop-down should 
then drop-up if the space above the widget is greater than the space 
below. This should be the default behaviour (i.e. display as many 
lines as possible, with a preference for 'below').

Just a note to all of you: I contracted Cyphre to develop some RebGUI 
widgets. In the next couple of weeks you will see two new widgets:
1. drop-tree: Is a mix of a drop-list with a tree view.
2. tree widget as we can derive this from the drop-tree

Having converted (or at least used as a starting base) a number of 
VID styles to RebGUI widgets I've observed that the final code is 
40%-60% smaller (YMMV) and easier to understand in that most of the 
logic resides in the widget itself (i.e. it is self-contained). But, 
once the code to be converted reaches a certain size where I can 
no longer 'grok' it in a single reading (about a hundred lines for 
me) I find it easier to code from scratch. ;)


I'd also break it into two separate widgets: grid and list-view, 
and look at the minimum function set each requires (KISS).


Simplest way to start is to read all the doco under 'RebGUI Documentation' 
at http://www.dobeash.com/RebGUI/then look at the source code of 
a few widgets (start with something simple like %button.r then move 
onto %table.r which shares a lot in common with list-view).


If you run into any brick walls (or find yourself asking, "why oh 
why did they do it that way?") just drop a note here. ;)

I just want to inform you what enhancements I needed and Cyphre did 
so far for RebGUI:


table: Add an API to table that allows to change the columns layout 
at runtime: my-table/set-columns ["Column 1" left 0.25 "Column2" 
center 0.75]


drop-list: fire action only if selection was made/changed, at the 
moment action fires if clicked on field too


general: on-un/focus should be fired if user clicks an other widget, 
not only if carets leaves the widget when TAB is pressed


table: moving bar up/down with keyboard should fire click-action, 
alternativ: pressing RETURN can fire click action

table: align header text like data (left, center, right) at the moment 
always left
table: TRAC #21


TRAC #5 Cyphre: should be fixed but please test it and let me know. 

TRAC #6

I'd also like to see the drop list drop down on clicking on the text 
and not just the down arrow.

Tree: The code for the tree is mostly complete. Even an API to change 
the tree at runtime exists. The code isn't splitted out into a standalone 
tree-widget yet. It's included in the drop-tree widget.

Question: If you create several data-forms that can loaded with different 
records, I always need a way to reset those fields/drop-lists etc. 
that are not loaded to default values or empty values.

Just to inform you, we are going to publish all our RebGUI changes 
today. Those will fixe and enhance quite a lot of things. Further 
a new widget "drop-tree" will be published as well.

ATTENTION: rebgui-edit.r was not yet merged. Latest revision doesn't 
include older changes. We will do this ASAP. But rebgui-edit.r is 
required in this version otherwise all other changes done by us might 
not work.



FIXED *rebgui/pad: Now only works for horizontal padding. Padding 
should happen depending on the layout direction left-to-right or 
top-to-down.
	Cyphre: now PAD works according to the AFTER settigns. Example:
	display "Test" [
		after 3
	    field
		pad 5
	    field
	    pad 5
	    field
	    pad 5
	    field
	    pad 5
	    field
	    pad 5
	    field
	]
	Robert,let me know if it works like you wanted.

FIXED *group-box: When setting a new title group-box/text: "new-title" 
the surounding frame needs to be adjusted to the new text-width.

FIXED *drop-tree: When selecting different quick-access buttons directly 
one after the other, the drop-tree shouldn't close

FIXED *drop-tree: Highlighting the pressed quick-access button with 
green, the hovered one as is in orange. To give user visial feedback.

FIXED *general: a way to sepcify "align ['left]" for all further 
widgets to avoide repeation. Idea: Add disaply keywords: left, right, 
center
	Cyphre: added keyword TEXT-ALIGN left/right/center. Example:
	display "Test" [
		text-align right
		after 3
	    t: text 20 "test 1"
	    field "test 2"
	    field "test 3"
	    text-align left
	    field "test 4"
	    field "test 5"
	    field "test 6"
	]

FIXED *drop-list: an option that will show the list layered above 
everything (like the tree list of drop-tree).
	Cyphre: added drop-list/popup-mode: 'inside(default) or 'outside
	note: the same works for drop-tree

FIXED *drop-tree: changing state of the drop-tree (a new entry was 
selected) should only be done if the ACTION code returns TRUE. Otherwise 
the old state is kept, the drop-tree is closed and nothing happens. 
This allows the code to check for some pre-conditions before changing 
the state, and give some feedback to the user. Much like the on-unfocus 
functionality of RebGUI.

FIXED *drop-tree: pressing the quick-access numbers doesn't work 
any more as the drop-tree closes now if the mouse is clicked outside 
the drop-tree

FIXED *table: table/selected returns NONE if the table is empty and 
no record is selected. If there was one recrod selected at any time, 
than table/selected returns [none none <repeated for number of columns>]. 
If not row is selected at any time, table/selected should just return 
NONE.

FIXED *table: If a table is re-used in that the table is reused with 
code like:
	insert clear table/data [...]
	people/redraw

and there was a row selected before, than the internal state is still 
in "row selected" but the new row isn't highlighted. Here internal 
state and GUI don't match.

FIXED *drop-tree: clicking a "+/-" in the tree only open/closes the 
tree without calling the action for the node

FIXED *drop-tree: Re-add whole line selection and hovering functionality 
(so that mouse does not have to be over text)

FIXED *drop-tree: Add an option to get big fast-selction keys aligned 
left-to-right
	Cyphre: added drop-tree/expander-mode: 'big(default) or 'small

FIXED *button: Add an option to disable a button my-button/active: 
true/false, if disabled the button is drawn greyed-out
	Cyphre: usage is my-button/active: true/false show my-button

FIXED *field: Support number datatypes for TEXT so that things like 
field-a/text + field-b/text can be used

 Cyphre: you need to set field/edit-mode: 'numbers to activate this 
 behaviour for field(othervise it works like a normal field)
	2nd implementation uses own styel: number-field

FIXED *radio-group: Add an API that allows to provide a new DATA 
specification block at runtime or a way to alter the text of the 
radio fields at runtime.

 Cyphre: now you can just change the data content and do show on the 
 radio-group like:
		my-radio-group/data: ["item1" "item2" "item3" "item4"]
		show my-radio-group

 Note that it won't react on change of number of items. Just change 
 of texts.

FIXED *radio-group: Add a way to select one radio field at run-time
	added accesor select-item item [integer!] usage:
		my-radio-group/select-item 2
		show my-radio-group

 note: you can get the selected item using my-radio-group/picked, 
 you can get the text of selected item using my-radio-group/selected

FIXED *drop-tree/grey-out: Can it be done in that we only show the 
text in a light grey instead of black? Like Windows does it.
	Cyphre: now the masked text is light grey

FIXED *on-focus / on-unfocus: If FALSE is return from the ACTION 
and the user clicked somewhere on the screen, the focus is still 
in the "field" but no cursor bar is visible

FIXED *drop-list: IIRC in your widgets it was possible to start typing 
and the selection list was filtered. A mandatory feature for the 
drop-list :-))

 Cyphre: added drop-list/editable? flag to enable/disable editing 
 of the drop-list field

 also added drop-list/auto-fill? flag which enables automatic text 
 filterin from the selection list

FIXED *general: add hover tooltip help option to every widget (global 
patch)

 Cyphre: added TOOL-TIP facet to rebface object. If TOOL-TIP is set 
 to string! value a tooltip is shown when mouseover such widget.
	example:
		display "test" [
			button "press me" tool-tip "press this button to continue"
		]

FIXED*drop-list: proivde a much better selection-list opening algorithm 
especially for long lists. Open upward, downward, middle like so 
that as much entries are shown for the given screen space. And an 
option that will show the list layered above everything (like the 
tree list of drop-tree).
	Cyphre:

 -added droplist/lines - can be 'auto (default) or integer! to force 
 number of shown lines in droplist

 -added droplist/droplist-mode - can be 'auto (default) 'upward, 'downward 
 or 'middle to force way how the list is popped up
	you can use various combination of those settings.
FIXED*table: Add an API that allows to select a row at run-time.
	Cyphre: Usage is for example:
		my-table/select-row 5
		show my-table

FIXED*table: Add an API to table that allows to change the columns 
layout at runtime: my-table/reset ["Column 1" left 0.25 "Column2" 
center 0.75]

 Cyphre: I added the functionality byt the API call is my-table/set-columns 
 ["Column 1" left 0.25 "Column2" center 0.75]

FIXED*drop-list: fire action only if selection was made/changed, 
at the moment action fires if clicked on field too

FIXED*general: on-un/focus should be fired if user clicks an other 
widget, not only if carets leaves the widget when TAB is pressed

FIXED*table: moving bar up/down with keyboard should fire click-action, 
alternativ: pressing RETURN can fire click action

FIXED*table: align header text like data (left, center, right) at 
the moment always left
FIXED*table: TRAC #21

FiXED*TRAC #5 Cyphre: should be fixed but please test it and let 
me know.
FIXED*TRAC #6

It's mostly done (90%) as there is a complete tree in the drop-tree 
widget. We just didn't extract the code into a stand-alone widget 
as I don't need it at the moment. Feel free to go for it.

when i run create-distribution.r, i get
...
widgets/drop-tree.r
** Script Error: Cannot use add on none! value
** Near: bytes: bytes + size? f

create-distribution.r - workaround at the moment is to create two 
empty 'place-holder' scripts in widgets dir named %number-field.r 
and %drop-tree.r. This should resolve itself once Cyphre publishes 
his remaining changes ... otherwise I'll add them to SVN the next 
time I commit any [other real] changes.

Also committed rev#26 with support for Ctrl-Enter hard tabs, and 
removed references to drop-tree/number-field so create-distribution 
works correctly.

why drop-list does not exceed the border of owning app window?

Pekr, the drop-list would have to be a window itself to do that.

Anton - are you sure? :-) I just looked lately at the source, and 
there seems to be one param -inbound, or outbound, for drop-list 
.... inbound is set by default. Separate window - why? We have show-popup 
...

So you're just saying you'd like the drop-list to also use borderless 
windows in its implementation.

This is a problem with drop lists. I thought though that this was 
one problem Cyphre was tackling

hmm, you are probably right, Anton ... just downloaded drop-list.r, 
changed 'inline to 'outline, but nothing changed, it can't go outside 
the parent window ... (which is maybe logical, as everything lives 
in screen-face/app-window/pane .... unless show-popup does not allow 
for other modes ...

Pekr, what is so difficult about browsing the source. The particular 
code you are interested in is at  http://trac.geekisp.com/rebgui/browser/widgets/drop-list.r

Anton - today I consulted with Cyphre, and it is really how I thought 
about it - drop-list, and its inside/outside argument really allows 
you to have the drop-list to go beyond the border of parent app. 
The case is, that there is simply a bug, which Cyphre nearly fixed 
(hilite stopped working)

So I would drop the /WITH refinement and make it implicit in a DELIMIT 
or CONJOIN function... (maybe..)

1) rejoin/quoted [...]   ; <-- this is most similar to rejoin, or 
delimit without the /WITH

2) conjoin/quoted "," [...]    ; <-- this is like delimit/with/quoted 
 (and the non-optional "with" argument is specified first)

Anton, I'd drop the word "adjoin" because it means basically the 
same thing as "join".

hmm,,    
   repeat i dec length? string
   repeat i  (length? string) - 1
i drop that. makes sense.

if you drop the position marker, will it be simpler or harder to 
build formatted tables?

Do you use the RIGHT and CENTER options in the dialect in your code 
today? Would you have to change alot, if I drop the size in the dialect?

That's for the example, you can drop it. It's not needed anymore, 
the timings are now (from 0.9.19) automatically inserted by the RSP 
engine in debug mode (when DEBUG keyword is found in the webapp config 
block).

thanks... wrt CRON... when you release the next version, I could 
drop that into it and send it back to you.  you don`t have to do 
everything yourself   :-D

so just drop off the end?

I've tried to write that line SEVEN times before altme finally didn't 
eat it up or drop connection.

I am trying to make mod-remark as consistent and integrated as possible 
with the rest of cheyenne.  the end goal being that you remove the 
rsp from your modules and drop-in remark instead.