Hi,
Jennifer Stratton writes:
> I'm a total amateur and am always entering something I didn't mean to
> or deleting the wrong thing. I need an undo button that will undo the
> last function completed. Would love it
Alas, there is none right now, and AFAIK none in the work
I'm a total amateur and am always entering something I didn't mean to or
deleting the wrong thing. I need an undo button that will undo the last
function completed. Would love it
thanks
___
gnu
Point conceded. I think I'll review my approach and switch to a singular
Undo/Redo history. I'll try to update my application as soon as possible.
Akintayo
On 3/28/07, Josh Sled <[EMAIL PROTECTED]> wrote:
>
> On Wed, March 28, 2007 2:51 pm, Derek Atkins wrote:
> > Se
> > level.
>
> I'll add my "me too" here. With splits it gets particularly
> complicated. One of the things I most want to undo in GnuCash
> happens when I'm editing a complicated split and as part of
> that process I change (accidently or not) the acco
On Wed, March 28, 2007 2:51 pm, Derek Atkins wrote:
> See, I disagree. I consider a gnucash Book (set of accounts) to be the
> same
> as a gnumeric (or Excel, or OOo) spreadsheet/set-of-workbooks. Each
> account
> is akin is a single workbook, but it's really the set of accounts (and
> other anci
Quoting akintayo holder <[EMAIL PROTECTED]>:
>> Does any other app handle undo this way? Why should gnucash be different?
>
>> What does gnumeric do when you undo a change not on the local workbook
>> page/tab? We should do that.
> OpenOffice would jump to the
>Does any other app handle undo this way? Why should gnucash be different?
>What does gnumeric do when you undo a change not on the local workbook
>page/tab? We should do that.
OpenOffice would jump to the scope of the last change, its Undos are global
within the workbook/file. As does
On Wed, March 28, 2007 5:37 am, Derek Atkins wrote:
> But I ALSO think that there needs to be an application-wide UNDO
> list, for operations that don't have a locality.. E.g. imports,
> accounts/budget/business object creation, etc.
>
> This is clearly a VERY big problem, but
u put anything else in there... ;)
> Because of that, is why I suggested that undo has a window of it's own,
Does any other app handle undo this way? Why should gnucash be different?
What does gnumeric do when you undo a change not on the local workbook
page/tab? We should do that.
a customer, and then loose
data, I'd certainly like to be able to replay that.
If they were written to the log then undo for them would be easy.
> I DO understand the want for locality of operation. At some level it
> DOES make sense to have "register"-based undo contex
I fully agree with Derek. The main reason someone would want to undo
an Import is that the Import was messed-up somehow - wrong account
created; wrong currency; wrong file imported, etc.
It does not make sense to undo the steps of an import one by one,
because those steps were not performed in
wed a series of steps and then
>> clicked "Done" or "Finish" or "Import" and gnucash did some magic.
>
> Except that the "magic" is what must be undone, not what you clicked,
> and it is decidedly less atomic.
Not from most user's p
t the user to save their
>> file before an import and simply reopen that save in the case
>> that it goes horribly wrong. Again, maybe it's just me... as for
>> not tying undo to an account, I wholeheartedly agree.
>
> It's extremely unreasonable when we fi
Quoting Jeff Carneal <[EMAIL PROTECTED]>:
> Just to address the point of undo'ing an import...
>
> Maybe it is just me, but as a user, I have no expectation whatsoever
> of being able to undo something as large in scope as an import. I
> think that's partly be
Ariel <[EMAIL PROTECTED]> writes:
> Each time something is written to the log, it's also written to undo - in
> fact a large part of undo is already written: the log already records a
> before and after, all you need to do is put in a gui to see each entry in
> the
On Tue, 27 Mar 2007, Nathan Buchanan wrote:
> On 3/27/07, Ariel <[EMAIL PROTECTED]> wrote:
>> Let the user cherry pick which transaction to undo - it doesn't have to
>> be in strict reverse order.
> This sounds a bit complicated for the average user, if we do de
On 3/27/07, Ariel <[EMAIL PROTECTED]> wrote:
Let the user cherry pick which transaction to undo - it doesn't have to
> be in strict reverse order.
This sounds a bit complicated for the average user, if we do decide to let
the user cherry pick, we need to have a very clear UI/
Yes, that first one is a problem and one that I have not personally
experienced - so I am guessing a bit. But if you create the entry in one
view then commit [guessing about this part] and move it to another view.
Then I would place the Undo entry in the first view's list, as you haven'
On 3/27/07, akintayo holder <[EMAIL PROTECTED]> wrote:
>
> In the scenario given, It would not be possible to undo from account B as
> the state of the transaction would've been modified elsewhere.
Modified elsewhere, yes, but it's still the same user. I don't see
On Tue, 27 Mar 2007, akintayo holder wrote:
> In the scenario given, It would not be possible to undo from account B as
> the state of the transaction would've been modified elsewhere.
>
> I think it is the lesser of all evils, as a global list may involved undoing
> a tr
In the scenario given, It would not be possible to undo from account B as
the state of the transaction would've been modified elsewhere.
I think it is the lesser of all evils, as a global list may involved undoing
a transaction that isn't visible or switching to a different account
ticularly
complicated. One of the things I most want to undo in GnuCash
happens when I'm editing a complicated split and as part of
that process I change (accidently or not) the account that I'm
using to view the split at the time. The whole thing suddenly
dissappears and I'm left
akintayo holder wrote:
>
> Hi,
> I agree with your points, except for the single GList. I think Undo needs
> to be local in context. In other words if I Undo from a given register, it
> should only undo the operations made from that view even if they do not just
> impact thi
Hi,
I agree with your points, except for the single GList. I think Undo needs
to be local in context. In other words if I Undo from a given register, it
should only undo the operations made from that view even if they do not just
impact this view. So it must be possible to associate an undo with
Um, but which account do you associate it with?
When you Undo don't you want to undo from the UI, not on a per-account basis?
And what about something like a QIF Import, which really should be an
atomic do/undo object? Where would you store that info?
Keep in mind that Undo does NOT need
The reason I like Undo being associated with an account is the simple way in
which to enforce context. So an Undo could not impact a hidden account in an
unexpected way. Since accounting transactions affect at least two accounts,
grouping by account was more of an interface concession.
On 3/23
I'm not convinced that the Undo feature belongs to an account. There
are other (non-account-based) operations that should be undoable,
such as changes to the PriceDB, direct Transfer Dialog entries, or
even changes made via File -> Import. I think the Undo log should
be part of the
Hi,
Its seems that with respect to multi-user transactions and Undo, the first
step would be to enforce this rule; A transaction cannot be Undone if the
state of the record does not match the state after the original transaction
had completed. For example, you can only Undo an account creation if
Ariel <[EMAIL PROTECTED]> writes:
> It seems to me that an undo in a multi-user environment should be exactly
> equal to the user deleting (or changing, etc) the transaction manually
> back to what it was.
As pointed out, this isn't completely true. In a multi-user envi
On 3/20/07, Ariel <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 20 Mar 2007, akintayo holder wrote:
>
> > I would like to restrict the scope of the undo to single-user use cases.
> > Is this a reasonable project ?
>
> It seems to me that an undo in a multi-user envi
On Tue, 20 Mar 2007, akintayo holder wrote:
> I would like to restrict the scope of the undo to single-user use cases.
> Is this a reasonable project ?
It seems to me that an undo in a multi-user environment should be exactly
equal to the user deleting (or changing, etc) the trans
"akintayo holder" <[EMAIL PROTECTED]> writes:
> Hi,
> I plan on applying for a SoC project working on GNUCash. I have looked at
> the proposed ideas, and I want to write the undo/redo feature. Given the
> time period and the other issues like multi-user concurre
Hi,
I plan on applying for a SoC project working on GNUCash. I have looked at
the proposed ideas, and I want to write the undo/redo feature. Given the
time period and the other issues like multi-user concurrent access, I would
like to restrict the scope of the undo to single-user use cases. Is
On Mon, 2007-03-12 at 00:26 -0400, Jerry Quinn wrote:
>
> I had talked to my dad a bit about features that he would need to use gnucash
> in their business setting and audit trail was at the top of the list. With
> an
> audit trail, you really can't have an undo that is in
Mark Johnson wrote:
> Wasn't there some suggestion that an audit trail would be useful in a
> distributed environment a while back? It sounds like it would have a
> great deal in common with the undo.
I had talked to my dad a bit about features that he would need to use gnu
Wasn't there some suggestion that an audit trail would be useful in a
distributed environment a while back? It sounds like it would have a
great deal in common with the undo.
Mark
Peter Selinger wrote:
>Here is how I think undo can be done in a distributed environment. I
>thi
Here is how I think undo can be done in a distributed environment. I
think the undo history should be kept locally in the client (no global
list in the server). The server, however, can keep track of who the
last user (or last several users) were that edited a given
transaction, purely for
I dont think you can depend on a single global log.. It would require
extending the QofBackend API to do something like that.
So, what DOES "undo" mean in a multi-user environment? That's a hard
problem to solve, I think.
-derek
Karl Chen <[EMAIL PROTECTED]> writes:
&
>>>>> On 2007-02-23 06:58 PST, Derek Atkins writes:
Derek> Are you offering to code this?
Well, I'll put it on my to-do list - that's easy - but it's a long
list so no promises on when I'll get to this if I'm the only one
interested in coding it :
Good point; I didn't know about this concurrent editing process.
If there is a single global log I guess one could have the ability
to undo other's transactions after confirmation, though this would
be tricky and for now I would say only allow undo if no one else
has committed in th
On Fri, Feb 23, 2007 at 09:58:35AM -0500, Derek Atkins wrote:
> Are you offering to code this?
>
> Yes, Undo would be cool. I'd also like to see larger-size undo atoms,
> like "undo import".
AOL that!
A
>
> -derek
>
> Quoting Karl Chen <[EMAIL PRO
On Fri, Feb 23, 2007 at 12:53:41PM -0400, Peter Selinger wrote:
> As I understand it, in a large GnuCash installation, multiple users
> could access the same backend database. The lock-edit-commit mechanism
> prevents conflicts.
>
> So what should be the default behavior of U2
As I understand it, in a large GnuCash installation, multiple users
could access the same backend database. The lock-edit-commit mechanism
prevents conflicts.
So what should be the default behavior of U2 and U3 (undo or redo) if,
for example, the transaction has meanwhile been edited by another
Are you offering to code this?
Yes, Undo would be cool. I'd also like to see larger-size undo atoms,
like "undo import".
-derek
Quoting Karl Chen <[EMAIL PROTECTED]>:
>
> Hi Gnucash developers,
>
> First, excellent work - Gnucash is awesome. I especially
Hi Gnucash developers,
First, excellent work - Gnucash is awesome. I especially
appreciate the book data format which has allowed me to make batch
changes externally.
I have a wishlist request: Undo functionality. I think Undo
(various levels described below) would add a LOT to usability
mespec))param->param_setfcn;
if(date_setter != NULL) { date_setter(ent, cli_date); }
(That took me ages to understand but thanks to Derek's patience, I got it
eventually!)
Example:
http://code.neil.williamsleesmill.me.uk/cashutil/group__UNDO.html#ga2
All data modification should occur
to be needed later. I was
planning to differentiate a MODIFY from a CREATE but I think that was just a
hangover from tying the undo idea to events and dirty instances.
Okay. Well, this is why it's good to talk things over before we write
code. ;)
IMHO this is a simpler API :)
I would t
e a MODIFY from a CREATE but I think that was just a
hangover from tying the undo idea to events and dirty instances.
> I would think a much better API would be:
> QofOperation qof_book_start_operation(QofBook* book, const char
> *op_name); void qof_book_end_operation(QofOperation oper);
ons, which is only used
by the undo/redo subsystem.
At least that's my take on it all.
-derek
Neil Williams <[EMAIL PROTECTED]> writes:
> On Wednesday 10 August 2005 8:49 am, Derek Atkins wrote:
>> Neil Williams <[EMAIL PROTECTED]> writes:
>> > For now, I
ink the right way to go about it is not a list of changed
> entities, but a list of events/operations.
The existing events, I feel, are largely inappropriate for undo. What a user
would consider a single operation can consist of many engine events. So in
the CLI I'm experimenting with a
On Wednesday 10 August 2005 2:34 pm, David Hampton wrote:
> On Wed, 2005-08-10 at 12:44 +0100, Neil Williams wrote:
> > In order to do redo properly, the undo operation needs to add itself to
> > the list as an event that includes the state of affected parameter values
> > be
On Wed, 2005-08-10 at 12:44 +0100, Neil Williams wrote:
> In order to do redo properly, the undo operation needs to add itself to the
> list as an event that includes the state of affected parameter values before
> the user clicked undo because the *current* state of any entity
event.
Undo List
-> List of affected entities (just the type and GUID) per event.
-> list of affected parameter values before the event.
In order to do redo properly, the undo operation needs to add itself to the
list as an event that includes the state of affected para
Neil Williams <[EMAIL PROTECTED]> writes:
> For now, I'm afraid, I have to step back and keep to what I can realistically
> hope to complete.
Oh, that's fine. I honestly didn't expect Undo in the near term.
Besides, we don't quite have SQL done, yet, so it&
Benoit Grégoire <[EMAIL PROTECTED]> writes:
> We should rip them out in the head branch...
Well, not until we have full SQL support.. ;)
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://w
On Tuesday 09 August 2005 9:10 am, Derek Atkins wrote:
> Neil Williams <[EMAIL PROTECTED]> writes:
> > the undo list itself
> > could be stored in a similar manner to the current logs if that was
> > useful. Depends on the SQL backend - if we're all using immedi
> Yes, the list itself would be part of the QofBook struct and
> > accessed via an API exposed via qofbook.h - the undo list itself
> > could be stored in a similar manner to the current logs if that was
> > useful. Depends on the SQL backend - if we're all using immediate
> &
Neil Williams <[EMAIL PROTECTED]> writes:
> On Monday 08 August 2005 9:47 am, Derek Atkins wrote:
>> I presume by "retained" you mean "in core" and not "in storage"...
>
> Yes, the list itself would be part of the QofBook struct and
> acc
On Monday 08 August 2005 9:47 am, Derek Atkins wrote:
> Neil Williams <[EMAIL PROTECTED]> writes:
> > If the undo list is retained within the book and only referenced from
> > that book, this would provide sufficient segregation.
>
> I presume by "retained" y
Neil Williams <[EMAIL PROTECTED]> writes:
> David Hampton wrote:
> | I can see multiple undo lists within one application working, but it
> | will need to be well documented.
>
> If the undo list is retained within the book and only referenced from
> that book, this
display data from two books in the same main
> window of gnucash. The file (book) name is part of the window title so
> it will be clear with a glance which data file is being edited.
Then each book will maintain it's own undo list, that's not a problem at all.
The second main
On Sun, 2005-08-07 at 22:14 +0100, Neil Williams wrote:
> Or are you talking about multiple *main* windows of GnuCash?
Yes. Gnucash 1.8 has this capability today and it is retained in g2.
You will not be able to display data from two books in the same main
window of gnucash. The file (book) nam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Hampton wrote:
| I can see multiple undo lists within one application working, but it
| will need to be well documented.
If the undo list is retained within the book and only referenced from
that book, this would provide sufficient segregation
On Sun, 2005-08-07 at 17:46 +0100, Neil Williams wrote:
> On Sunday 07 August 2005 4:58 pm, you wrote:
> > On Sun, 2005-08-07 at 00:04 +0100, Neil Williams wrote:
> > > A list would be more flexible - undo lists have to be sequential so a
> > > generic qof_undo() would
On Sunday 07 August 2005 4:58 pm, you wrote:
> On Sun, 2005-08-07 at 00:04 +0100, Neil Williams wrote:
> > A list would be more flexible - undo lists have to be sequential so a
> > generic qof_undo() would need a single GList of all changes and rolling
> > such a list in st
On Sun, 2005-08-07 at 00:04 +0100, Neil Williams wrote:
> A list would be more flexible - undo lists have to be sequential so a generic
> qof_undo() would need a single GList of all changes and rolling such a list
> in strict sequential order back and forth (i.e. a redo as well as
har *param_name);
>
> (QOF can't undo / redo anything unless the data is accessible as a
> parameter with a QofAccessFunc *and* a QofSetterFunc so passing the value
> as a string is pointless. The combination of param_name and the object
> e_type from the instance do the rest.)
&g
On Saturday 06 August 2005 9:36 pm, Derek Atkins wrote:
> If QOF supported a native "undo" that would be REALLY COOL.. In fact,
> supported a "list" of undo operations would be even cooler!
>
> :)
(well, I did ask!)
My ideas on how that might be best achieved
If QOF supported a native "undo" that would be REALLY COOL.. In fact,
supported a "list" of undo operations would be even cooler!
:)
-derek
Neil Williams <[EMAIL PROTECTED]> writes:
> Is it necessary to offer an undo at the edit stage or should edits take place
dirty). Once GnuCash v2 XML is replaced, this would only apply to QSF
data.
Is it necessary to offer an undo at the edit stage or should edits take place
immediately (as in the GUI)?
Undo isn't a trivial addition so I wanted to check it was worthwhile - I can
see how to implement it for QSF bu
70 matches
Mail list logo
