Re: [JPP-Devel] undo/redo changes.. Re: Issues after adding loads of features as WKT
Hi all, I joy the discussion late but I want to share my point of view. >We can well keep our concept. One of the OJ specialities is that user can keep however many layers editable at the same time. There are also limits to this "specialty". It often happens to users to digit features on one layer and than I discovered that that layer was not the right one, especially if the project has several layers (saved or not) loaded. Kosmo folows a sort of "bottle neck" philosophy: users are obliged to follow a fixed procedure to digit/modify layers, but this way avoids frequent errors which are typical in newbies of OJ (and even advanced users) > 'undoable delete' will always cost memory, except we'll dump it to disk (let's not) .. but i am thinking from a user perspective here and users tend to not to want to know but expect certain comforts like undoability.. todays workflow tends to be more experimental. trial, error, undo... Yes, I understand comfort point of view. But the cost could be worse than the benefits: if OJ freezes, because of an 'undoable delete' on a layer (which requires a lot of memory consumption) the risk is that users have to kill the application and they loose the all un-saved modifications made on several layer on the project (as there is no warning to save modification like in Kosmo, users have a tendency in OpenJUMP to modify/digit/analyze and than to save every now and than or at the end of the work Going back to other software, Kosmo offers the choice to save layers either to memory or to the disk, and to choose in which folder to save temp data. This could be an alternative, if possible: 1) 'undoable delete' if layer is saved on disk (as a list of layers like layerA_temp01, layerA_temp02 etc for a layerA loaded on OJ) 2) if layer is loaded on memory 'undoable delete' is not possible regards Peppe 2013/1/21 Stefan Steiniger > I am not sure, but we could also decide to make large transactions not > undoable (i.e. decide on a buffer size limit?). Like some delete delete > operations on Microsoft will delete large files always permanently? Of > course, one would need to warn the user. > > my 2 cents > stefan > > Am 21.01.13 18:46, schrieb Michaël Michaud: > > Hi, > >> 'undoable delete' will always cost memory, except we'll dump it to disk > (let's not) .. but i am thinking from a user perspective here and users > tend to not to want to know but expect certain comforts like undoability.. > todays workflow tends to be more experimental. trial, error, undo... > > Everybody like to be comfortable, but let's have a look at the bill. > > Loading everything in memory is already limiting OpenJUMP'susability. > > We must pay attention not to make it worst. > >> so i'd kind of heavily vote to have it undoable. > > I'm OK for an experimental feature after 1.6 release. > > (but not convinced I'll buy it) > > > > If we really identify two real usage, one way to work-around > > could be to implement a "delete selected layer (undoable)" AND a > > "delete selected layer (definitive)"... > >>> (and in case we want to persist > >>> deleted layers, we have to make sure that performance is not a > bottleneck). > >> what about fixing it and seeing how it goes? taking it step by step. i > am not sure everybody is working extra huge layers all the time. > > let's see after 1.6 release. It seems that it can take some time before > > we find and implement the best solution. > > > > Michaël > >> and even if the feedback says that the user experienced got worse, we > could go back to the current state all the time. OR we simply decide to > make the undo queue memory dependent (like start trimming if we reach 90% > or have a configurable count of undo steps e.g. 10 by default). > >> > >> ..ede > >> > >> > -- > >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > >> MVPs and experts. SALE $99.99 this month only -- learn more at: > >> http://p.sf.net/sfu/learnmore_122412 > >> ___ > >> Jump-pilot-devel mailing list > >> Jump-pilot-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > >> > >> > > > > > > > -- > > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > > MVPs and experts. SALE $99.99 this month only -- learn more at: > > http://p.sf.net/sfu/learnmore_122412 > > ___ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-p
Re: [JPP-Devel] undo/redo changes.. Re: Issues after adding loads of features as WKT
On 22.01.2013 14:29, Giuseppe Aruta wrote: > Hi all, > I joy the discussion late but I want to share my point of view. > >>We can well keep our concept. One of the OJ specialities is that user can >>keep however many layers editable at the same time. > There are also limits to this "specialty". It often happens to users to digit > features on one layer and than I discovered that that layer was not the right > one, especially if the project has several layers (saved or not) loaded. > Kosmo folows a sort of "bottle neck" philosophy: users are obliged to follow > a fixed procedure to digit/modify layers, but this way avoids frequent errors > which are typical in newbies of OJ (and even advanced users) i'd rather modify the tools to respect layer selection (only selected layers are effectively edited), like it is common in desktop publishing, than force a specific flow on users. >> 'undoable delete' will always cost memory, except we'll dump it to disk >> (let's not) .. but i am thinking from a user perspective here and users tend >> to not to want to know but expect certain comforts like undoability.. todays >> workflow tends to be more experimental. trial, error, undo... > Yes, I understand comfort point of view. But the cost could be worse than the > benefits: if OJ freezes, because of an 'undoable delete' on a layer (which > requires a lot of memory consumption) the risk is that users have to kill the > application and they loose the all un-saved modifications made on several > layer on the project (as there is no warning to save modification like in > Kosmo, users have a tendency in OpenJUMP to modify/digit/analyze and than to > save every now and than or at the end of the work that's a misconception.. 'undoable delete layer' would not need additional memory, but rather not release already reserved and then still needed memory. and as said: this can be released once the undo queue is shortened or emptied completely. > Going back to other software, Kosmo offers the choice to save layers either > to memory or to the disk, and to choose in which folder to save temp data. > This could be an alternative, if possible: > 1) 'undoable delete' if layer is saved on disk (as a list of layers like > layerA_temp01, layerA_temp02 etc for a layerA loaded on OJ) > 2) if layer is loaded on memory 'undoable delete' is not possible sounds messy. too much explaining to the users, why undoable now, why not then. as i see it, there is either a complete undoable support or none. however there might be preference switches to modify the default behaviour (for experts with boxes with limited RAM). generally, if the layer has been edited manually, they should be an OK/Cancel dialog. ..ede > regards > > Peppe > > 2013/1/21 Stefan Steiniger mailto:sst...@geo.uzh.ch>> > > I am not sure, but we could also decide to make large transactions not > undoable (i.e. decide on a buffer size limit?). Like some delete delete > operations on Microsoft will delete large files always permanently? Of > course, one would need to warn the user. > > my 2 cents > stefan > > Am 21.01.13 18:46, schrieb Michaël Michaud: > > Hi, > >> 'undoable delete' will always cost memory, except we'll dump it to > disk (let's not) .. but i am thinking from a user perspective here and users > tend to not to want to know but expect certain comforts like undoability.. > todays workflow tends to be more experimental. trial, error, undo... > > Everybody like to be comfortable, but let's have a look at the bill. > > Loading everything in memory is already limiting OpenJUMP'susability. > > We must pay attention not to make it worst. > >> so i'd kind of heavily vote to have it undoable. > > I'm OK for an experimental feature after 1.6 release. > > (but not convinced I'll buy it) > > > > If we really identify two real usage, one way to work-around > > could be to implement a "delete selected layer (undoable)" AND a > > "delete selected layer (definitive)"... > >>> (and in case we want to persist > >>> deleted layers, we have to make sure that performance is not a > bottleneck). > >> what about fixing it and seeing how it goes? taking it step by step. i > am not sure everybody is working extra huge layers all the time. > > let's see after 1.6 release. It seems that it can take some time before > > we find and implement the best solution. > > > > Michaël > >> and even if the feedback says that the user experienced got worse, we > could go back to the current state all the time. OR we simply decide to make > the undo queue memory dependent (like start trimming if we reach 90% or have > a configurable count of undo steps e.g. 10 by default). > >> > >> ..ede > >> > >> > -- > >> Master Visual Studio, SharePoint, SQL, ASP.NET
