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 <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, 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-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-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