On Mo, 21.06.2010 16:29, Tristan Van Berkom wrote:
>What happens when you have multiple buffers editing separate
>but interdependent project data ? Is the new code introduced
>to be so complex that it will handle the interleaving of commands
>on separate datasets into a single stack ?
No, I don't
On Mon, Jun 21, 2010 at 4:03 PM, Holger Berndt wrote:
[...]
>
> [...]
>
>>You don't want your business logic driven by your onscreen widgets
>>haphazardly this way - you need your undo/redo stack to interface with
>>your internal data model - and you want your views to be synchronized
>>to the mod
On Mo, 21.06.2010 14:48, Tristan Van Berkom wrote:
>> - Your stack will behave consistently with other applications using the
>> same stack implementation.
>
>This is entirely speculative,
What I meant by consistent behaviour was the undo stack policy (e.g.
conventional against emacs-style). Th
On Mon, Jun 21, 2010 at 7:40 AM, Holger Berndt wrote:
> On Mon, 21 Jun 2010 12:57:44 +0200 ecyrbe wrote:
>
>> Easy Undo/Redo framework are usually based on Inheritance...
>
> I don't have any statistics, but surely, there are many frameworks
> based on inheritance, and many others that aren't. The
On Mon, Jun 21, 2010 at 7:40 AM, Holger Berndt wrote:
> On Mon, 21 Jun 2010 12:57:44 +0200 ecyrbe wrote:
>> [...]
>> Anyway, i don't see the value of adding it to GLib, as undo
>> frameworks are only an abstraction, and users end-up doing the
>> painfull job of implementing undo commands for every
On Mon, 21 Jun 2010 12:57:44 +0200 ecyrbe wrote:
> Easy Undo/Redo framework are usually based on Inheritance...
I don't have any statistics, but surely, there are many frameworks
based on inheritance, and many others that aren't. The question is
more: Does it make sense to base it on inheritance
I do agree that there should be no UI related thing on Undo/Redo
Implementation, if any.
Easy Undo/Redo framework are usually based on Inheritance... but in GLib,
inheritance is not an easy way for Gtk users (in plain C GObject anyway).
Using vala or another object oriented binding to Gtk, it could
On Wed, 2010-06-16 at 22:01 +0200, Holger Berndt wrote:
> Some time ago, there was some discussion about a generic undo stack in
> GTK+ [1]. The talk back then didn't result in more concrete API
> discussion. As undo/redo is part of the GTK+ Roadmap [2], I now shot
> ahead and created an undo propo
Hi Martin,
On Do, 17.06.2010 07:13, Martin Nordholts wrote:
>I'm also sceptical. There are too many different ways to implement Undo.
>The generic solution would only represent one way, which doesn't make it
>generic enough IMO.
The question is: Do they really NEED it in different ways, or are
On 06/16/2010 10:49 PM, Tristan Van Berkom wrote:
For instance, consider '+' = do and '-' = undo:
4 7
| /
3 5
|/
2
|
1
Would translate to: +1 --> +2 --> +3 --> +4 --> -4 --> -3 --> +5 --> +7
It would be inconvenient to perform operations on that representation of
a tr
On Wed, Jun 16, 2010 at 4:28 PM, Martin Nordholts wrote:
> On 06/16/2010 10:01 PM, Holger Berndt wrote:
>>
>> Some time ago, there was some discussion about a generic undo stack in
>> GTK+ [1]. The talk back then didn't result in more concrete API
>> discussion. As undo/redo is part of the GTK+ Ro
On 06/16/2010 10:01 PM, Holger Berndt wrote:
Some time ago, there was some discussion about a generic undo stack in
GTK+ [1]. The talk back then didn't result in more concrete API
discussion. As undo/redo is part of the GTK+ Roadmap [2], I now shot
ahead and created an undo proposal page [3] for
On Wed, Jun 16, 2010 at 10:01:39PM +0200, Holger Berndt wrote:
> Some time ago, there was some discussion about a generic undo stack in
> GTK+ [1]. The talk back then didn't result in more concrete API
> discussion. As undo/redo is part of the GTK+ Roadmap [2], I now shot
> ahead and created an und
Some time ago, there was some discussion about a generic undo stack in
GTK+ [1]. The talk back then didn't result in more concrete API
discussion. As undo/redo is part of the GTK+ Roadmap [2], I now shot
ahead and created an undo proposal page [3] for that. Comments are very
welcome.
Holger
[1] h
14 matches
Mail list logo
