I've been trying to follow this conversation, and I thought I'd add my 2 cents:

MM wrote: "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."

I agree with this statement 100%.

I think we should either (1) make layer deletion by writing large
layers to disk, or (2) allow the user choose between a delete layer
command that is undoable or not undoable.

It also sounds like power users might benefit from having an interface
exposed that allows management of the undo queue.

Landon

On Tue, Jan 22, 2013 at 6:02 AM,  <edgar.sol...@web.de> wrote:
> 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 <sst...@geo.uzh.ch <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 <http://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 
>> <mailto:Jump-pilot-devel@lists.sourceforge.net>
>>     >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>     >>
>>     >>
>>     >
>>     >
>>     > 
>> ------------------------------------------------------------------------------
>>     > Master Visual Studio, SharePoint, SQL, ASP.NET <http://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 
>> <mailto:Jump-pilot-devel@lists.sourceforge.net>
>>     > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>     >
>>
>>     
>> ------------------------------------------------------------------------------
>>     Master Visual Studio, SharePoint, SQL, ASP.NET <http://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 
>> <mailto: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. ON SALE this month only -- learn more at:
>> http://p.sf.net/sfu/learnnow-d2d
>>
>>
>>
>> _______________________________________________
>> 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. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d
> _______________________________________________
> 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. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Reply via email to