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: References: From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" Date: Wed, 9 Aug 2017 06:27:56 -0800 Message-ID: Subject: Re: [geda-user] [dev] undo code in pcb/pcb-rnd; libuundo To: geda-user AT delorie DOT com Content-Type: text/plain; charset="UTF-8" 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 Precedence: bulk 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, 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