AltME groups: search

I would like widgets tabling, statusbar, menu, table with free content 
(not only text) colomn resizable and sorting, menu, popup menu,

docking area and dock bars,

Louis: because of the clean seperation between display engine and 
widgets, it's ready now. What's missing is a good widget set to make 
it *usefull*. ;)

Louis I think that depends on how many people work on widgets set 
and what capabilities and imaginativ they are  :) (Cyphre style with 
AGG are trully a good research way )

Definitions of widget on the Web:


    A standardized on-screen representation of a control that may be 
    manipulated by the user. Scroll bars, buttons, and text boxes are 
    all examples of widgets.
    www.redhat.com/docs/glossary/


    A set of clickable, graphical element in a user interface. This includes 
    buttons, radios, checkboxes, and scroll bars. Widgets vary in appearance 
    and dimension from platform to platform.
    www.gerbilbox.com/newzilla/glossary.php


    n. 1. A meta-thing. Used to stand for a real object in didactic examples 
    (especially database tutorials). Legend has it that the original 
    widgets were holders for buggy whips. "But suppose the parts list 
    for a widget has 52 entries...." 2. [poss. evoking `window gadget'] 
    A user interface object in {X} graphical user interfaces.

    www.worldwideschool.org/library/books/tech/computers/TheHackersDictionaryofComputerJargon/chap55.html


    (n.) In a window system, a reusable user interface component such 
    as a button, scrollbar, control area, text edit area, and so on. 
    When an X Toolkit Intrinsics function creates a widget, it is returned 
    as an opaque data handle and assigned to a variable called a widget 
    identifier. See also OLIT.
    docs.sun.com/db/doc/805-4368/6j450e610


    – A graphical user interface programming object (button, scrollbar, 
    radio button, etc.) for the X Window System. (Also, see X Window 
    System.)
    www.newtolinux.org.uk/glossary.shtml

IMHO you have a tendancy to confuse a user if switch lingo in the 
middle of something so you might as well begin with the lingo that 
you want to use for the entirety of your docs and provide definitions...

alternative view point - some of us are infrequent view users, and 
the extra jargon we have to remember just makes things difficult

...With the definition of each of them somewhere near the top of 
the document or easily accessible.


Yes, please give a clear defination and example for every term.  
Do not asume that anyone already knows the meaning of a term.  The 
fact that a term can have different meaning in rebol can cause a 
lot of confusion sometimes.  For example from the Core manual, "The 
copy word as used in parse is different from the copy function used 
in REBOL expressions. Parse uses a dialect of REBOL, and copy has 
a different meaning within that dialect."

Ashley, what is the point of only using positional references to 
sub-faces?  The whole reason that I started creating my styles was 
because I found the positional references of VID to be too restricting 
and difficult to deal with. IMHO, just making subfaces a facet of 
the style face increases the usability of VID at least 10 fold.

Louis, agree totally. Witness the confusion between Anton and myself 
in the View group about what a facet is (and throw into the mix View 
facets, VID facets and Style facets). I also don't like the close 
visual and phonetic similarity between face and facet ... it's just 
too easy to mistype / misread (with a single "t" to distinguish the 
two). Another term to consider:

	Feel, behaviour, action or event handler?


The very first section of the document will be a concepts / terminology 
section which will have a simple table that maps View terms / concepts 
to their RebGUI equivilents. Thereafter the RebGUI terms will be 
*consistently* used.

Ammon, positional references should only be the concern of the widget 
designer (ie. its not a user-code level concern). If a complex widget 
needs additional facets to control its appearance and behaviour then 
I'm all for it. Once we get a widget or two under our belts, we can 
write a "Widget Designer's Guide" to at least have common accessors. 
(there's another term we need to nail down).

Yeah, the accessors...  Not sure I really got the complete concept 
of accessors.  IMHO, it is just extra work and the developer not 
the end user who puts the widget in an application generally has 
to build those unless the end user starts digging deeply into the 
style.  This IMHO, is a MAJOR problem.  If you make the sub-faces 
a facet of the style then the end user can always access the sub-faces 
of the style and do as they like with them AND DO IT EASILY.  And 
the developer gets the benefit of not having to guess at all the 
ways that the end user may want to access the sub-faces!  That in 
and of itself is a goldmine, to me.

Terms: I'm all for using "standard" terms. I must say that View always 
forces me to map the words and rethink them. I would like to see:
	Window
	Canvas instead of face

 Attribute instead of facet (please keep non-native speakers in mind)
	Action instread of feel
	Widget instead of style

For me a Widget can have different styles: Windows, Mac etc.

Yes, but it makes switching to Rebol really hard. I still get confused. 
It's the same with Maxims Steel! stuff. The words just don't help 
me to undestand what it's about. It's contra-productive. Even if 
wording might not be perfect it's known and people willl know for 
about 80% what it's talked about.

The more standard the terminology used, the more "standard" expectations 
people will have. I think the rebol way is quite different to other 
languages, so it shouldn't restrict its language (and thus ideas) 
to other standards.

Well, you can see it both ways. And I don't think this argument is 
winnable by either side.

and i hope rebGUI will integrate new widgets that doesn't exist in 
common VID engine so

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? ;)

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)

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! ;)

http://www.dobeash.com/it/rebgui/facets.html#section-5

May be you can add to the 'effect definition that any effect can 
be used. Not only 'bezel, 'bevel and so on

I have monitored  the memory consumtion of test.r script and I have 
seen that every second betwin 4 to 8 ko are allocated maybe there 
is something to do to avoid this

Shadwolf, the memory used increases always more and more ?

just comment the recyle and then the memory consumtion is back ...

and it's stable without it there very mutch allocation before GC 
to be called

i think 'show use some memory, and don't recycle it
it would be bigger else, something like  n * image size
I tried with bigger images (400x400 instead of 40x40)
and only 16k more is allocated at each time

I remove the show ace and I still have memoru leak

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

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! ;)

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


Check out the new tab-panel widget and updated View facets document.

Mm, I have the opposite problem ... I just want to double-click the 
script and when I close the window I don't want to then have to close 
an additional console window. ;)

Right click just about any file and you can change the EXE that is 
associated with the file's extension so, potentially any version 
you like.

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?

thanks :-)

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

thanks, will try it. Debeasch, it is Ashley, right? If RebGUI will 
be of the same quality as RebDB, it is surelly gonna be cool. Ashley 
is very good and precise designer, his code is nice. Other such folk 
is DocKimbel, his mySQL code was pleasure to study :-)

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

Vincent: rate suggestion ... done (overlooked in 0.1.3)

Robert: Will the splitter be integrated into the next release? ... 
Yes

Pekr: "I want full OS compliancy in behavior" ... which OS and what 
skin?

Ammon: "RebGUI is ..." ... spot on, and I like that sentence so much 
I'll add it in some shape or form to the main page ;)

Ashley - it was long discussion at some stage of View 1.3 project, 
but shortly - my opinion is, that we don't need to skin anything. 
IMO it is good and vital, if we are distinguishable, so ppl can say 
- it is that colorfull app, Rebol :-) What I have in mind by OS compliancy, 
is behavior, so mainly keyboard handler, but also mouse reactions 
etc.

Proper and OS compliant behavior is imo MUCH more important, then 
skin ...

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

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.

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

why not totally different look and behaviour - the nearly same is 
annoying, the different is... different

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)

Interesting, and I'm certainly open to new ways of doing things ... 
but two marks against it for me are:

	1) It's overly complex [for RebGUI]
	2) I tend to design like I write - left to right, top to bottom

Nice concept though.

offset is still needed for precise effect but using this kind of 
organisation that is more powerfull than below accross  we ca  make 
quite and easy beatifull graphic interface

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)

I wonder if we should use an existing dialect and modify it to product 
ps .. or create one from scratch.

So, for example, if we used to plot dialect to draw a graph, we can 
then emit postscript and send directly to the printer.

In the name of science, I repeated the above test and it printed 
out again.

DRAW is also a function used like:
img: make image! 100x100
DRAW img <some draw commands>

With PostScript, I'm thinking something like:
ps-output: ""
POSTSCRIPT ps-output <some PS commands>


ps-output could then also be a file! or port! and send the output 
directly to the destination.

Is the aim to take a draw block and process it so that postscript 
is produced.

It's one way of doing it, and maybe not so bad. I don't know enough 
about PS to see, if DRAW is too limited. Maybe PS has a lot other 
stuff, you wanna do, that is difficult to do in DRAW.

The DRAW approach is, that if you can produce your output in a DRAW 
block, then you can also print it using PS. My approach is to make 
a PS dialect, and keep DRAW out of is. With my approach, you can 
print from REBOL/Core too. I guess, we can have both approaches without 
problem.

And both will be usefull for different situations.

but let's start with a postscript dialect and then see if we can 
retrofit draw to it.

since rebol3 is coming, and View may well change, it makes less sense 
to stick to the past.

I would save the state and then restore it.

So far, you can specify font, set position and print text.

so, you need also the %! at the beginning, and a showpage at the 
end.

Desitions have to be made about the dialect structure. Should the 
outer block consist of font-specifications and pages, or isn't that 
structure the best for PS? A better understanding of PS is needed 
to answer.

I'll look at all the PS operators to get a view of the whole thing. 
Then define a structure for the dialect (probably top-concept of 
a page), and then implement the operators most needed.

Would it be normal in PS to define the font before anything else, 
and then describe pages with paths? Is that the structure?

I wonder if we can't just use Gabriele's dialect and build a different 
emitter.

New version. The postscript block consists of font definitions and 
pages. A page consists of paths and transformations. Try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

print postscript [font [Times-Roman 20] page [path [at 72x72 rotate 
45 "Hello World!"]]]

The "page" and "path" words are optional, so this'll give same result:

print postscript [font [Times-Roman 20] [[at 72x72 rotate 45 "Hello 
World!"]]]

A postscript block can have several pages, and every page can have 
several paths.

PostScript has a lot of operators (commands). For this REBOL dialect 
to be usefull, we should keep the number of features at a minimum. 
It's always hard to learn something new, and if the number of commands 
is too big, less will use it. I would like feedback on, what features 
should be supported in the dialect for a first version. This dialect 
can then be used in REBOL programs, that would like to do PostScript 
output. And I could make a PostScript output from my NicomDoc format. 
And then we could also have a DRAW -> PS converter.

OK, enough, and now something at least a bit more constructive:

One thing that may become an issue on the future is syncronization 
of Color Profiles. Different display and printing devices hace different 
gamma curves. This should be an issue for black and withe and vector 
graffics, put if you are printing a rebol screen. Then you may need 
to take the color profiles into consideration.

even just by making vectorgraphics and text in PS now is great. it'll 
almost fulfill my needs

and we'll use it  ;-)

well we can convert a draw block to-image and then send that out 
directly.. but its very slow to print... I mean sending 300 dpi or 
more bitmaps to a printer is tedious.

300dpi = 300 ticks in an inch.  if you know the printer edges to 
be 1/2 inch, then you can juste calculate a 2250 wide bitmap (using 
US letter size paper)  and send it .  this works.  simple math .

and you can scale it to whatever resolution...

a good solution might be to use decimal 0-1 values and just recompute 
them to whatever output you are using (so adapt to any paper/bitmap 
size)

geomol, on feedback, I'm not entirely sure what the initial supported 
functions could be since I'm not an expert on DRAW, but at least 
support for text and vector graphics. the coordinate system for DRAW 
and PS would be nice if it could work identically.

Ok, text and vector graphics ... and some grey-tone/colour for a 
start. And then the rotate, scale and translate, that's already included 
in my postscript dialect.

positioning and size is the most important in the preview. rendering 
and prettiness is less important

for line elements, and text, that should not be a problem ( given 
the same fonts ).

Like you, I'm primarily interested in text, and lines ( my application 
uses LaTeX at present to do text ).

I need to output tables and text at specific locations as well as 
bar codes

I've seen a problem with a barcode reader that could not read codes 
printed from one expensive printer and it would read them fine if 
printed from another cheap printer

line thickness can be specified in both ps and view.

I didn't discover the error until I tried it on the expensive printer. 
besides the size and position of the line was supposed to be correct. 
the barcode was created with PDF Maker

and it looks correct when viewed in a PDF Viewer

PS has setlinewidth, and setting it to 0 will make is as thin, as 
the device can do.

I think it would be good if someone could produce some draw scripts 
of varying difficulty, and then we can see how far we can get in 
rendering these to ps.

easiest might be some text and lines .. then boxes, circles, fills 
.. then gradient fills etc.

Funny, I was just thinking about that. I think, I'll just make the 
first dialect being a small subset of PS, and then license can be 
the one, Carl talked about in a blog. Was it BSD?

We could then put it in the Library, and others can develop it further. 
(Maybe that should be coordinated somehow?)

graham, even if I take a good PDF viewer and zoom all the way in