Thoughts: - I don't think warning should be occurring when creating a memory layer (that is when pasting as new layer, when adding the result of a processing algorithm as memory layer, or creating a blank memory layer) - I don't think the user should be able to disable the warning message (which imo should be a dialog with saving shortcuts), the resulting data loss is too critical; it's like opening a project with missing layers, qgis doesn't (and shouldn't) allow for this dialog to be skipped - IMO best to have: a/ a message bar when saving project while in an ongoing session, and a missing layer-like warning dialog when closing project On 25 Sep 2014 12:15, "Denis Rouzaud" <denis.rouz...@gmail.com> wrote:
> > On 25.09.2014 04:02, Mathieu Pellerin wrote: > > Regarding the saving aspect of it, IMO it needs to be worked out. I've > had a couple of users over here already reporting "data loss" with the > following scenario: > 1. Open his/her project > 2. Copies one polygon from a large dataset and pastes is as a new memory > layer (very useful feature introduced in QGIS 2.x) > 3. Styles the memory layer, and saves the project > 4. The next day, when he/she re-opens the project, the polygon is gone > > Throughout the above mentioned workflow, there was never _any_ indication > that the pasted memory layer would not be saved when saving the project. > > If QGIS further ease access to memory layers via incorporating the new > memory layer function into the core (which I hope its done :) ), and decide > against saving across project session, then there must be a UX to deal with > that, instead of silently killing the data of the memory layer(s). One way > forward would be to have a warning upon closing a project that has > non-saveable memory layers to warn the users. That warning should offer for > users to save the memory layers onto a proper format (possibly like the > missing layer dialog, with a list of all the memory layers and an input to > add the saved file location/name). > > I would be in favor of a warning when first create a memory layer. The > warning would say you can't save them except from using a plugin. And, > there would be a checkbox "do not display this warning anymore". > > > > > Math > > On Thu, Sep 25, 2014 at 4:07 AM, Martin Dobias <wonder...@gmail.com> > wrote: > >> Hi Nyall >> >> On Thu, Sep 25, 2014 at 3:31 AM, Nyall Dawson <nyall.daw...@gmail.com> >> wrote: >> > Hi all, >> > >> > The recent discussion around memory layers in another thread has >> started me >> > thinking about the best way to expose them more readily to users. >> > >> > As such, I've opened a pull request which ports Borys Jurgiel's "New >> Memory >> > Layer" plugin to core (PR #1591). Hopefully this can be merged for 2.6. >> It's >> > more or less a direct port - I've left it without the ability to specify >> > fields at creation time as I believe that field creation would indicate >> that >> > we are encouraging users to store real data in these layers, which is >> > something we should avoid. >> >> Cool - from time to time it is handy to make a memory layer for some >> temporary data and having to use a plugin / python console for the >> creation is suboptimal... >> >> > What I'm thinking though is that we should rename "memory layers" >> within the >> > UI. The name suggests that they are remembered, and conveys more of a >> > permanent feel. >> > >> > I think that for 2.6 we could rename them to "temporary scratch >> layers", and >> > then for >2.6 (after we port the memory layer saving plugin/decide on a >> > suitable format for saving them) drop the " temporary" part of this >> name. So >> > they'll be just "scratch layers". >> >> I like the name "scratch layer" - and I wouldn't mind having it from >> 2.6 even without the "temporary" part although there is no saving for >> it. (Saving is still a bit controversial for me as we would >> inadvertently create another vector file format - unless we would ask >> user to save the layer data into one of OGR supported formats or >> spatialite DB.) >> >> Cheers >> Martin >> _______________________________________________ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > > > _______________________________________________ > Qgis-developer mailing > listQgis-developer@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/qgis-developer > > >
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer