Re: [Qgis-developer] standardisation of the editing map tools: modify behaviour of press-pan-release tools
Hey Denis, There is a 4th option of course and that is a key modifier for override to do click-click. I was planning on doing that a while ago when I thought about the same thing. So adding something like shift+click to enabled click-click mode. Not sure if that is better but there is not a good way to change this kind of thing. - Nathan On Thu, Sep 25, 2014 at 3:46 PM, Denis Rouzaud denis.rouz...@gmail.com wrote: Hi all, I'll try to summarize. *QEP*: I don't mind doing one, but I think it's a bit early since we are still discussing. *Problematic*: Drag'n'drop map tools prevent from enhancing CAD tools in QGIS. For this, it is *required *to add click-click to all map tools. *Other softwares:* CAD softwares use click-click actions while design and GIS (Mapinfo, what about ESRI?) use drag'n'drop. New users or even current users might be afraid of such a change. *Pros of methods:* Advantages of click-clik: * allow other actions to be done in the movement * allow cancelling the action (this was not pointed out yet) Advantages of drag'n'drop * More intuitive (for non-CAD users, which I believe is the majority) I see *3 (and a half) solutions* (thanks to Matthias for pointing some): 1.* Replace current* drag'n'drop to click-click + simplest solution to maintain - need time for new users to get used to this 2.* Enable both* click-clik and drag'n'drop: a short click will free the node/feature while a long click (*) will allow drag'n'drop. + both solutions are here - might be confusing for a standard user to make a short click and have a node moving without knowing what to do (although escape would cancel the thing) 3. Provide both behaviours and *choose which one to use in options* (e.g. enable CAD behaviour for map tools). + both solutions are here - behaviour not coherent along the different installations half solution: click-click in map tools, allow drag'n'drop in the main identify tool. Like *Microstation*. - this works only for move features (i.e. not feasible for rotate and node tools) Please comment these solutions, to see if there's a consensus. I'll start and vote for 1. ;) Cheers, Denis * The determination of what should be done is made on the distance in pixels from the press position to the release position. If it's small it is considered as a short. Time might also get into consideration: if you long-click but don't move it could be considered as cancel. On 24.09.2014 10:56, Denis Rouzaud wrote: Hi all, There is somehow an inconsistency in the behaviour of the current editing map tools. Some, like add features, uses the left click to trigger the action. Others, like the node tool or move feature use press-pan-release mouse events: * mouse press to select the node/feature * mouse mouse to move it * mouse release sets the position. I would propose to standardise this and for the latter tools propose the following work flow: * left click enables the move * left click again to validate at position * or right click to cancel Why changing this? If you look at CAD software, they also use the proposed approach. And there's a reason for doing so, which is valid for QGIS too. We are looking at improving the CAD tools in QGIS. In this area, I recommend trying the fantastic CADinput plugin made by Olivier Dalang. The plugin works on top of any map tool and enables CAD tools for each of them. The problem with the press-pan-release map tools is that you can't truly interact while you are actually in the action of the map tool (holding the click): * you can't click anymore and this prevents from using intermediate points (you have to use the tool several times and repeat the operation as many times as intermediate points you need) * it is not really user friendly to have to press keys while holing the click This is why, changing the map tools behaviour is requested if we want to go further with CAD tools in QGIS. Regarding the future of CAD tools in QGIS, I am quite sure the plugin proposed by Olivier would be a good way to go for QGIS, but it still might be a bit early to integrate it in core. The idea is rather first to extend the API and propose ready to use methods, so it will be easy to implement your preferred solution in a plugin. But first, we need to standardise the map tools. So, the bottom line, any objection to changing the behaviour of: * edit node tool * move feature * rotate feature * move label * rotate label * any other press-pan-release map tool that I am not aware of ??? Best wishes, Denis ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory Layers - some proposals
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 nirvn.a...@gmail.com 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 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory Layers - some proposals
On 25/09/2014 4:03 pm, Nathan Woodrow madman...@gmail.com wrote: What about a icon in the legend to note that it it's not going to be saved? I like that idea - I'd imagine if memory/scratch layers always displayed the RAM icon in the legend and not the layer symbol then it would be a permanent reminder to the user that they are a different type of layer... Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory Layers - some proposals
Possibly although that'd clutter that space. Renaming Memory Layers to Temporary Layers would also give a good clue. That said, I must say I quite enjoy using the memory layer saver, I'd be sad to see this function not making it into core. Martin raised an important issue re format. What about saving memory layer data as GeoJSON within the qgis project file? That's a solution that is compatible with the project file's xml format. Thoughts on that? On 25 Sep 2014 13:03, Nathan Woodrow madman...@gmail.com wrote: 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 nirvn.a...@gmail.com 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 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
Re: [Qgis-developer] standardisation of the editing map tools: modify behaviour of press-pan-release tools
On 25.09.2014 08:02, Nathan Woodrow wrote: Hey Denis, There is a 4th option of course and that is a key modifier for override to do click-click. I was planning on doing that a while ago when I thought about the same thing. So adding something like shift+click to enabled click-click mode. Not sure if that is better but there is not a good way to change this kind of thing. - Nathan Or we use the modifier for the drag'n'drop, if people like to keep a button mouse pressed, they don't mind using one more key... just joking! Modifiers are a pain when you use the tools a lot. Anyway, if we do this, this can be combined with the options (solution 3) Standard mode: simple click: drag'ndrop, shift: click-click CAD mode: simple click: click-clcik, shift: drag'n'drop On Thu, Sep 25, 2014 at 3:46 PM, Denis Rouzaud denis.rouz...@gmail.com mailto:denis.rouz...@gmail.com wrote: Hi all, I'll try to summarize. *QEP*: I don't mind doing one, but I think it's a bit early since we are still discussing. *Problematic*: Drag'n'drop map tools prevent from enhancing CAD tools in QGIS. For this, it is *required *to add click-click to all map tools. *Other softwares:* CAD softwares use click-click actions while design and GIS (Mapinfo, what about ESRI?) use drag'n'drop. New users or even current users might be afraid of such a change. *Pros of methods:* Advantages of click-clik: * allow other actions to be done in the movement * allow cancelling the action (this was not pointed out yet) Advantages of drag'n'drop * More intuitive (for non-CAD users, which I believe is the majority) I see *3 (and a half) solutions* (thanks to Matthias for pointing some): 1.*Replace current* drag'n'drop to click-click + simplest solution to maintain - need time for new users to get used to this 2.*Enable both* click-clik and drag'n'drop: a short click will free the node/feature while a long click (*) will allow drag'n'drop. + both solutions are here - might be confusing for a standard user to make a short click and have a node moving without knowing what to do (although escape would cancel the thing) 3. Provide both behaviours and *choose which one to use in options* (e.g. enable CAD behaviour for map tools). + both solutions are here - behaviour not coherent along the different installations half solution: click-click in map tools, allow drag'n'drop in the main identify tool. Like *Microstation*. - this works only for move features (i.e. not feasible for rotate and node tools) Please comment these solutions, to see if there's a consensus. I'll start and vote for 1. ;) Cheers, Denis * The determination of what should be done is made on the distance in pixels from the press position to the release position. If it's small it is considered as a short. Time might also get into consideration: if you long-click but don't move it could be considered as cancel. On 24.09.2014 10:56, Denis Rouzaud wrote: Hi all, There is somehow an inconsistency in the behaviour of the current editing map tools. Some, like add features, uses the left click to trigger the action. Others, like the node tool or move feature use press-pan-release mouse events: * mouse press to select the node/feature * mouse mouse to move it * mouse release sets the position. I would propose to standardise this and for the latter tools propose the following work flow: * left click enables the move * left click again to validate at position * or right click to cancel Why changing this? If you look at CAD software, they also use the proposed approach. And there's a reason for doing so, which is valid for QGIS too. We are looking at improving the CAD tools in QGIS. In this area, I recommend trying the fantastic CADinput plugin made by Olivier Dalang. The plugin works on top of any map tool and enables CAD tools for each of them. The problem with the press-pan-release map tools is that you can't truly interact while you are actually in the action of the map tool (holding the click): * you can't click anymore and this prevents from using intermediate points (you have to use the tool several times and repeat the operation as many times as intermediate points you need) * it is not really user friendly to have to press keys while holing the click This is why, changing the map tools behaviour is requested if we want to go further with CAD tools in QGIS. Regarding the future of CAD tools in QGIS, I am quite sure the plugin proposed by Olivier would be a good way to go for QGIS, but it still might be a bit early to integrate it in core. The idea is rather first to extend the API and propose ready to use methods, so it will be easy
Re: [Qgis-developer] Memory Layers - some proposals
On 25/09/2014 4:27 pm, Mathieu Pellerin nirvn.a...@gmail.com wrote: Possibly although that'd clutter that space. Not really- it could be handled in the same way as the editing icon is at the moment. That doesn't take up any extra room as it replaces the style swatch. That said, I must say I quite enjoy using the memory layer saver, I'd be sad to see this function not making it into core. Martin raised an important issue re format. What about saving memory layer data as GeoJSON within the qgis project file? That's a solution that is compatible with the project file's xml format. I think the issue is more with compatibility with other programs. That's why a zip/archive style project file which stores memory layers in an existing standard format (eg geojson) was suggested. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory Layers - some proposals
Personally I like the memory layer and use it frequently. The icon idea sounds good to me. Ideally it could be a RAM icon combined with the type of geometry (Point, Line, Polygon). I also like the idea of having the memory layer as a core feature - but then there should be a user-friendly way to copy/inherit attribute columns from an already existing layer. For the long run it would be very useful being able to save the memory layer to any OGR format. Apparently it is already possible to load a memory layer to the databases supported by the DB manager (Postgis, SpatiaLite). I think the memory layer would be very well suited for certain analysis tasks where users don't want to fuss around with Shapefiles. They want to test something and only if the result is satisfying they would save the result. I would also envisage the Processing framework to make use of the memory layer for certain tasks. Andreas Am 25.09.2014 06:17, schrieb Nyall Dawson: On 25/09/2014 4:03 pm, Nathan Woodrow madman...@gmail.com mailto:madman...@gmail.com wrote: What about a icon in the legend to note that it it's not going to be saved? I like that idea - I'd imagine if memory/scratch layers always displayed the RAM icon in the legend and not the layer symbol then it would be a permanent reminder to the user that they are a different type of layer... Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory Layers - some proposals
I guess the main issue with replacing the style swatch is we loose that for a ram icon that will be there all the time so you can't see the style set on the layer. Personally I do prefer the name Temporary rather then Memory. - Nathan On Thu, Sep 25, 2014 at 4:38 PM, Nyall Dawson nyall.daw...@gmail.com wrote: On 25/09/2014 4:27 pm, Mathieu Pellerin nirvn.a...@gmail.com wrote: Possibly although that'd clutter that space. Not really- it could be handled in the same way as the editing icon is at the moment. That doesn't take up any extra room as it replaces the style swatch. That said, I must say I quite enjoy using the memory layer saver, I'd be sad to see this function not making it into core. Martin raised an important issue re format. What about saving memory layer data as GeoJSON within the qgis project file? That's a solution that is compatible with the project file's xml format. I think the issue is more with compatibility with other programs. That's why a zip/archive style project file which stores memory layers in an existing standard format (eg geojson) was suggested. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] standardisation of the editing map tools: modify behaviour of press-pan-release tools
Hi, I think we should be open-minded towards Denis ideas and not categorically reject any changes in curent behaviour. Enabling the CAD mode enables a lot of possibilities compared to the current mode. I am not a CAD expert either, but I am often impressed about how efficiently my Autocad colleagues can edit/construct data. Therefore I would support the option to switch between Graphics/CAD mode. There could even be a button in the editing toolbar switching between the two modes, though I would expect that people would like to stay in one mode most of the time, once they get used to either mode. From Denis proposals listed below I would prefer option 3 (Provide both behaviours and choose which one to use in options). The above suggested switch mode button or a modifier key could be added as well, though I see it as convenience and not absolutely necessary at the start. Andreas Am 25.09.2014 05:46, schrieb Denis Rouzaud: Hi all, I'll try to summarize. *QEP*: I don't mind doing one, but I think it's a bit early since we are still discussing. *Problematic*: Drag'n'drop map tools prevent from enhancing CAD tools in QGIS. For this, it is *required *to add click-click to all map tools. *Other softwares:* CAD softwares use click-click actions while design and GIS (Mapinfo, what about ESRI?) use drag'n'drop. New users or even current users might be afraid of such a change. *Pros of methods:* Advantages of click-clik: * allow other actions to be done in the movement * allow cancelling the action (this was not pointed out yet) Advantages of drag'n'drop * More intuitive (for non-CAD users, which I believe is the majority) I see *3 (and a half) solutions* (thanks to Matthias for pointing some): 1.*Replace current* drag'n'drop to click-click + simplest solution to maintain - need time for new users to get used to this 2.*Enable both* click-clik and drag'n'drop: a short click will free the node/feature while a long click (*) will allow drag'n'drop. + both solutions are here - might be confusing for a standard user to make a short click and have a node moving without knowing what to do (although escape would cancel the thing) 3. Provide both behaviours and *choose which one to use in options* (e.g. enable CAD behaviour for map tools). + both solutions are here - behaviour not coherent along the different installations half solution: click-click in map tools, allow drag'n'drop in the main identify tool. Like *Microstation*. - this works only for move features (i.e. not feasible for rotate and node tools) Please comment these solutions, to see if there's a consensus. I'll start and vote for 1. ;) Cheers, Denis * The determination of what should be done is made on the distance in pixels from the press position to the release position. If it's small it is considered as a short. Time might also get into consideration: if you long-click but don't move it could be considered as cancel. On 24.09.2014 10:56, Denis Rouzaud wrote: Hi all, There is somehow an inconsistency in the behaviour of the current editing map tools. Some, like add features, uses the left click to trigger the action. Others, like the node tool or move feature use press-pan-release mouse events: * mouse press to select the node/feature * mouse mouse to move it * mouse release sets the position. I would propose to standardise this and for the latter tools propose the following work flow: * left click enables the move * left click again to validate at position * or right click to cancel Why changing this? If you look at CAD software, they also use the proposed approach. And there's a reason for doing so, which is valid for QGIS too. We are looking at improving the CAD tools in QGIS. In this area, I recommend trying the fantastic CADinput plugin made by Olivier Dalang. The plugin works on top of any map tool and enables CAD tools for each of them. The problem with the press-pan-release map tools is that you can't truly interact while you are actually in the action of the map tool (holding the click): * you can't click anymore and this prevents from using intermediate points (you have to use the tool several times and repeat the operation as many times as intermediate points you need) * it is not really user friendly to have to press keys while holing the click This is why, changing the map tools behaviour is requested if we want to go further with CAD tools in QGIS. Regarding the future of CAD tools in QGIS, I am quite sure the plugin proposed by Olivier would be a good way to go for QGIS, but it still might be a bit early to integrate it in core. The idea is rather first to extend the API and propose ready to use methods, so it will be easy to implement your preferred solution in a plugin. But first, we need to standardise the map tools. So, the bottom line, any objection to changing the behaviour of: * edit node tool *
Re: [Qgis-developer] Memory Layers - some proposals
As a name, I like Scratch layer or Temporary layer. I see that people can confuse Memory with permant storage. Andreas Am 25.09.2014 06:41, schrieb Nathan Woodrow: I guess the main issue with replacing the style swatch is we loose that for a ram icon that will be there all the time so you can't see the style set on the layer. Personally I do prefer the name Temporary rather then Memory. - Nathan On Thu, Sep 25, 2014 at 4:38 PM, Nyall Dawson nyall.daw...@gmail.com mailto:nyall.daw...@gmail.com wrote: On 25/09/2014 4:27 pm, Mathieu Pellerin nirvn.a...@gmail.com mailto:nirvn.a...@gmail.com wrote: Possibly although that'd clutter that space. Not really- it could be handled in the same way as the editing icon is at the moment. That doesn't take up any extra room as it replaces the style swatch. That said, I must say I quite enjoy using the memory layer saver, I'd be sad to see this function not making it into core. Martin raised an important issue re format. What about saving memory layer data as GeoJSON within the qgis project file? That's a solution that is compatible with the project file's xml format. I think the issue is more with compatibility with other programs. That's why a zip/archive style project file which stores memory layers in an existing standard format (eg geojson) was suggested. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory Layers - some proposals
Nyall, I don't think there's a compatibility issue with memory layers. Those are by their nature QGIS-dependant data, the same way ArcGIS can't simply open a .qgs project file, a .qml layer properties file, etc. One of the nice feature of memory layers (and its sister plugin memory layer saver) is the fact that they are embedded within .qgs project files. It should stay that way (which using GeoJSON within the XML structure of an .qgs file would do). Transforming the .qgs project file into a zip container would probably be a huge project driven by greater needs than memory layers :) Re Temporary Layers, I find it slightly better than Scratch Layer for non native English speakers (i.e. more to the point in simple English :) ). M On Thu, Sep 25, 2014 at 1:38 PM, Nyall Dawson nyall.daw...@gmail.com wrote: On 25/09/2014 4:27 pm, Mathieu Pellerin nirvn.a...@gmail.com wrote: Possibly although that'd clutter that space. Not really- it could be handled in the same way as the editing icon is at the moment. That doesn't take up any extra room as it replaces the style swatch. That said, I must say I quite enjoy using the memory layer saver, I'd be sad to see this function not making it into core. Martin raised an important issue re format. What about saving memory layer data as GeoJSON within the qgis project file? That's a solution that is compatible with the project file's xml format. I think the issue is more with compatibility with other programs. That's why a zip/archive style project file which stores memory layers in an existing standard format (eg geojson) was suggested. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Keeping line breaks in QGIS expressions
Hi, It would be wonderful if someone could work on preserving formatting and add comment support for the expressions in the QGIS 2.7 dev phase. I can try and help to find some funding, if a dev is interested in implementing this and can provide a quote. Andreas Am 24.09.2014 19:44, schrieb Matthias Kuhn: Hi Martin On 24.09.2014 21:42, Martin Dobias wrote: I would propose the following: - QgsExpression::dump() should always recreate the string from the data structure - save the original expression string and return it with QgsExpression::expression() - unless the expression is modified by other means, which will set the saved string to a NULL string in which case QgsExpression::expression() will be forwarded to QgsExpression::dump() This logic makes sense to me. For the third item I would just suggest that any modification would immediately regenerate the saved expression string using dump() - so there would be no forwarding from expression() to dump(). Or created on first request and then buffered for subsequent use. This might save some CPU cycles and memory once in a while :-) Cheers, Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] processing translation
What about to translate the processing plugin ? There is no doubt that processing is more powerfull/modular than the old ftools, but users who don't speek english find that the processing module and its toolbox is less accessible than former fTools menu. Content to translate will be : - the names, groups - add a description property (with some illustrations would be the best) shown in an new information panel on node selection. What do you think about this ? Arnaud ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory Layers - some proposals
On 25/09/2014 4:51 pm, Mathieu Pellerin nirvn.a...@gmail.com wrote: Re Temporary Layers, I find it slightly better than Scratch Layer for non native English speakers (i.e. more to the point in simple English :) ). What happens when we port the memory layer saver to core though? Temporary layers are no longer temporary ;) we need a name which indicates that they should not be used for important data, but ultimately they will be permanent layers... Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory Layers - some proposals
I agree. It seem me a silly question. If an user choose a memory layer it know that is a memory layer :) So it is not a permanent dataset. I like the memory layer because they as really useful for temporary elaborations and quickly tests. lso another question is. If an user choose the memory layer it crunch the ram resources. And after it begin to ask for more resources because its million records daataset is not well used with the memory layer. However if like to put a memory layer persistent. Why dont return to old question. Change the project save from XML to a spatialite ? Storing the project in a spatialite will allow easily to host also in the spatialte the datasets if this is the like of the qgis community. Also the spatialite start to support also the raster with rasterlite extension. So tomorrow you should do also a memory raster layer. Regards, Andrea. 2014-09-25 9:19 GMT+02:00 Matthias Kuhn matthias.k...@gmx.ch: Hi, Please excuse my ignorance, but Why would you want a memory (as in RAM) layer when you want permanent data? For portability reasons? That's fine, but then we should offer a possibility to support portability support for a real geo-format (with spatial index and all the goodies). To stuff it into the project file there can be support from a plugin, but I would not vote for adding this to core. To me it seems that the current demand for this comes mainly from wrong expectations created by the name (and people subsequently loosing data). And we can fix the name. For the portability issue, I'd rather go the longer way but get it right. Regards Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] processing translation
+1 Bernhard Am 25.09.2014 08:56, schrieb Arnaud Morvan: What about to translate the processing plugin ? There is no doubt that processing is more powerfull/modular than the old ftools, but users who don't speek english find that the processing module and its toolbox is less accessible than former fTools menu. Content to translate will be : - the names, groups - add a description property (with some illustrations would be the best) shown in an new information panel on node selection. What do you think about this ? Arnaud ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer __ Information from ESET Mail Security, version of virus signature database 10461 (20140925) __ The message was checked by ESET Mail Security. http://www.eset.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] processing translation
Hi, this topic already was discussed recently, see this thread http://osgeo-org.1560.x6.nabble.com/Processing-i18n-support-td5155677.html In short, Processing has i18n support, but some code parts still miss it. We are working on this, but patches are welcome. 2014-09-25 9:56 GMT+03:00 Arnaud Morvan arnaud.mor...@camptocamp.com: What about to translate the processing plugin ? There is no doubt that processing is more powerfull/modular than the old ftools, but users who don't speek english find that the processing module and its toolbox is less accessible than former fTools menu. Content to translate will be : - the names, groups - add a description property (with some illustrations would be the best) shown in an new information panel on node selection. What do you think about this ? Arnaud ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] standardisation of the editing map tools: modify behaviour of press-pan-release tools
* rotate feature * move label * rotate label * any other press-pan-release map tool that I am not aware of ??? Best wishes, Denis __ Information from ESET Mail Security, version of virus signature database 10461 (20140925) __ The message was checked by ESET Mail Security. http://www.eset.com ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory Layers - some proposals
On Thu, Sep 25, 2014 at 09:02:07AM +0700, 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. Same happened to me many many times. It's also reported in this ticket: http://hub.qgis.org/issues/8387 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). +1, saving should NOT be reported as a success w/out the user being made aware of the issue and asked for action (discard/save_as_format). --strk; () ASCII ribbon campaign -- Keep it simple ! /\ http://strk.keybit.net/rants/ascii_mails.txt ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory Layers - some proposals
Hey all, I think the best course of action here is to hold off until after 2.6 so we can review this thing as a whole solution rather then rushing it in last minute and then moving the target later. IMO we could in the future use sqlite in memory datastore for the memory provider which gives us a lot more options and range. Changing the format of the project file to something that isn't xml is a interesting idea however it's not something that should be rushed into without consideration so I think that is a very different topic. - Nathan On Thu, Sep 25, 2014 at 5:19 PM, Matthias Kuhn matthias.k...@gmx.ch wrote: Hi, Please excuse my ignorance, but Why would you want a memory (as in RAM) layer when you want permanent data? For portability reasons? That's fine, but then we should offer a possibility to support portability support for a real geo-format (with spatial index and all the goodies). To stuff it into the project file there can be support from a plugin, but I would not vote for adding this to core. To me it seems that the current demand for this comes mainly from wrong expectations created by the name (and people subsequently loosing data). And we can fix the name. For the portability issue, I'd rather go the longer way but get it right. Regards Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory Layers - some proposals
On Thu, Sep 25, 2014 at 04:03:04PM +1000, Nathan Woodrow wrote: What about a icon in the legend to note that it it's not going to be saved? I like the icon idea, but would still additionally have a warning at save time. I see those temporary layers like drafts. That is, something you do not want to loose but is not either fully existent on its final form. You'd have to save them to have a final product (that can be shared), but you should not be loosing them (why would you ?). In order to avoid keeping such draft layers dangling, the user should be asked what to do whenever they are removed from a project. They could be discarded or saved_as_permanent. Just my 2c of UX :) --strk; () ASCII ribbon campaign -- Keep it simple ! /\ http://strk.keybit.net/rants/ascii_mails.txt ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] crash with undo command
How to verify if the signal « feature added » is emitted from an add feature tool? De : qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-boun...@lists.osgeo.org] De la part de Nejia Envoyé : mercredi 24 septembre 2014 16:09 À : qgis-developer@lists.osgeo.org Objet : [Qgis-developer] crash with undo command Hi, I have a plugin that allows to change an attribute value of added feature to the selected value of a combo-box. I change the attribute when the signal featureAdded is emmited (ie. Before the endEditCommand of add feature is called) so in this undo command we have in the order: 1- QgsVectorLayerUndoCommandAddFeature 2- QgsVectorLayerUndoCommandChangeAttribute If we undo add feature command it must call undo() on all child commands in reverse order, but when I debug in QGIS it do it in the order not in reverse order ie. It call: 1- QgsVectorLayerUndoCommandAddFeature::undo() 2- QgsVectorLayerUndoCommandChangeAttribute::undo() Thats why Qgis crash when I undo add feature command An explanation for this? Is there any way to knew if the signal feature added is emitted when a new feature is added not from commitChanges(), redoEditCommand() and undoEditCommand()? Thank you Nejia ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Memory Layers - some proposals
Aren't there two different possibilities in which such layers can be used: * As a scratch layer for the user, which he may want to save in the end * As a means for plugins to show information to the user In the first scenario, the user may actually want to save the information because he realized in the process of drawing it, that it's valuable to him (if he would have known from the beginning, he could have started with a permanent layer type). In this case it would be nice to make the user aware of the risk of loosing data and offer him a simple way to save it (to an OGR supported format). In the second scenario, the information may be completely reproducible by the plugin or the information drawn by the user intercepted by the plugin and redirected to suitable places. In such a scenario a Do you want to permanently save? dialog would not be appropriate. And therefore there should be a possibility to disable it. On the other hand, I also tend to use my /tmp folder on my machine for data I use to play around for the next couple of minutes but that I am completely aware of that it can be lost anytime (and I don't want my computer to ask me: Hey, you have saved that download to /tmp and I'm going to delete it now, is that ok for you?). So I tend to disagree with Sandros why would you want to loose the data? and answer it with because it's intermediate, volatile and/or temporary. All in all: there are two scenarios, one with manual operation, one with plugins. The second one needs to be controlled by python, the first one is about awareness. This awareness can be achieved by one or more of the following * Icons * Message bar (e.g. when starting to digitize You are digitizing on a temporary layer. Do you want to convert it to a permanent layer? Click here.) * Message box when removing the layer from the canvas/closing the app There is unsaved information, you will loose it unless you donate 5$ to the QGIS project. Click here Or did I get this wrong? Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Python: viewing properties for an ComposerItem programmatically?
On Wed, Sep 24, 2014 at 4:32 PM, Luca Manganelli luc...@gmail.com wrote: [CUT ALL] # these commands doesn't show the item properties composerView.selectedItemChanged.emit(composerMap) # doesn't work composer.showItemOptions ( composerMap ) # doesn't work I found a way to do this programmatically. The two functions above do not work, so to fix it I have to do in this way: # The composer window (you have to find the right composerView object from iface.activeComposers() ) composer = composerView.composerWindow() # Find the Command History Dock from ccomposer main Window commandDock = composer.findChildren ( QDockWidget, CommandDock )[0] # Find the QUndoView widget undoView = commandDock.findChildren ( QUndoView )[0] # Select the first element in command history (with text empty) index = undoView.model().index (0, 0) undoView.setCurrentIndex ( index ) # Select the second (but this may vary) element (the map object) index = undoView.model().index (1, 0) undoView.setCurrentIndex ( index ) TA-DAH! Now it shows the item properties of the MAP ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Python: viewing properties for an ComposerItem programmatically?
On 25 September 2014 00:32, Luca Manganelli luc...@gmail.com wrote: Hi, (i'm using qgis 2.4) how can view the object properties of a composer item I added with my plugin? I tried with showItemOptions(...) but it doesn't work in this example, I add a composerMap, but I cannot find a way on how to automatically view the properties in the Composer Window: # open the composer that I created composition = composerView.composition() What about composition.setSelectedItem( composerMap ) ? That should work... Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Module dependencies
About the python dependencies, I propose to share a list of dependencies of the plugin, where everyone can add and propose those necessary to its plugin. This list could then be taken into consideration during the release of the new version of QGIS, which may already contain them. For example, I (will) need of : qtreactor twisted zope It is impossible to add them to QGIS ? Regards Roberto ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QGIS hackfest Linuxhotel News
Hi, I have some not so good news for all who arrive on wednesday and before thursday late afternoon. I was just informed by the linuxhotel, that they will have another big event on thursday, 2nd october. They have given priority to this event, because that's what they make money with (we only pay a very reduced price). For us it means, we only have one smaller room (maybe for 15 people) available on thursday until maybe 7pm and all others have to split up to several other rooms in the linuxhotel. We will find a solution anyway, there is internet everywhere, but I wanted to inform you, so you are not disappointed, if we are not able to work all together in one room until thursday evening. Whish you all a save journey to Essen! Regards Otto ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Fwd: Re: Memory Layers - some proposals
Forwarded to list Forwarded Message Subject:Re: [Qgis-developer] Memory Layers - some proposals Date: Thu, 25 Sep 2014 06:04:19 -0800 From: Gary Sherman gsher...@geoapt.com Organization: GeoApt LLC To: Matthias Kuhn matthias.k...@gmx.ch CC: gsher...@geoapt.com On 9/25/14 1:10 AM, Matthias Kuhn wrote: Aren't there two different possibilities in which such layers can be used: * As a scratch layer for the user, which he may want to save in the end * As a means for plugins to show information to the user In the first scenario, the user may actually want to save the information because he realized in the process of drawing it, that it's valuable to him (if he would have known from the beginning, he could have started with a permanent layer type). In this case it would be nice to make the user aware of the risk of loosing data and offer him a simple way to save it (to an OGR supported format). In the second scenario, the information may be completely reproducible by the plugin or the information drawn by the user intercepted by the plugin and redirected to suitable places. In such a scenario a Do you want to permanently save? dialog would not be appropriate. And therefore there should be a possibility to disable it. I agree---I have a plugin that uses memory layers to display information abstracted from a database (with no QGIS data provider). This functionality is essential and should not be changed, rather additional features added to support interactive use through the UI. On the other hand, I also tend to use my /tmp folder on my machine for data I use to play around for the next couple of minutes but that I am completely aware of that it can be lost anytime (and I don't want my computer to ask me: Hey, you have saved that download to /tmp and I'm going to delete it now, is that ok for you?). So I tend to disagree with Sandros why would you want to loose the data? and answer it with because it's intermediate, volatile and/or temporary. All in all: there are two scenarios, one with manual operation, one with plugins. The second one needs to be controlled by python, the first one is about awareness. This awareness can be achieved by one or more of the following * Icons * Message bar (e.g. when starting to digitize You are digitizing on a temporary layer. Do you want to convert it to a permanent layer? Click here.) * Message box when removing the layer from the canvas/closing the app There is unsaved information, you will loose it unless you donate 5$ to the QGIS project. Click here Or did I get this wrong? Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Gary Sherman Founder, QGIS Project Consulting: geoapt.com Publishing: locatepress.com We work virtually anywhere =-=-=-=-=-=-=-=-=-=-=-=-=-=-= ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Re: Memory Layers - some proposals
Since Processing has been mentioned a couple of times in the thread, just some clarification: - Processing can create memory layers, but only for native algorithms (that is, not from SAGA, GRASS, etc). The option is available in the button aside the text box where the destination path is entered - All Processing layers are temporary, unless a path is entered, and they are saved to a temp folder which is cleaned when the user closes QGIS - There are warnings in the Processing documentation about not creating a project with temp layers and to always enter a path if the layer is not an intermediate result. Otherwise it will be lost. I think that i can improve that and add a warning to pop up when the project is saved if it includes temp layers, capturing the corresponding signal and checking that there are no layers that are saved in the Processing temp path. Would that be too intrusive? Hope this helps 2014-09-25 17:15 GMT+02:00 Matthias Kuhn matthias.k...@gmx.ch: Forwarded to list Forwarded Message Subject: Re: [Qgis-developer] Memory Layers - some proposals Date: Thu, 25 Sep 2014 06:04:19 -0800 From: Gary Sherman gsher...@geoapt.com gsher...@geoapt.com Organization: GeoApt LLC To: Matthias Kuhn matthias.k...@gmx.ch matthias.k...@gmx.ch CC: gsher...@geoapt.com On 9/25/14 1:10 AM, Matthias Kuhn wrote: Aren't there two different possibilities in which such layers can be used: * As a scratch layer for the user, which he may want to save in the end * As a means for plugins to show information to the user In the first scenario, the user may actually want to save the information because he realized in the process of drawing it, that it's valuable to him (if he would have known from the beginning, he could have started with a permanent layer type). In this case it would be nice to make the user aware of the risk of loosing data and offer him a simple way to save it (to an OGR supported format). In the second scenario, the information may be completely reproducible by the plugin or the information drawn by the user intercepted by the plugin and redirected to suitable places. In such a scenario a Do you want to permanently save? dialog would not be appropriate. And therefore there should be a possibility to disable it. I agree---I have a plugin that uses memory layers to display information abstracted from a database (with no QGIS data provider). This functionality is essential and should not be changed, rather additional features added to support interactive use through the UI. On the other hand, I also tend to use my /tmp folder on my machine for data I use to play around for the next couple of minutes but that I am completely aware of that it can be lost anytime (and I don't want my computer to ask me: Hey, you have saved that download to /tmp and I'm going to delete it now, is that ok for you?). So I tend to disagree with Sandros why would you want to loose the data? and answer it with because it's intermediate, volatile and/or temporary. All in all: there are two scenarios, one with manual operation, one with plugins. The second one needs to be controlled by python, the first one is about awareness. This awareness can be achieved by one or more of the following * Icons * Message bar (e.g. when starting to digitize You are digitizing on a temporary layer. Do you want to convert it to a permanent layer? Click here.) * Message box when removing the layer from the canvas/closing the app There is unsaved information, you will loose it unless you donate 5$ to the QGIS project. Click here Or did I get this wrong? Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Gary Sherman Founder, QGIS Project Consulting: geoapt.com Publishing: locatepress.com We work virtually anywhere =-=-=-=-=-=-=-=-=-=-=-=-=-=-= ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
