What about a icon in the legend to note that it it's not going to be saved?
- Nathan On Thu, Sep 25, 2014 at 3:57 PM, Mathieu Pellerin <[email protected]> wrote: > 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" <[email protected]> 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 <[email protected]> >> wrote: >> >>> Hi Nyall >>> >>> On Thu, Sep 25, 2014 at 3:31 AM, Nyall Dawson <[email protected]> >>> 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 >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >> >> >> >> _______________________________________________ >> Qgis-developer mailing >> [email protected]http://lists.osgeo.org/mailman/listinfo/qgis-developer >> >> >> > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
