<p dir="ltr">Thoughts:<br>
- 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)<br>
- 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<br>
- 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</p>
<div class="gmail_quote">On 25 Sep 2014 12:15, "Denis Rouzaud" <<a href="mailto:denis.rouzaud@gmail.com">denis.rouzaud@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <br>
    <div>On 25.09.2014 04:02, Mathieu Pellerin
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>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:<br>
                </div>
                1. Open his/her project<br>
                2. Copies one polygon from a large dataset and pastes is
                as a new memory layer (very useful feature introduced in
                QGIS 2.x)<br>
              </div>
              3. Styles the memory layer, and saves the project<br>
            </div>
            4. The next day, when he/she re-opens the project, the
            polygon is gone<br>
            <br>
          </div>
          Throughout the above mentioned workflow, there was never _any_
          indication that the pasted memory layer would not be saved
          when saving the project. <br>
          <br>
        </div>
        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). <br>
      </div>
    </blockquote>
    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".<br>
    <br>
    <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Math<br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Thu, Sep 25, 2014 at 4:07 AM, Martin
          Dobias <span dir="ltr"><<a href="mailto:wonder.sk@gmail.com" target="_blank">wonder.sk@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nyall<br>
            <span><br>
              On Thu, Sep 25, 2014 at 3:31 AM, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>>
              wrote:<br>
              > Hi all,<br>
              ><br>
              > The recent discussion around memory layers in another
              thread has started me<br>
              > thinking about the best way to expose them more
              readily to users.<br>
              ><br>
              > As such, I've opened a pull request which ports Borys
              Jurgiel's "New Memory<br>
              > Layer" plugin to core (PR #1591). Hopefully this can
              be merged for 2.6. It's<br>
              > more or less a direct port - I've left it without the
              ability to specify<br>
              > fields at creation time as I believe that field
              creation would indicate that<br>
              > we are encouraging users to store real data in these
              layers, which is<br>
              > something we should avoid.<br>
              <br>
            </span>Cool - from time to time it is handy to make a memory
            layer for some<br>
            temporary data and having to use a plugin / python console
            for the<br>
            creation is suboptimal...<br>
            <span><br>
              > What I'm thinking though is that we should rename
              "memory layers" within the<br>
              > UI. The name suggests that they are remembered, and
              conveys more of a<br>
              > permanent feel.<br>
              ><br>
              > I think that for 2.6 we could rename them to
              "temporary scratch layers", and<br>
              > then for >2.6 (after we port the memory layer
              saving plugin/decide on a<br>
              > suitable format for saving them) drop the "
              temporary" part of this name. So<br>
              > they'll be just "scratch layers".<br>
              <br>
            </span>I like the name "scratch layer" - and I wouldn't mind
            having it from<br>
            2.6 even without the "temporary" part although there is no
            saving for<br>
            it. (Saving is still a bit controversial for me as we would<br>
            inadvertently create another vector file format - unless we
            would ask<br>
            user to save the layer data into one of OGR supported
            formats or<br>
            spatialite DB.)<br>
            <br>
            Cheers<br>
            Martin<br>
            _______________________________________________<br>
            Qgis-developer mailing list<br>
            <a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
            <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Qgis-developer mailing list
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
    </blockquote>
    <br>
  </div>

</blockquote></div>