AltME groups: search

hum ...  yes but more with a meanning behind items  on the graph 
pattern. Featuring relations betwin item one to another

using such a tool is like describing your application steps through 
 you have the start point of your application then comes the splash 
screen then comme the main window  in it you put those items etc...

Maxim hum on the graph i can't say you where it starts where it ends 
or what it does ... but the main idea behind a graph representation 
is the one look to it you understand it

elixir actually is a generic procedural data engine.  follow the 
arrows... its just sprawled right now... but if you ordered them 
from left to right, or top to bottom it would be very clear.

but the pic I posted is just a very preliminary prototype... though 
it still works well for demoing the idea for the other levels of 
the system which have never been attempted... well only a little 
bit in my latest glass work.

Maxim it looks great but it's too open ... in my idea what you show 
with elixir should be part of  it  the "free to add thing" part but 
the other part is we have a set of ready made boxes/items you just 
need to set an execution path and give them some related information 
like position size text etc...

i like the idea of having a really simple way to look at rebol app 
and then you can edit part of it add new boxes with crazy new stuff 
etc.... it's somehow what we do in text based coding 

but on heavy fragmented project it's hard to have an over view to 
it ...

I just wanted to show you that there is someone already tackling 
the idea... thoug it will still be a few months before I have any 
R3 version of elixir (the move to R3 and the wait for extensions 
is the main reason I stopped working actively on elixir)... it was 
just tooo demanding for the R2 platform, in just about every way 
possible.

problem with this kind of representation as a former small talk extensive 
programer is deeper you go in the specifications more blurry is you 
view ... it's like a melt of lot of boxes everywhere with arrows 
linking them to any direction ... that's pretty hard to handle ...

it can be.. with some compositing I've done I had hundreds of nodes 
in a single shelf... at some point we would do node art   ;-)

I know I want the basic repitive task to be handle faster... then 
the other probleme is in a function setting a hierachy of calls ....

this aspect is  not usefull on linear easy applicaitons very straight 
forwarded but on complexe application what comes first can be determining 
betwin a working application and a crashing application

maybe somthing like a popup note  when you passe your mouse over 
the node you have like an insight of the node contents and maybe 
a closer view to the links to arrows

all I can say is that on a theoretical level it scales better than 
any other system out there... because using dynamically adapting 
networks of any kind, the structure has as much value as the rest. 
  the fact that its also visual is just icing.

one thing that should be cool to should be the capability to export 
new feature item. Let say i create a splash screen ready to use window 
you just have to provide an image to it so new in my tool box i have 
this new "piece" of ready to use code it would be pretty fun to be 
able to exchange it to others ...

if those sharable items can be synchronised from a network source 
this should be really awsome... recently i saw google document was 
able to share document editions in live that's cool stuff too for 
an IDE to be able to discuss code and then co-write it ...

with elixir you can build google-wave like concurrent user apps with 
just a few nodes.  then you can wrap them in a pool and just provide 
the pool as the data to another node.


it is even project that we will be able to reverse-script a pool 
and provide its structure as an output, so that you can actually 
share the pool's structure in real time along with the data it is 
linked to.

sorry i'm trying to imagine using such a tool to write an area_TC 
...

people must understand that this effort is not just "for fun" I've 
been reading almost 4 hours a day on average on various topics so 
that the performance will be hard-core, at least the design will 
allow it to be sooner rather than after 15 rewrites.

maxim in a near futur the APU will lead and rebol should be able 
to adapt to that hardware change fast ... And benefit from it

its to program a completely new OS design which was tought of 15 
years before terms like "the cloud" became buzzwords.  In this system, 
there is no concept of cloud as a difference in your day to day work 
and play.


in elixir, you are not on or in *a* cloud, the idea is that everything 
we relate to *is* a cloud.  from the button which you click on (which 
is part of the application's cloud) to the current definition of 
servers that process services.  in fact, in elixir, the button state 
of your application can become input data for ANY other node. be 
it in the app, or within a single integer variable sitting in a process 
queue on a server... its the same interface to link them than to 
create a new thread.  there are basically no differences.

that like the rebol.org in a potential 10 ... some step forward the 
rebol/desktop concept ... those idea of distributing or lets say 
shared code repository is just facinating ... so much more can be 
done in that scope

glass v2 already proves the interface can be a cloud of nodes... 
I just shipped my first 400kb glass based app to a client two hours 
ago.


it can scale to 200mb of nodes and data editing people softs' incredily 
lame SQLserver DB setup.

although at some point it gets really slow because of the limits 
of R2... it just chugs along never *EVER* breaking about even though 
at some point I've got about 50000 nodes talking to each other.


actually, the only thing that does constantly break a part is everything 
which isn't representable as nodes... like events, and input data 
files which I must read and convert into nodes, which get connected 
directly to the interface.

i will try to think this  more  i like the idea of  having a fast 
view uppon rebol script as a view boxed/noded in realation one to 
another. I like the idea of behing able to "enter" those box/nodes 
to adapt them enhance them or simply redefine them. I like the idea 
of sharing pre-sets box and having a synchronised / shared tool box 
.If i design a tool and make it available then in a short time that 
tool becomes part of the hudge collective tool box and then is shared 
to every one.

i like the idea of a splendid scenarised grphical overview ..

wrt teapot progress ...  in many ways its regressed  ;-)


The teapot was a test of how to integrate something into R3's view 
engine safely and without any side-effects.  hopefully some of that 
research will allow us to better hook into R3 with an eventual tiny 
expansion of the gob structure.


now I'm actually building the engine which interprets user data and 
sends that data to the integration I did earlier. 

though its pretty much empty right now.  I'm *just* about to add 
reading of a user built block of data which I convert to low-level 
C structs and then render in HW.

then can a recusiv process be the base of the tool creation/collection 
can then those basic bricks be assembled on more sofisticated tools 
 those sofisticated tools being then short cuts to create your own 
software

I'm also beginning to feel like a real C programmer... which is a 
welcome change...

pools become nodes.  so anything that can connect to a node can also 
connect to a pool (which means everything per the philosophy of elixir).

to each of those tools there is a auto generated form that you will 
feel to set up your function arguments

this is known as a "process" in elixir... scripts which build up 
nodes and link them up in a specific way.


tools are processes which have a persisten interface (cli or graphical)

have a good and smooth progression then maxim

yeah... there's still a long ahead of me... though I'm now running 
instead of crawling towards it.

yeah but i'm a drunken idiot so most of it is too polished for my 
grasp ;)

now discussing undo/redo management. There is a small spec available 
here:

http://rebol.net/wiki/R3_GUI_Specs#Undo.2FRedo_Management

any input is welcome.

forcing a 1:1 undo thread to window   relationship breaks up quickly 
when you consider that some windows operate on many threads and some 
threads will require many windows .

ok, then we would need a different method for coupling an undo context 
rather than in the face.

best is to have a simple block with named threads... and you force 
people to supply the thread name when using any of the undo/redo 
functionality.


also, undo/redo is best done when its not directly part of the gui. 
  


though its nice when the undo engine is able to speak to the gui 
directly.  the gui must not be the "brain" of the undo..

having written  a few, I recommend making it an external api which 
is fully "gui enabled"   this way, undo events can automatically 
call face accessors,  and you can put the undo stuff in the logic 
rather than the gui.   many times, the logic might generate a few 
undo, or none, based on things which the gui can't properly be aware.

undo/redo is a pretty complex thing and unless you've got a non-destructive 
dataset, its almost imposible to make it a generic tool that is actually 
stable.

yes, the idea is also that it can be entirely decoupled from the 
GUI, so if you don't want it or want to use a different way to undo, 
that should be possible. the task for undo as I see it is to read 
actions and allow playing them back by taking control of the GUI.

take the case of a system where the undo crosses the lifespan of 
a window (or a few) how do you undo that?  re-open a new window which 
isn't connected to anything?

it basically has to be built with undo actions at the center.


each action has to be able to handle any gui issues gracefully... 
the gui itself cannot manage that unless its an uber simple gui.

also, there is a tricky thing to redoing in that its often more like 
a complement than an inverse of an undo... especially when storing 
diff data.

so the undo data and the redo-data aren't necessarily the same   
:-(  


my best system was using dataflow nodes.   but it requires a dataflow 
dataset.

The standard design pattern applied to undo/redo is the Command pattern, 
which implies that everything you want to undo or redo is a command 
that knows what it means to perform an action and apply its inverse, 
and the target of the action.

also most undo/redo tie-in commands with macros and/or actual gui 
buttons and menus... sort of like the internal API for the lower-level 
stuff.


each of these commands/actions puts itself on the undo stack  and 
usually has a counter command...  add-text/remove-text, edit-record/restore-record, 
etc.

only  edit face needs the undo/redo stuff ... and mostly Area where 
you can input large text for text field it doesn't matter and could 
bring a security breach ... If you ca recall the previous password 
and user entrered in a login window for example.

efficient undo/redo have to be face based. The need for other face 
to access it is irrelevant as  it's a temporary buffer  and that 
this buffer main fonction is to keep tracks of the changes. Wider 
you keep the tracks heavier is the syttème. If that systeme could 
be arguments passed to configure and tune it that would be top.

another optimisation is that when you create a document you will 
obviously do alot of insert action so the idea is to regroupe the 
insert actions betwin  insert space
For example:


insert "a", insert "b"', insert "c"; insert " " -> trigger of the 
sorting algorithm insert "abc" [line1-:-0] (this optimisation can be 
seen in OpenOffice 3.2)
 

Would be better if instead of registery the action done by the user 
you register the mirror action to be apply to reverse it
then you have

delete "a", delete "b", delete "c"; delete " " -> trigger concatenation 
algorythm delete "abc"@line1:0, delete "space"@line1:3 (position 
here is set as line number followed by the caracters to pass in the 
line before reaching the character can speed up rendering if you 
are able to use remove index stuff in my opinion)

anyway good luck in this hudge task you could write a book only on 
the undo/redo functionnality ;).

there is so many to say about undo/redo functionnality that it can 
be the subject of a book of it's own easyly....  (sorry previous 
sentence wasn't pretty understandable)

undo/redo works as a LIFO pile.

you have to keep the deletions active in you record

lets say the user does:

insert "a", insert "b", insert "e", backspace "e", insert "c" then 
the concataining algorythm have to merge insert "a" and insert "b" 
into insert "ab", but need to keep record of the actions insert "e", 
backspace "e", insert "c" in order to unpile it properly.

You could write a lot about it for sure, but it's worth looking at 
for the general case beyond simple char-by-char text edits. Consider 
fwd/back navigation and breadcrumb trails. The trick is to leverage 
the generality and use it to make things easier, rather than making 
more complex.

it's potentially a rat's nest to stick our fingers into, but from 
a simple developer's starting point, it should work without doing 
anything to the style or the layout. that's where I think the design 
should start.

New r3-gui.r3 released at above location.


New feature: Now allows reactors to be run after a specific actor 
in the style. If your style runs ON-DRAG, a block of reactors after 
an ON-DRAG keyword will be run afterwards. This opens up a lot of 
new possibilities.

view [field on-drag [do [probe 'dragging]]]

This needs a lot of testing.

http://94.145.78.91/files/r3/gui/247.png


Tab boxes now support drag and drop. I'll provide a built version 
tomorrow as I found a build problem tonight, so you can try it out.

Drag and drop - nice feature, about tab preview, I am not sure about 
that one. It felt a bit distracting last time I saw it. Can it be 
turned off as a feature?

Now it's always on but aking a switch to turn it off is easy.

Rebolek, architecturally, it may be a good idea to provide such thumbnails 
as part of the help system, when it comes along. The help system 
is what will allow us to use layouts and gobs as tool-tips for any 
face, so hopefully it will be possible to call up an image in 1-2 
lines of code.

The rounding is only a few pixels, and antialiased. Look with the 
magnifying glass if you can't see it.

Hm, thinking about multi-line tabs - if you have so many tabs, it's 
probably a good idea to redo your UI.

Yeah. The tree view on the left has been a good substitute for multiline 
tabs in recent preference dialogs.

Rebolek - yes, and that is my point ... now I will create a screenshot 
for you, showing the mikrotik feature ...

there was a spec document which specified layers, guides, etc. but 
it's lost now.

The "bad design" part being "too many tabs, use something other than 
tabs as a structuring model".

last used tab, last focused item. there are a few things to save, 
but as long as they can be retrieved and set in code, it should be 
possible to do.

speaking of which: would it not be a good idea to have functions 
that can extract and impose facets on a face in one line of code?

that would make it simple to save a state

I disagree.  Nested tabs are not the same as multiple row tabs.  
With the former you can effectively book mark a deeply nested page 
.. the latter you can not

bad design
 vs "good design" is just a matter of opinion ...

Also the nested tabs allows me to refer to a particular screen by 
a path notation

I was surprised at how "narrow-scoped" some users are, when working 
in a program, almost down to a single face, not noticing the larger 
context or organization of the program, particularly if the program 
has many modes (tabs). I think that its important to design UIs around 
clearly marked mode of operation, or even better: Have mode-less 
operation.

MS approaches this by using a "control panel" of icons

Each icon then deals with a particular subsystem

Right. The problem is usually that an item you are looking for, doesn't 
reside in the subsystem that you think it does, so when there is 
no other way, at least provide a flat structure search.

there is usually a method for searching for what you want. a typical 
mac app even allows searching all menus in the menu bar.

The modern version of the system dialog does a list on the left instead 
of tabs. It might look like a column of links in a left-side navbar, 
but it is basically the replacement for the tabs.

I do not like multiline tabs either, and they violate some of the 
rules of good GUI design.


Sure Graham, good and bad design are matters of opinion; however, 
they are based on what "most users" can understand and efficiently 
operate.  If a GUI causes a user become "lost" or do the wrong thing, 
then it's not a good design.

There is now Carl's blog upon how to easily list styles in R2. I 
posted corresponding R3 code, although it might be preliminary:

foreach [name obj] guie/styles [print [name "-" obj/about]]

But - I would like the GUI team to think about following aspects:


Imo the guie/styles list is highly insufficient. Imagine you want 
to auto-inspect (load) list of styles into your GUI designer. What 
you get now is a flat list of styles, where apart from 'table, you 
have its sub-styles like 'table-cell, 'table-row, 'table-header, 
etc. I am not sure that in the case of an IDE, you want to see those 
styles listed. OTOH those are legitimate styles, from which you might 
want to derive something, or just being able to change their aspects. 


So, I propose to resolve this situation somehow. The implementation 
is up to gurus, just few wild ideas:


- use tagging - tag style as 'main/root/parent, whatever - but - 
that introduces another field to the styles? Maybe not, because I 
expect some tagging system being available anyway?


- create guie/widgets, e.g.: guie/widgets: [table [table-cell table-header 
table-row] - that way we will be able to list just/only widgets as 
table, not having the list poluted with widget internals


- the above aproach might not work well in the case, when you aproach 
styles more as a CSS, not as widgets. Because - even e.g. 'table-cell 
might be derived from a totally different style, e.g. a box, or field, 
so I have no idea of how to keep track of those dependencies, but 
this is the area I leave for gurus to think about. E.g. someone changes 
box style and your table is influenced and user might be confused, 
why it happened. But I expect style/parent or something like that 
being available?

Tags can be used, they are implemented.But, IMO, if you need a list 
of styles for a GUI builder, you better make a list manually.

> Imo the guie/styles list is highly insufficient. Imagine you want 
to auto-inspect (load) list of styles into your GUI designer. What 
you get now is a flat list of styles, where apart from 'table, you 
have its sub-styles like 'table-cell, 'table-row, 'table-header, 
etc. I am not sure that in the case of an IDE, you want to see those 
styles listed.


We already have and use tagging. The styles you mention should be 
tagged INTERNAL, if they are not already, as they are part of compound 
styles. So it's up to an IDE to discern that properly 


It might be possible to make a helper function that filters in only 
end-user styles, but we'll see how important that becomes.

I propose to use guie/widgets then, to group related styles. By related 
I don't mean derived, but more of a compound styles - table is good 
example ...

1) because one style can be related to several styles and new user-designed 
styles and also can be used dynamically by a style, depending on 
the situation.
2) a few lines of code.

Current list of tags (subject to change):

; set at stylize time
style-tags: [
	internal		; the style is intended for internal use
	panel			; the style is panel of other faces
	compound		; the style is a compound of part styles
	field			; the style is a field with editable text
	state			; the style is a user interactive state changing item
	action			; the style is a user interactive action item
	info			; the style is an indicator
	tab			; the style is part of tab navigtion

 auto-tab		; the style automatically tabs away on a specific event
	select			; the style contains user selectable text

 keep			; the style retains highlighting and caret after unfocusing
]

; set at layout and any other time
face-tags: [
	default			; the face is the window default
	focus			; the face is in focus
	disabled		; the face is disabled
	frozen			; the face is frozen
	dirty			; the face is dirty
]

; set at window creation time
window-tags: [

 form			; windows containing a validatable form or other field or 
 state faces

 inform			; windows containing only text or images and no validatable 
 faces

 popup			; windows containing a menu or selection, which when interacted 
 with, results in immediate return of a value
]

ad 1) I can understand that, and that was also one of my worries 
in my initial post. However, as a designer/programmer, wouldn't you 
find usefull to have:


- something like tree-view (or node based visual display) of styles 
and their dependencies?


- wouldn't it help your orientation to have some list like guie/widgets, 
grouping particular styles, just for your info? So that you know 
that e.g. table is being built using xyz styles?

I am just asking - so no offense please :-)

1) One internal style may be related to more styles.

2) Is this really a problem? I see no benefit of having such a simple 
function as part of R3GUI - because R3GUI doesn't need it.

1) It's possible to make the style tree, when the styles are being 
initialized. In fact I already have this as a separate script, but 
it has not been used lately.

Tags are really trivial. They are just a list of words and we have 
a few TAG functions to set/unset/inspect them during runtime. It's 
entirely up to styles or the higher level code to use tags correctly 
and this is for example done with face navigation.

I've got one question. There's face/faces for all faces that are 
part of a face. There also needs to be some container for faces that 
are part of face but are not visible (hidden) right now. Currently 
it's called face/cache, but I think the name should be different. 
Any ideas?

I'm considering a rewrite of the validation prototype as there are 
some parts missing with regards to initial state.


Have there been any considerations on how to use the DIRTY tag? I 
have some ideas on when DIRTY is set:


- The user creates an edit in a field, changes setting in a radio 
group, etc. It would not be enough to focus the face, but a specific 
action would have to be taken.

- When the user deliberately moves the edit back to the original 
state, the field is still dirty, so we can observe which fields were 
manipulated.

- Using a function DIRTY?, we can observe whether a field or a panel 
is dirty.

- It's not possible or logical to set the DIRTY tag programmatically 
(other by forcing it in with TAG-FACE face 'dirty)

It would be cleared when:


- Using a function CLEAN, we can unset the DIRTY tag in a face or 
panel of faces. This would be the only way to unset the tag.

- When the user deliberately moves the edit back to the original 
state, the field is still dirty, so we can observe which fields were 
manipulated.

 - I don't like this one. Than we should have a manipulated flag. 
 As dirty means: changed.

For DIRTY being changed, that has relevance for when validation is 
not used, for enabling submit buttons. But this also means the original 
value should be stored, which may be covered by the undo system. 
I'm not sure that's useful, if the undo system can show the number 
of changes in a field.


For MANIPULATED doing what is described above, it overlaps most of 
what DIRTY would do and it would also overlap most of what validation 
already does, namely detect and approve/deny changes in a field. 
I'm not sure it's useful either.

I have a very basic question, that I have already asked to Carl : 
how to get a working gui.r version ? when doing load-gui, I get the 
following error message : ** Script error: size-text has no value. 
It seems to me that this point should be definitely fixed, as it 
prevents anybody to do view tests (for instance the ones given in 
the reference doc http://www.rebol.com/r3/docs/gui/guide.html) I 
think that this should be done quickly and independently of any improvement 
and evolution of the gui styles and functions.

which is a result of the work of the RM team

Now provides a visible frame for keyboard navigation:

http://94.145.78.91/files/r3/gui/248.png

Henrik, what happened to your skin of a few years ago? That looked 
much better

This won't start until sometime later though, so it's going to look 
like this for a while. I'd hate to do too many rewrites, if I were 
to start now.

that's not certain yet as he has not made any evaluation yet, but 
it will be a publicly distributed GUI, so you can at least get to 
use it.