World: r3wp

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

then perhaps this could be done:

undoer: make-undoer

view [panel [...bunch of fields...] options [undo: 'undoer]]

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.

although that specifically implies that you actively need to do some 
specific work to activate undo. I don't like that.

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.

non-destructive datasets: this also implies that the undo engine 
really stores all temporary data. it could be an issue with larger 
data sets, unless it's possible to compress them into changes.

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.

might even be that the gui which manages the effect cannot be re-opened... 
ex photoshop.


and yes the data has to be stored somehow... another thing the undo 
"actions" are able to manage better/

they might know how to store things in diff mode, but only it can 
know based on current state, when its remembering.

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.

I'm pleased with this discussion. Undo journaling is sorely lacking 
from many systems

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.

yep... what I call actions above.

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.

where undo/redo starts to be challenging is when you don't deal with 
pure texte anymore but that you have to deal with formated text.

with only keeping full tracks for the "actions" into an Area type 
face the undo/redo statcks could be on big documents really heavy 
in memory.

some kind of binary labelling for action is then  needed to keep 
memory use to the minimum. You have to keep record fo the postion 
elements within the text too...

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.

otherwhile you loose information or better say course of actions.

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.

Yes. The style needs to interface to the engine without user intervention.

Style writers are the people doing the work for the rest of us.

And the engine should make it easy for style writiers. :-)

New r3-gui.r3 available at:

http://94.145.78.91/files/r3/gui/r3-gui.r3

No changes to other components.

thx.

and changes to gui itself? at least in brief?

mainly fixes

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.

Unofficial A110 available:

http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

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.

So now you can drag tabs to reorder them? Cool in any case.

Yes, exactly.

And there's also tab preview when you hover over tab button.

Ooooh.

Very nice news but I still I havn't seend grids,  file requestors, 
requestors, listiviews, right-to-left support ad many more.
Hurry up, we are waiting !
.
.
.

:-) just joking. Fantastic work !

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.

aking=making

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.

Is that the current fashion .... bevelled tabs?  And not rounded 
tabs?

and would it be feasible to have tabs across multiple rows instead 
of having to use arrows to move the tabs across?