AltME groups: search

I remenber reading somewhere (maybe ML) that an edge is a face pretty 
like other face.
I seems to be true:

view/options lay: layout [
	box "Bouncing window !!" 300x200 rate 1 feel [
		engage: func [f a e] [
			if a = 'time [lay/changes: 'restore show lay]
		]
	]
	text "Minimize me (if you can ;-)"
] 'resize

a 'progress version without sub-face:

1) Terminology: I'm starting to gravitate towards Window, Face, Attribute, 
Widget and Feel.

2) Widgets: will have simple VID-like names; e.g. button, icon, image, 
bar, progress, etc ... I'm compiling a list of the required base 
widgets and will publish here for discussion when done

3) Facets document: updated 'restore, 'activate and 'edge/image descriptions

4) Vincent's 'progress widget ... exactly what I was after; added 
it to next build

Did I miss anything? ;)

just a detail: in facets document, /span datatype is pair! . you 
could use it to store other data, but if you set a pair! to /span, 
/view will use it as virtual size for face (it still works in later 
betas, so one should be careful to not use it to store coordinates) 
ie:
f: layout [
   banner "Testing /span" guide 
   box 400x400 effect [gradient 1x1 0.0.0 255.255.255] 
   button "Hello!" return 
   text-list data ["just" "a" "list"] 
   image logo.gif logo.gif/size * 2
]

f/span: f/size  ; here we tells /view to use virtual coordinates 
for all subfaces

view/options f 'resize ; will give a fully resizable window (widgets 
included), but it only works for reducing window's size.

with it, a program designed for a 1024x768 display can work on a 
640x400, or even a 320x200 screen :-) there's a known bug in /view 
betas with alpha channel, the transparency use real coordinates, 
not virtuals.

Good diagnosis. I knew assigning a pair! to span did *something*, 
I could never quantify exactly what though. As Ammon said, an interesting 
effect but somewhat useless in an age where screen ratios are all 
over the place and resizing needs to occur both vertically and horizontally.

First stab at a list of required base widgets

	area
	bar
	box
	button
	check
	droplist - text display + drop-down list
	editlist - edit box + drop-down list
	field
	groupbox - encloses a group of gadgets in a titled border
	icon
	image
	list – single column
	listview – multi-column
	progress
	radio
	scrollbar

 spliter – a “spliter window” which affects the width / height and 
 position of other gadgets
	tab -  arranges multiple gadgets into logical groups
	text
	slider
	treeview

 updown – scrollbar minus the bar (used with a field to increment 
 / decrement numbers, etc)
	menu
	popup-menu - context menu
	status – status bar with one or more “segments”
	toolbar


The aim is to have as few widgets as neccessary to build the majority 
of required GUI's. Take a look at the applications you use on a day 
to day basis, what widgets do they use? Are they in the list above? 
How are they named? Are there any widgets in the above list we can 
do without? (not that *someone* won't need it, just that it isn't 
common enough to be part of the base widget set).

As long as there is a glossary that let's you translate from familiar 
terms, I think you're OK using REBOL's native terms, though they 
were foreign to me when I started.

Window or dialog?

 Or Screen or Form or Layout. A Dialog is usually something other 
 than the main screen in an app. You sometimes need to use all those 
 terms if you're speaking in the domain of an application, so use 
 wha'ts appropriate in each context. 

Face or graphical object?

 Or Control or Widget. Tough call on this one. I was used to Control 
 from VB, and Face confused me as it could be a layout as well. I 
 like distringuishing between layouts and controls. Hmmm Maybe a hierarchical 
 tree.

Facet, attribute, property or descriptor?

 I like either Attribute or Property. I can live with Facet in REBOL, 
 it's shorter, and it makes sennse if you think in terms like "let's 
 discuss this facet of the business". 

Style, widget or template?
	Style, definitely.

Styles (and Stylize) are also a user-friendly way to get massive 
code-reuse, as well as being the widgets... maybe widget-styles (I 
have seen people say VID-styles before) or something like that could 
describe subsets of styles in use...VID is a package of styles...(just 
some outloud thoughts)

bug: the last widget in a rebgui layout determine the width of the 
face - if the last widget is narrow, the window is narrow.

fix: in %display.r, you have to keep track of the maximum x value:

- near "xy: origin-size" you can initialize a 'max-width: "max-width: 
origin-size/x"

- in parse loop, just after xy update "xy/x: xy/x + last-face/size/x", 
you can update the 'max-width: "max-width: max max-width xy/x"

- after (outside) the parse, near where the y size is last updated 
"xy/y: xy/y + last-face/size/y", you can set the x size to be the 
'max-width: "xy/x: max-width"

for widgets, I would add a basic 'anim - it's just too easy to implement 
to miss it (ie. a looping anim widget) :

editlsit = droplist with a read-only mode in the field IMO

a 'check with 'text in one face :

usage: 
check [
    text "a label"
    size 100x15
    data true
]

another bug (or more likely unfinished part): the last widget in 
a row determines the height of the row

Latest release, incorporating all the above changes, available at: 
http://www.dobeash.com/files/RebGUI-012.zip

Documentation also significantly expanded to include:

	- Latest REBOL/View facet observations
	- Glossary of terms
	- Licencing section
	- RebGUI Display User's Guide
	- RebGUI Widget Designer's Guide

Get it here: http://www.dobeash.com/it/rebgui/


My intention with RebGUI is to foster a community project that can 
deliver a credible alternative to VID, with my role being one of 
project leader / sponsor. The licence stuff is just to clarify my 
legal position and the rights of contributors and users. I'm looking 
at how to enable co-operative development (using IOS) but this can 
wait until the base design has stabilized. It's just too easy to 
fork efforts at this stage. All of this is still Alpha so if there 
is anything you disagree with (technical, documentation or legal) 
then please raise it here and I'll do my best to accommodate your 
concerns.


I want this whole process to be as open as possible, but without 
the pitfalls of "design by committee" where nothing gets done! ;)

Hum after some tests that eratic memory consumtion apears to be related 
with the anim widget ... I put  it in  comment  then I have a stable 
mémory allocation.

same for anim adding to the feel a recycle call after the show face 
will stabilize the memory usage

mmh, after disabling nearly all widgets, it seems that the events 
who eats memory:

even without 'progress, memory is consumed by 4-8ko steps. (just 
going over 'button eats memory)
for 'anim its more visible ('time events),

recycle in 'progress mean recycle at each 'show, so a recycle at 
window level could do the same.

but for anim, it's a simple assign

face/image is just a pointer to an image in face/data

so there is a direct like I think

the image isn't evaluated in "face/data: either tail? ..." it's just 
a pointer affectation

I'm keen to see your findings / conclusion on this one. Nailing "memory 
leaks" early in the design is a high priority.


If the "problem" is with 'show then we can always do something simple 
like:

	show*: :show
	show: func [face [object! block!]][show* face recycle]

Not sure about the performance hit though ...

Anyone know where I can get a good free set of XP (or XP-like) toolbar 
icons (22x22) that I can distribute without issue? (I'll acknowledge 
the author(s) in the source and documentation).

I don't see any mention of user-data . This was standard value for 
a user to store / manipulated data in a VID face, without fear of 
the style over writing it (unlike face/data which belongs to the 
style).

RebGUI uses the standard View face (25 facets) and 'data is not used 
by REBOL/View. VID extends this face by an additional 22 facets:

	state
	style
	alt-action
	facets
	related
	words
	colors
	texts
	images
	file
	var
	keycode
	reset
	styles
	init
	multi
	blinker
	pane-size
	dirty?
	help
	user-data
	flags


and provides 'user-data as it uses the 'data facet itself. RebGUI 
widgets use 'data as the "interface" attribute (e.g. setting a progress 
bar's value) and may define additional facets for internal use on 
a widget by widget basis. The idea is to make best use of the 25 
available View facets and not have every widget using 47 facets regardless 
of whether it needs to or not! ;)

one ask I allways maid to me was how to done a box with sunken like 
borders with rebol/view ?

A suggestion .. don't quit after closing an example window please 
.. halt will do just fine.  Otherwise have to reload rebol each time 
:(

I agree with Graham. I have .R files associated with my editor. Perhaps 
you could pass in a flag to intelligently quit or not ?

Windows keeps track of all the programs used to open a particular 
file extension. Just right click the script then choose:

	Open With | Choose Program


and browse select the file you want to open it with (checking the 
"Always use ..." option if you want to permanently associate it). 
Thereafter, this file is displayed whenever you right-click and bring 
up the "Open with" menu. On my system I have multiple REBOL versions 
and editors available so I can easily choose how I want to open a 
script.


Anton: if your .R scripts are associated with your editor, how do 
you run them? Console session and do?

I have my .r associated with editor as well.  I run a console session 
to run rebol scripts.

I'm either in a rebol console or a dos shell :(

I have a tendancy to fall in front of a video game or two but other 
than that I'm usually behind a rebol console as well. ;-)

I tend to create batch files if I need to run a rebol script .. or, 
encap them.

I suppose, Graham, you're tracert'ing a lot.

In http://www.dobeash.com/it/rebgui/widgets.html, 

in Feel function templates, there's missing the 'move event in engage.
It's used for dragging actions in a layout.
Here a vertical splitter widget using it :

thanks :-)

suggestion: the 'rate attribute/facet could be specified in a display 
- for 'anim and futur widgets. In 'display code:

not based on VID - it's a remplacement

the main web page is
http://www.dobeash.com/it/rebgui/

there's more information there on Ashley's project - a nice doc on 
/View engine growing with RebGUI progression.

Nah, RebGUI is simply a minimilistic, holistic approach where you 
don't any thing more then is needed and what you add is self sufficient. 
(at least that's my take on it...)

GL goes for a more dynamic approach while maintaining performance. 
 Did you see Maxim's rework of a multi-column scroll list?  Fast, 
very fast.

pekr sure this will come in time but in a 0.1.3 version I don't think 
this is actually the priority ...

a little correction to 'progress (didn't count the 'edge size and 
0x0 origin in draw):

a one-face horizontal slider prototype :

for 'hslider

- 'init is used to allow 'action in definition, as with 'action feel/engage 
is modified
- must be tuned and modified according to futur specifications

- usage example, in %example-misc.r, you can test it adding "hslider 
[size 200x20 data 0.75 action [p/data: face/data show p]]"
- for a 'vslider, same code with all x and y swapped

Pekr: visual focus like which OS? It isn't the same on Windows 95->2k 
and Windows XP, and there are other OS. Mouse reactions changes a 
lot between OS too.

a little set of existing controls makes it easier to discuss common 
behaviour. but it's important to discuss it as soon as we can.

more complex widgets shouldn't be done until we have a more detailled 
specification about global look and feel (colors, text size, ...)

Pekr that's right but I think that"s a second stage of consern first 
we have to make those common widget we have to make them speedy then 
we culd let spent some cpu calc to look & feel  purpose ;)

OK, I read it is a community project - what is the concrete plan, 
if any?

For VID 1.3, the spec was to be close to XP while maintaining open-endedness 
for custom and legacy projects (Surfnet Detective is imo an XP-alike 
that 1.3 may have ended up as).  As RebGUI is more focussed (and 
streamlined) than VID, I would recommend working toward a neutral 
style optimised for the kind of UIs that RebGUI is designed for.

Pekr: "What is the concrete plan, if any?" ... shadwolf was on the 
mark.

1) Create a set of base widgets with the desired *functionality*
2) Select a look & feel to approximate
3) Apply this look & feel *consistently* to all base widgets


Vincent is correct when he says we should discuss this sooner than 
later as look & feel can effect how a particular widget is implemented. 
As an example, a 'button widget trying to mimic WinXP might use multiple 
images and / or effects to mimic the various states a WinXP button 
can be in; while a minimalistic approach might just make use of 'edge 
and 'effect to toggle between several states.


I'm leaning towards a minimalistic yet modern look & feel (perhaps 
even PDA-like) so put any useful links / comments / opinions / designs 
here for folks to look at. Here's one to get the ball rolling: http://projects.o-hand.com/matchbox/screenshots.html

Pekr and every one have to understand that starting a sutch project 
from scratch (white page) is a true challenge.In french scene we 
have an example of a heavy skinnable widgets library that became 
deprecated because several reason in witch there is no one to take 
in charge the continuity of the lib and that's pretty difficult to 
make a relevent work while we don't know what could be the VID futures. 
This library is interdependent of VID so while we don't know how 
Carl plan to extend it in futur it's hard to make up plans to maintain 
it.  The name of this lib is libskins v3 witch was made by Etienne 
Alaurent.. What I want for RebGUI  is that every one can participate 
on it apporting  he's hown ideas to it but conserving the main project 
lines. I think Ashley is totally in this mood and try yet to make 
documentation around RebGUI concepts. In futur one posible idea to 
simplify the documentation elaboration could be to use the rebol 
french scene douwiki.Every people that creates a modification significant 
to RebGUI would write the related documentation directly to the dokuwiki 
this way the documentation task that had to make Ashley would be 
lighter. Ithink as Ashley have the "code vision" he must take in 
charge the code merging and releasing (that's yet what he do actually 
;) ). If we want RebGUI to be maintained and constently adapted we 
must  work as a team. This allow us to have more knowlege and more 
inovent ideas in the topic ;)

Latest release available at: http://www.dobeash.com/files/RebGUI-014.zip

Highlights include:

	- Several new widgets (15 in total now)
	- A simple WinXP-like look (not final, just something to model)
	- New %tour.r script to view all widgets in action
	- ESC to return to the console (for Graham)
	- Numerous minor improvements and fixes
	- Documentation update (the Display User's Guide in particular)

It's not a biggie.. but like Anton, some of us use the console preferentially.

When you resize the tabbed view to a smaller size, I notice that 
the window obscures tabs to the right.  Can you put an arrow widget 
to scroll the tabs across ?

Ashley I have a good idea to submit you conserning widget positionning 
http://rebol.dev.fr/view.php?sid=72

instead of using offset to set the position of a widget we use north 
south east west container ;)

you can start be texting the contribution code I submit you then 
try to find a relevent way to adapt it to rebgui  ;)

in a 'tab-panel, auto-resizing don't work

it's managed at window level, so faces in a face/pane aren't affected 
by resizing. it will be a problem with all container widgets. the 
resizing should be modified to recurse into pane faces and blocks.

Latest release available at: http://www.dobeash.com/files/RebGUI-015.zip

Highlights include:

	- New LED widget
	- Tweaked check, splitter and tab-panel widgets
	- Basic edit feel added to area and field widgets
	- Resizing is now fully recursive
	- Added a light-weight request-file function for Win32/SDK use
	- Numerous minor improvements and fixes
	- Documentation update (the Display User's Guide in particular)

A little correction to 'slider - 'slider position was set  with an 
edge in mind, so I subtracted edge/size to it. Without edge, the 
correct formulas are:

for y-slider, delta: 5 + to integer! face/size/y - 10 * min 1 max 
0 face/data

for x-slider, delta: 5 + to integer! face/size/x - 10 * min 1 max 
0 face/data
it will remove the visible gaps in Sliders demo

I find hover effects quite distracting, and not really useful - as 
if users didn't know that the boxed thing labelled "push me" was 
a button. But since it becomed the rule on some OS, here a simple 
one for 'check :

there's a compatibilty problem with 'check and 'led : #[none] #[true] 
#[false] don't works in /View 1.2.1 . it can be fixed by using reduce 
[true [...] false [...] none [...]]. (I think backward compatibility 
should be mandatory only for core functions/widgets, for additional 
optional elements like 'request-file function and /min-size option, 
a short note in documentation is enough)

tested 'request-file - spotted a bug:

when one uses a filename without a path in it, it causes an error.

ie: %my-file.r, split-path gives [%./ %my-file.r], the path isn't 
cleaned, local-request-file don't like "./" -> error
an easy fix is to uses 'clean-path before 'split-path: 
if file [
    set [path file] split-path clean-path path
]

that said, 'request-file works well (tested all /options,) and is 
a lot cleaner and smaller that the VID version :-)

Actually I'm doing research work on ricth tex editor with redered 
input ... It"s quite unachieved but I think that's a good work way. 
Instead of having input separated with preview I hope can find a 
good system to have both in same window

Asley I know that it. But that's not beacause RT is working on it 
too that we can't work on it right now with yet existent technologies 
and try to figure out how to do it with the limited capabilities 
(bacause we don't have aaccess to entire VM source code) we have. 
In futur once we yet trully have a working solution and VM will have 
officiallly the new technology AGG we could help Carl on TDM  by 
apporting our RTE/IR (ritch text editor input renderer) code to him. 
it's a base of search for us but it means to be one implicitly for 
Carl If we want to save his time and focus it on the important things 
we have maybe to take in charge some od research work  ;)

Latest release available at: http://www.dobeash.com/files/RebGUI-016.zip

Highlights include:

	- New bar, group-box and toolbar widgets
	- Removed icon and text+ widgets
	- Added accessor functions
	- Added pad keyword
	- text and size attribute handling improved
	- Numerous minor improvements and fixes
	- Documentation update
	- Added a simple install example

Less than a dozen widgets to go!

	droplist	edit box / text display + drop-down list
	list		single column
	listview	multi-column
	radio
	treeview

 updown	scrollbar minus the bar (used with a field to increment / 
 decrement numbers, etc)
	menu
	popup-menu	context menu
	status		status bar with one or more “segments”


If you're working on any of these, drop a message here so we don't 
double up on efforts. ;)

The styles that I have up on REBOL.org are built with on a similar 
concept to RebGUI if and you want, we can just minimize the facets 
and plug them into RebGUI...

On radio - started some work on it.

I would like more info on needed 'list, behaviour and features wise.

I have a working text-list widget, with full mouse control (shift/ctrl 
selection), but it's too big imho (100+ lines.)

list (single or multi column): I once have hired Cyphre to create 
a style for me. Very useful and powerful. If someone is interested 
I can provide the code as a starting point (or at least as idea pool). 
You can find some documentation for it on my homepage under project 
data-form dialect.

I think list must be  multi colum is good, so multi colum must have 
a title (enable/disable), row design (enable/disable), sorted capability 
when clicking . Row is capable to display text, images, progressbar, 
checkbox, button all kind of widgets. Maybe as base we must have 
a dialect to format heavyly the content

If you have a question feel free to ask.  I get feature requests 
but most of the features that get requested are already there.  Take 
a peek at the code, if it isn't self explanatory, I'm glad to explain.

I'll add the popup code to the Display function as a refinement...

display/popup

Interesting... Somehow I have a newer version number on the depreciated 
script...  I'll fix that...

You're "Installer" example script looks a lot like my Wizard.r style. 
 My Wizard style works alot like a tabpanel but includes a simple 
way to validate information before or after a particular pane is 
loaded and it automatically positions the navigation buttons, etc...

Ashley, on this page: http://www.dobeash.com/it/rebgui/display.html
 What does this mean? "Unless otherwise specified, text size reverts 
to 200x9999 if the string contains a newline."

Vincent: 'list behavior & features - less is more at this stage, 
once we have something to look at we can refine it.


shadwolf: 'text+ removal. While a useful widget for certain domains 
(like WYSIWYG editors / browsers) it's not a basic building block 
widget. There were also some unresolved implementation issues with 
it at this stage - I'll add it back in at a later date as an optional 
or advanced widget.


shadwolf: multi-column list. An implementation model I liked was 
that adopted by Gui4Cli ( http://users.hol.gr/~dck/g4c/) which allows 
simple "table" representations (including column type and alignment 
definitions). Can't say I've come across that many UI's that use 
anything other than text / numbers in a standard list (thumbnails 
and scrolling check-box options are usually implemented in an app 
specific manner).


Ammon: 'display/popup. If it's sufficiently different from 'display/layout 
then I'm all for it.


Ammon: Wizard style. A wizard widget, if simple enough, would be 
a good addition. Like 'group-box and 'tab-panel it is a meta-widget 
that groups / uses other widgets. I'll make this distinction clearer 
in the next version of the docs. On a side note, my install example 
has convinced me of the need for an 'indent option (and the fact 
that use of 'offset should reset the line-height calculation).


Ammon: "Unless otherwise specified, text size reverts to 200x9999 
if the string contains a newline." I probably need to rephrase this, 
but what I was trying to say was that by default 'text is 9999x20 
which let's you write a string without having to know it's width 
in advance (9999 will auto-size it), *but* if the string contains 
a newline then it is the height that is the more important variable 
so it'll use 200x9999 instead. Of course it'll only do this if you 
don't provide an explicit size yourself (the "unless otherwise specified" 
bit). Hope that makes a bit more sense.

Display/Popup is significantly different from /Layout.  /Display 
appends the face that is generated to System/View/Screen-face.  This 
makes it so that a popup can extend beyond the window of your application.

If the global event system is the best way of handling this, then 
we can always reinstate it (a pity though as nothing else has needed 
it yet).

Sounds like you have protect-system on (usually a good idea)
and rebgui wants to reuse a system word (usually a bad idea).

Try
unprotect 'show
to give rebgui permission to overwrite

I used the key bindings from OpenOffice where Ctrl+BackSpace and 
Ctrl+Del are delete word left and right respectively. EmEditor uses 
Ctrl-D to delete to end of line ... don't know if there is a "standard" 
for these types of operations; but as you surmised it's pretty easy 
to change at this stage.

ctrl-y does, in MEMACS: paste, in ConTEXT: delete current line, etc.

we should only keep basic ones, like copy-paste (ctrl-x,ctrl-c,ctrl-v), 
selection (ctrl-a, (ctrl)-shift-left/right), and undo/redo (ctrl-z,ctrl-Z?).

it's better that having users deleting all text with a bad keypress.

A policy of "least harm" applies with regard to key combos of different 
editors which contradict each other in a destructive way.

RebGUI 0.1.6 (b) version that includes cyphre's ctx-menu is done 
;) Well it was added as it and as I'm less an artist than Ashley 
I let it functionnal as it was mainly designed by cyphre. I add a 
little trick and some code to it to make it more resemblant to a 
common menu and add the possibility to draw text starting from left... 
I hope Ashley or others could take some amount of their precious 
time to see it and enhance this very first implementation to make 
it even more in the mood of RebGUI

yes it's a very cool widget library ;)

Ashley, can we get a password field ?

the span field is enought  but I need to redraw the ctx-menu when 
a resize is done

The menu widget is over 500 lines and a bit of a global name-space 
polluter. My first-cut clean of it is here: http://www.dobeash.com/files/menu.r


You'll notice that "lefted" items and shadow-drop images have already 
been cut ... but a lot more has to come out.

Ashley I notice it it was done pretty quickly as a try Like a can 
I do this algorithma ;)

I'm missing a new_folder.png

ctx-menu was in a early stage  :)

with my version it's not draw like this so 2 alternatives : or Ashley 
deleted some of the compositing code (don't think so ) or the images 
are to big and to avoid this to append again we need to add a static 
image menu resampling in order to get them fit the relevent value 
;)

when I see it was relatively close in code motion to rebgui I started 
to wanted hardly to port it and better it a little (the famous lefted 
option ... to quick developed to convince every one  ;)

Anyone had any experience with SQLite (http://www.sqlite.org/), especially 
in conjunction with REBOL? What are the limitations of sqlite3-protocol.r 
(http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=sqlite3-protocol.r), 
if any?

I'm interested to see how folks have dealt with issues such as:


 1) Support for datatypes other than TEXT, INTEGER, NUMBER and BLOB?

 2) All tables in one DB, or one table per DB to improve concurrency?

 3) Multi-user access across a network, given this statement from 
 the SQLite website:


SQLite uses reader/writer locks to control access to the database. 
(Under Win95/98/ME which lacks support for reader/writer locks, a 
probabilistic simulation is used instead.) But use caution: this 
locking mechanism might not work correctly if the database file is 
kept on an NFS filesystem. This is because fcntl() file locking is 
broken on many NFS implementations. You should avoid putting SQLite 
database files on NFS if multiple processes might try to access the 
file at the same time. On Windows, Microsoft's documentation says 
that locking may not work under FAT filesystems if you are not running 
the Share.exe daemon. People who have a lot of experience with Windows 
tell me that file locking of network files is very buggy and is not 
dependable. If what they say is true, sharing an SQLite database 
between two or more Windows machines might cause unexpected problems.

actually I am about to give sqlite a try this week. One of things 
which drive me to this solution is that it allows for sharing.