X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
	bh=NlB2VYxebJKCDdRMTBpEUcJDp0x9+sBnOlRJDU09uyE=;
	b=ON6/CFo+K5NSS3PnWEyCFVdKQ1qpv9zPBG7/A7HYPqLMibHMzIApJaWrT3iAL2ThHS
	ZY2nRA1FP4sj04FmAJseReOeOP9VLiIzxiiCxmem3puzUe31BCl/LitrqOPNR4foiH13
	7K1eFUhuzXbgD0YJKjfBRiwx2SqEJ5iWdyXfbiyqyob86bznVVwur6G5VlXVgf6GFZK7
	Se40ZfcFnFpwNrY8xo1UoaiPZNQIc2ckXCgyr2/5kDE5p6lbABSSjf1ofK9B5uBqn+QY
	5sdlypJPm+e7Wuzk0czwppob8/r65D8o9+HvO1w7ffhlOGyE6bwA2EscHjP3T2DQtIDr
	1HSA==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=NlB2VYxebJKCDdRMTBpEUcJDp0x9+sBnOlRJDU09uyE=;
	b=dOzcCdJJLk5LVClwSppaeqD3riIAXvme6KNzszF25Tlj6LTuU1VuLUydPQLmzDzKWG
	CJGWmduBTS5KMOKxjgjNrW7TDimCNxnYKMzOZYCQFp3dwe6uc4pM55i/6WARN6aOUI8p
	DxsiPqpSd280B0wBmdKkDZs2tY988mTiyMjJzQMu3sQH9dTJWbP+C3DJRbNtbyk9OU9N
	QXRNbRPhr9Uq8IW3X7BiDH/vOv4GcebcNvmoWIvQnqmcuPbcRTPa+8PS7fFL8tWCP4Xb
	LRiiqyK4wLgom8fxKeJHQPMEHNiCZ43dNamyXt+LxttavmuMMtKLnaPpPYy4nGeCjMwB
	zpdw==
X-Gm-Message-State:	AHYfb5i7Imh6VfIKaXiNXImTu1uVbdO4bslYi/xN7JorY2iCMLGz2I3z
	zrDvj8opTEzQsXocfp/4Ep1Ibua7Gg==
X-Received:	by 10.55.98.137 with SMTP id w131mr10086914qkb.175.1502288877551;
	Wed, 09 Aug 2017 07:27:57 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<alpine.DEB.2.00.1708090719161.27212@igor2priv>
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1708090719161 DOT 27212 AT igor2priv>
From:	"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date:	Wed, 9 Aug 2017 06:27:56 -0800
Message-ID:	<CAC4O8c_x5OAs9ZCCgsdXBjgmusQvnoKQKhzgb2EtYkqpO9FGVA@mail.gmail.com>
Subject:	Re: [geda-user] [dev] undo code in pcb/pcb-rnd; libuundo
To:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

Nice, yet another tempting bit of pcb-rnd.  You inspire me I'm going
to make a db
version one day "when I get more time" hah ah :)

Britton

On Tue, Aug 8, 2017 at 9:45 PM,  <gedau AT igor2 DOT repo DOT hu> wrote:
> Hi all,
>
> I'm announcing a new minilib called libuundo that provides an
> application-agnostic undo mechanism.
>
> Doc: http://repo.hu/projects/libuundo/
>
> Source: svn://repo.hu/libuundo/trunk
>
> The rest of this mail is dealing with "why do I think we need that" and "how
> does it solve those problems".
>
>
> What's wrong with pcb-rnd's (and pcb's) current undo code?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> The current undo code (as of pcb-rnd r10665 and pcb 4.0.0) is too
> centralized. There is a list of undoable actions and associated undo-data
> declared in a central place (undo.c) in core. If any part of the code
> introduces a new undoable action, it's not just that that part of the code
> starts to depend on undo, but undo starts to depend on that part of the code
> too, because half of the implementation needs to go in undo.c. This does not
> help making the code modular.
>
> pcb-rnd's modularity also heavily depends on plugins. The above setup works
> only as long as new undoable actions are never programmed in plugins. This
> is a severe limitation on what code can be moved out from core to plugins
> and forces some new code to go in core instead of a plugin. Or alternatively
> forces plugins to implement some actions that are not undoable.
>
> (This does not affect the case when the plugin operation can be carried out
> exclusibely by calls to existing core function that already have undo
> capability. While this is a common pattern, we also have the other pattern
> where atomic undoable functionality need to be implemented in plugins)
>
> Another problem related to plugins is that undo.c has no privisions for
> unloadable plugins - that is, even if plugins could register undo items on
> the list, once the plugin is unloaded we'd have a broken undo list. With the
> current code it would be hard or impossible to detect this condition, so the
> only safe option would be to clear the whole undo history any time any
> plugin is unloaded.
>
> Two levels merged: undo.c contains both the high level "maintain a list of
> undo/redo items" and the low level "how to undo this specific operation"
> functions and their undo data. Because of the undo data, and because the
> undo list item is basically a big union of all those data, the two levels
> can not be separated, the high level needs to know the struct sizes of the
> low level. With the current way the data is stored (uniform-item-width array
> with realloc) this can not be fixed.
>
> Finally, reusability and license: undo.c is GPL2+, which is totally fine for
> pcb-rnd and pcb. Other applications could benefit from the high level part
> of the undo mechanism. It makes sense to copy the code from pcb-rnd (or pcb)
> or even make this high level part a reusable lib. However, GPL2+ might be
> too restrictive for applications licensed even under other FLOS software
> licenses. Because of the history of the project and potentially many authors
> of the file, it's probably not feasible to try to change the license.
>
>
> How does libuundo solve these
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> - reuse: libuundo is a very small library, independent of pcb-rnd or pcb;
> the API is small too, it's easy to reuse in random applications
>
> - license: libuundo is written from scratch, under LGPL2+, which is more
> liberal on library-reuse. The library is single-author so far, so it's easy
> to extend licensing (e.g. dual license if a project finds even LGPL too
> restrictive)
>
> - levels: libuundo implements the high level only, the low level is up to
> the caller; the API is baed on function callbacks provided by the
> application
>
> - variable item data size: each undo item can have a different sized
> user-data
>
> - modularity: because of the function callbacks, the low level undo code
> does not need to be centralized; plugins can implement their undo/redo
> without having to place code in core
>
> - plugin provisions: without libuundo implementing or using any plugin
> system, it provides an API that lets the application track which plugin
> registered with undo item. It is possible to check the undo list upon a
> plugin unload and do a selective clear.
>
>
> Plans in pcb-rnd regarding to libuundo
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I've already split the high level and low-level, except for the structs, in
> pcb-rnd.
>
> The next step will be to finish this split by removing most of the code for
> the high level and use libuundo instead.
>
> The old, centralized undo will become a single "operator" in the new system.
> Thus we will get the same functionality mostly working the same way, but
> already being able to register new undo operators even from plugins.
>
> Later on, the old, centralized undo will be slowly rewritten so that each
> undoable action will be a separate uundo operator placed in the module that
> is responsible for it. Eventually this will remove the centralized low level
> part.
>
> (Obviously I think mainline pcb and gschem could benefit from a similar
> move, but I am not making any suggestion)
>
> Regards,
>
> Igor2

- Raw text -