AltME groups: search

From file list example: "text-list files do [set-face ca read-string 
pick files value]" - where does the 'value come from? Is it internal 
facet of 'text-list style?

Well, that's what comments in the blog and here are for. Please provide 
a list of things you consider important and we can discuss the list 
and get them included, or come up with alternate features that do 
the same thing but better. Don't assume that any features we already 
have will conflict with what you want. Feedback is king here.

The "list of widgets" post?

yes, list of widgets ... we should not release without widgets like 
tab, tree-view, basic table (list-view), accelerator keys (needing 
redesign of all relevant styles imo, because rich-text will be needed), 
tabbing support. VID2 show stopper was missing more advanced styles, 
at least above mentioned. Those are needed for basic prototyping. 
Newcomers will not be able to produce them themselves. Most ppl would 
prefer such things instead of fancy color requester etc.

Simple answer: I don't think we are currently talking about finalization 
and the color picker was an example, not a feature.


Longer answer: The new GUI is going to be part of the open source 
portion of R3, and open source projects are never really finished 
until they die. So the question here is not "finalized" but "ready 
for a release to the wider developer community". In order to do that 
we need to put together the core design of the infrastructure and 
enough styles to get the new DevBase GUI up and running. Right now 
we are focussing on styles and features that have the most impact 
on the system as a whole, or the most potential to flush out bugs 
in the underlying runtime.


If it all seems low-level, that is because it is. We will have a 
development release before we have most of the styles you mention 
because we will need the help of the developer community to make 
those styles and more. However, don't expect the styles you list 
to be missing - some of them meet the criteria I lested above, like 
helping flush out design flaws or use in DevBase.

The new GUI is going to be extensible with new styles. No list of 
styles will be sufficient for everyone, so we are enabling and encouraging 
developers to make their own. For instance, I would like some styles 
inspired by the Office 2007 UI: ribbons and contextual toolbars. 
I know whole applications that are less complex to implement than 
those styles, so I would not expect them to be included in the core 
release at first.

Henrik, I just checked out your latest movie (#3).  Very nice. I 
was wondering (as I always am) about the lists - There's a note that 
mentions that there will be tables. Will that in essence be like 
list-view?

james, for now lists are one-column tables. the code seems to support 
multiple tables, but I've not seen them used that way. I think the 
list-box style needs more code to handle multiple columns properly.

dialogs are nice (although I hate them as a concept :-), but the 
most important for ppl will be lists - tex-list, list, grid, tree-list. 
Those are more complicated style, and highly expected ones (looking 
into blog comments). At least one of those styles should be tried 
to proof the concept. So far the most difficult style which was build 
seems to be scroller (area)?

Of those you list there, only modules are getting some love as a 
result of the GUI work so far, as the GUI will be modularized. However, 
the new GUI will be used to implement the new DevBase, and that will 
bring us open source code and more people.

I think no more styles are defined. Dunno if even general list is 
in there ...

I know.. what's with me and the "list" fixation? I wonder if it has 
to do with always trying to order my life. Actually, I thought that 
this is the first thing that my .Net friends are going to ask to 
see.

Perhaps this is a good topic for a list of gadgets that are needed.

I wonder how would AltME looked using new skin though. It would look 
like more typical OS app, and I might loose interest in it just because 
of that. What could be better is the keyboard support (in list, tabbing 
between panes, etc.). I think that special apps with special purpose 
in mind, will need special skins ...

Henrik: Cool stuff so far. But, aren't you the guy doing the list-view 
stuff?


I think the current VID should really be stressed on a complex real-world 
example: A Table/Spreadsheet that can handle 1 Mio. rows with high 
speed a la Excel. It's a widget type you can use to show stuff or 
even let people enter something.

Robert, yes, I did LIST-VIEW. With current VID, do you mean R2 VID?

IMO rebrowse should be far away in our todo list. So much core capabilities 
was missing in the first R3 released.

When i read that for Carl, [parse] evolutions must be downsized the 
most as possible (while I believe this is one of the most important 
functions 

in Rebol), i have still some doubts how priorities are well defined.

Don't know - it makes sense, only if Carl takes the list of priorities 
seriously. Maybe he has his own opinion and will choose to implement 
according to his own priorities ...

The other issue is that at the current stage of development, R3 needs 
apps. We need network apps to test the network infrastructure, GUI 
apps to test that, the list goes on. We don't need these to do a 
development release of R3, but we need to do a development release 
of R3 to get these apps made. You didn't think that Carl was going 
to delay the R3 release to write a forum, did you?

Slider is really nice, but quite honestly - how often, if ever, do 
you use slider in your app to represent data? I would welcome more 
practical styles as tabs, tree-view, list-view (grid)

Small status update:


- Mostly doing code cleanups and bug fixes now, so changes are not 
very visible.

- Carl has worked on window positioning and popup offsets, which 
were not working correctly. This should finally enable us to get 
popup styles done. Actually I've already done the first for date 
field. Popups are very simple to do, compared to VID. Just open a 
modal window without a border.
- Icarii has begun working on R3 styles too now. Thanks!

- Still baffled at the concept of MAX-SIZE. There are some places 
where it just doesn't work (see my later screenshots with a funny 
curled-up scroll-bar).

- I'm very pleased with my container style. It has proven to be very 
useful and we will build many more styles with it.

- Autogenerated style list and style tree (will publicize this soon 
here. R3-alpha users can see them in Users/Henrik/style-tree.rmd 
and style-list.rmd)
- Over 80 styles now. I suspect there will be 10-20 more.

- Color policies are being settled, so you can abstract colors away 
from a style into a theme.

- Each style will eventually get a tag block. This makes it possible 
to tag a style as 'internal or 'advanced, depending on where it's 
intended to be used and what it can do. This is very useful in documentation, 
and for some styles that need to work together in specific ways. 
It also makes it possible to hide advanced styles from end-users, 
who won't need to use them directly.


For those who have missed it, screenshots and videos are here: http://rebol.hmkdesign.dk/files/r3/gui/index.rsp

Henrik - the problem with the list is its complexity. I am not sure, 
I would like to see hidden advanced styles, but various variants, 
and styles as 'clicker, which has no benefit for an end user, unless 
he/she is ready to produce his own ones, based upon 'clicker.

Simply put - when you look into RebGUI widget directory, you can 
see all widgets, which imediatelly make sense for user - when you 
compare it with the list provided, the difference is very obvious 
- every one single self-descriptory, usable, vs. chaos ...

The style list is only there to describe the styles as they exist 
and are defined in the system: As a single flat list. The 'parent 
value is the only thing to make it into a tree. A tag block would 
help us group it however we want. I don't think there will be problems 
describing the styles in the documentation in a clear fashion.

What is the style the picture shows? List-view? Or some grid prototype?

Ok, I'm building it of several parts. (This may change if I find 
some more clever way of doing it.) First there is a DATA-GRID, which 
is a TIGHT style that contains actors to generate a grid view and 
links to a block of data. DATA-GRID is a slave style in that you 
link it to a data block and then it will display what it can display 
of that block from a start index set in the style, so it works like 
a data window. TEXT-GRID is currently just a variant of DATA-GRID 
with different spacing between cells.


Next, we can move that start index around by attaching a scroller 
to the DATA-GRID, and set the DATA-GRID's ON-SCROLL actor to set 
a new index, based on the input from the scroller. The scroller will 
be set based on the size of the data block versus the size of the 
data grid. Presto, a functioning list view.

I will explain sorting, filtering and all that later.

If I get to do it, sorting will be non-destructive, like LIST-VIEW. 
This means keeping a sort index. But that depends on how complex 
it will be. Carl tolerates only little complexity.

Re; LOAD; well yeah ... TRANSCODE can be used to support junk! now. 
 ;)  You'll love it Brian, really.  You can have your grandma asking 
you questions about deep deep PARSE problems as she dances around 
the console analyzing her grocery list, while you point out that 
the total is actually wrong due to a lexical problem with some of 
the money! values.  Then, 4 months later, she'll teach you something 
that her new perspective and point of view made possible as she unveils 
the world's greatest home management software ... like evv-a.   :)

Note that your parameter was the last in the list, the second condition 
mentioned above. That would only work if the calling expression was 
the last in its block because of REBOL's evaluation rules.

Is there a list of all those contributing to R3?

Our official people list appears not to be up to date:

http://rebol.net/wiki/People

:-)

Public messages moved. I'll move the private messages when I figure 
out how to list them.

>> ? evoke
USAGE:
        EVOKE chant

DESCRIPTION:
        Special guru meditations. (Not for beginners.)
        EVOKE is a native value.

ARGUMENTS:

        chant -- Single or block of words ('? to list) (word! block! integer!)

One question to R3 chat. Was there any change, that enter now does 
not list new messages one each time?

If such functionality was removed, how do I simulate it? L does list 
of msg heading, lm lists msgs even with body. But all of them at 
once, not one in each press ?

eh? you launch demo, go few items down in text-list, select text-view, 
and it crashes to console with:

Cannot parse the GUI dialect at: 'set ts read-string %main.r

Is there  a list of all the widgets available for R3 ?

Graham, I think you can get a list from within the R3 alpha as discussed 
here: http://www.rebol.net/wiki/GUI_Example_-_View_all_styles

That list will be larger when the real skin comes in.

In fact the list may be so large, we have to group them. Carl and 
I have discussed a tagging system, that lets you know which styles 
are meant to be used for you (end-users) or which ones are meant 
to be used for skinners to create new styles.

http://rebol.hmkdesign.dk/files/r3/docs/style-list.html
http://rebol.hmkdesign.dk/files/r3/docs/style-tree.html


Not a complete list. Some will disappear again, but it's what I have 
here.

kib2: about the GUI system, it is very far from done, so don't be 
too disappointed. Also we have a private bug list for the GUI alone.

Primary issues with the GUI:


- Layout resizing can result in too much horizontal stretching and 
too little vertical stretching.
- Style list is very incomplete.
- Keyboard navigation is very sparse.
- No rich text editing.
- Skin will become more esthetically pleasing later.

- Some nasty bugs in the low level graphics engine, not yet solved.

What is not likely to change:


- The design of the system feels very solid. Every time a change 
or addition is made, it's 5-10 lines of code.
- Style creation process, so feel free to make your own styles.

What is likely to change:


- The layout engine gets new features now and then to simplify the 
dialect.
- Popups, dialogs.

I liked list and hash and did use them a lot.  List was was buggy 
though.

eh ? bug in list ?

Because of list being buggy sort was modified so that it doesn't 
use list.

I don't know much about vector or map but I hope that we haven't 
loss the functionality of list and hash in R3.

I used list! once in list-view, but found that it had too much overhead, 
when needing to use it as a block, so it had to be converted.

Yeah that is what made list less desirable for me as well  Henrik.

Brian, I think we need to address the lack of list in R3.  Maybe 
a list like handling of block data that still returns a block.

at the performance level of list.

There is a proposal (looking likely to be implemented) to have FOREACH 
work on object! and map! types. The word list syntax would be restricted, 
but you could do your traversal that way. In the meanwhile you have 
WORDS-OF to get the keys in a block, VALUES-OF to get the values 
in a block, BODY-OF object! to get both in a block (map! proposed 
too) and TO-BLOCK of map! to get both in a block. It works, but the 
FOREACH proposal would create fewer intermediate blocks.

Theoreticaly empty space may be in the middle, that is question of 
implementation with influence to performance of course (and diference 
betwen block, hash, list, map etc.)

I have no clue about low level implementation of blocks, but if it 
would be double linked list (from C algorithm POV) it wpould be possible, 
but you are right, doesnt mention it

So  for instance from the wiki we have this

files: read %*.r

view/across [
    text-list files do [set-face ca read-string pick files value]
    ca: code-area
]

when maybe somet hing this is preferable

actions: [
	tl:.on-click [  [set-face ca read-string pick files value] ]
]

view/across [
    tl: text-list files 
    ca: code-area
]

Couldn't you do something like this, using compose?

actions: [

 my-text-list [set-face my-code-area read-string pick files value]
]

view compose/only [
	my-text-list: text-list files do (actions/my-text-list)
	my-code-area: code-area
]

It should be pretty easy to write a function that maps an ACTIONS 
block such as the following into a window:

	actions: [
		my-text-list [
			do [set-face ... ]
			"other-event" [ blah blah..]
		]
	]

Essentially:

view [
	; ACTIONS
	my-text-list/action: [set-face ...]

	; STRUCTURE
	my-text-list: text-list data files
]

view [
	; STRUCTURE
	my-text-list: text-list data files

	; ACTIONS
	my-text-list/action: [set-face ...]
]

view [
	; STRUCTURE
	text-list data files  ; <---- element #1
	code-area  ; <---------- element #2

	; ACTIONS
	[on-click [set-face ...] ] ; <---- actions for element #1
	[on-enter [ ... ] ] ; <---------- actions for element #2
]

We could combine both approaches. In the ACTIONS section, if there's 
a word followed by a block, then the word is the name reference to 
the element (eg. 'my-text-list), but if there is just a block, then 
the next element is taken anonymously.

view [
	; STRUCTURE
	my-text-list: text-list data files ; <------ element #1
	code-area ; <--------- element #2

	; ACTIONS

 my-text-list [on-click [set-face ...] ] ; <----- actions for my-text-list

 [on-enter [ ... ] ] ; <------- actions for the next anonymous element 
 (in this case code-area).
]

view [
	; STRUCTURE
	my-text-list: text-list data files ; <-- element #1
	label "on-line"
	code-area

	; ACTIONS

 my-text-list [on-click [set-face ... ] ] ; <--- actions for my-text-list
	[ ]  ; <-- actions for label

 [on-enter [ ... ] ] ; <--- actions for the next anonymous element 
 (code-area)
]

Just thinking, should the actions section be specified in a block 
? eg:

view [
	; Structure
	my-text-list: text-list

	; ACTIONS
	actions [
		my-text-list [ ... ]
	]
]

view [
	; Structure
	label "hello"
	panel [
		; Structure
		my-text-list: text-list
		actions [
			my-text-list [ set-face ... ]
		]
	]
	actions [
		[ ] ; <--- actions for the LABEL
		[ ] ; <-- actions for the PANEL
	]
]

view [
	; Structure
	label "hello"
	text-area
	my-text-list: text-list
	code-area

	actions [
		my-text-list [ set-face ... ] ; <--- action for my-text-list
		[ ] ; <-- action for code-area
	]
]

So, above, during code maintenance any number of extra fields can 
be inserted before my-text-list and it won't affect the actions assignment.

view [
	; Structure
	label "hello"
	text-area
	my-text-list: text-list
	code-area

	actions [
		text-list [ set-face ... ] ; <--- action for my-text-list
	]
]

there's only one text-list in the window

There can be an overlap in names, so we have to deal with this possible 
ambiguity:
view [
	text-list: text-list  ; <--- TEXT-LIST #1
	text-list  ; <--------- TEXT-LIST #2
]

Where the name-reference is the same as the element type (text-list).

actions [
	text-list [
		[ text list 1 ]
		[ text-list 2 ]
	]
]

Perhaps lit-words could be used to indicate that it's a type, eg:

	actions [

  'text-list [ set-face ... ]  ; <-- Action for all text-lists in the 
  window.
	]

so you meant:
	actions [
		text-list [
			[ ... ] ; <-- action for the first text-list
			[ ... ] ; <-- action for the second text-list
		]
	]

view [
	; Structure
	text-list: text-list  ; <-- Named text-list.
	text-list ; <-- Anonymous text-list.

	actions [
		text-list [
			[ ... ] ; <-- Action for first text-list
			[ ... ] ; <-- Action for second text-list
		]

  'text-list [ ... ] ; <-- Action for the specifically named text-list, 
  'text-list.
	]
]

It should be easy in rebol to define actions programmatically, or 
to make your own style of text-list before-hand.

Well, I think it can pretty easily be done for your own forms, by 
making a function that accepts an action specification, as above. 
Apply it to your forms and that's that. Eg. if you could say:

	window: layout [ ...text-list ... ]
	set-behaviours window [ text-list [...] ]
	view window


Wouldn't that be almost as good (if not better) than any built-in 
inline action specification ?

On my todo list.

Pekr, Brian has a very very long todo list :)

I expect that my work on some of my todo list will take the form 
of helping others do it - it's more of a to-get-done list :)

However, I was not precise enough about my todo list. No REBOL interpreters 
are on it - I want a REBOL-to-JS compiler.

For changelog - bewary - the list is empty unless you select concrete 
product at the top right section of the screen ...

they are not "hidden". they are just not part of the standard style 
list. and you can't create free-drag or lock-drag items in your layout 
without creating a style.

R2-Forward has been updated to match alpha 37 as well, though that 
meant adding one more function to the todo list (and 5 more to the 
done list, and 6 more to the improved list) :)

Sorry, make that 18 more to the improved list - I forgot to include 
last night as well :)

The function I added to my todo list yesterday is done. Two lines 
of code, though they are tricky :)

The new DevBase (3) mostly works now. I posted some suggestions today, 
but it is usable as-is. I'm only using DevBase 2 for historical reference 
now. DevBase 3 doesn't have a reviewer concept, so I'm going to ask 
Carl what the new acceptance policy is - I have the rank to accept, 
but the guidelines need to be updated for the new model. Most of 
my todo list for DevBase 2 is already implemented in DevBase 3, so 
in many ways it is already a vast improvement.

AdrianS: some small helper, but you probably know it. What you can 
do is partial word searches. E.g. try:

help to- ; and it will list every to-* function
help pr ; it will list every function containing "pr"

For instance, help/limit "blah" number! would only list top-level 
defined numbers with "blah" in their names.

Cool :) To answer your question: Not this week, but it's on my list.

Adrian, what Brian is proposing will get you most of what you want, 
but what you are asking for seems to be a bit to specific and from 
my perspective doesn't add enough value to be worth the time to implement. 
 With intuitive sorting you'ld get all of the functions that require 
both an Integer! and a String! first followed by those that require 
an Integer! or a String!.  About 80% of the reason that I actually 
use Help is to see the order in which a function expects it's arguments 
to be in.  Searching for [Integer! String!] will list the functions 
that opperate on a string and require an index to that string at 
the top of the list and I think that's what you're really looking 
for.  Some people think in oppisite directions and want to declare 
the index first and others want to declare the string first.  It's 
just a matter of preference and doesn't change what the function 
does.

yeah, I found that I had to make a significant mental shift to grasp 
REBOL - all of a sudden though, it became clear - almost an epiphany 
- I think btiffin had a good list of the various stages of understanding

There are some gotchas - I didn't redefine any R2 natives in the 
main module. That is on my todo list for a suplementary module.

Not with the term. Cleaning up R3's modularity is the next thing 
on the todo list, and I will backport it to R2-Forward as much as 
possible. Most of the hard work of the backport has been done already 
by Gabriele in his %module.r. By the way, if you don't use R2-Forward 
as a module, a lot more code doesn't work. The new words are just 
exported from it when loaded as a module - they redefine the global 
words when you just DO it. Those changes to global words can break 
other parts of R2 in unknown ways. If you just import the module, 
only the words in your script are redefined, so only your script 
has to be made compatible.

First of all, this is not the place to discuss such things if you 
want them acted on. AltME is too ephemeral, and some of the core 
people don't come here that often, and most of the core people haven't 
been on the mailing list in years.


Post those links in R3 chat. The modularity stuff can go in R3/Language/Modules 
(2165) and the services stuff in Tools/Reb-Services (54). Keep in 
mind that the vast majority of a Java spec like that is dedicated 
to making Java suck less, so the REBOL version will likely be mch 
simpler.

Question to R3 people:
In R2	>> LIST-DIR %/c	<-- will crash R2.7.6 
In R2	>> X: %/c

 >> LIST-DIR X		<-- will ask a security question to allow, and then 
 return desired results

In R3	>> LIST-DIR %/c	<-- will return desired results (no security 
for alpha R3a.37)
	>> X: %/c

 >> LIST-DIR X 	<-- will give ** Script error: invalid arguement: 
 %X
	>> LIST-DIR :X	<-- will return desired results.

Why do I need to put a : in front of my variable in order for LIST-DIR 
to work properly?  Doesn't seem to be intuitive, does it?

because of how path is defined (as parameter) in list-dir.

func [ 'path ...] instead of  func [ path ...]

don't know why this choice

perhaps to allow this semantic:
list-dir c
instead of list-dir %/c
but it doesn't work

Steve, I'm trying to "capture" the source of LIST-DIR in a separate 
file, but I don't have the syntax quite right.

R3	>> SAVE %listdir.r SOURCE LIST-DIR	<-- donsn't work, I'm not sure 
how to sturcture this command