<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 25.09.2014 04:02, Mathieu Pellerin
wrote:<br>
</div>
<blockquote
cite="mid:CAC_qv=q+Hbe=iLtBsxZsZh8M6b4n=uCV_7bTsh7e3EscDX5e_A@mail.gmail.com"
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
cite="mid:CAC_qv=q+Hbe=iLtBsxZsZh8M6b4n=uCV_7bTsh7e3EscDX5e_A@mail.gmail.com"
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 moz-do-not-send="true"
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 class=""><br>
On Thu, Sep 25, 2014 at 3:31 AM, Nyall Dawson <<a
moz-do-not-send="true"
href="mailto:nyall.dawson@gmail.com">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 class=""><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 moz-do-not-send="true"
href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
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 class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Qgis-developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
<br>
</body>
</html>