[Qgis-developer] Python support in project file

[Nathan Woodrow]

My comments are inline.

On Thu, May 31, 2012 at 10:49 AM, Giuseppe Sucameli
<sucameli at faunalia.it> wrote:
> Hi Martin,
>
> On Wed, May 30, 2012 at 11:37 PM, Martin Dobias <wonder.sk at gmail.com> wrote:
>> On Wed, May 23, 2012 at 9:24 PM, Giuseppe Sucameli
>> <brush.tyler at gmail.com> wrote:
>>> I've added a new tab "Project routines" to the project properties dialog
>>> where the user can define 3 different python routines:
>>
>> Maybe I would call it "macros" - everyone knows that term from Excel
>> and Word :-)
>
> +1 for macros
>
>> How the GUI is going to look like? Should the user enter the Python
>> code directly into some text edit widgets?
>
> yes, 3 text edit widget, one for each macro.
> The user has to write python code into them.

It would be good to be able to user something like:

import mymodule
mymodule.dosomething()

where mymodule is living in the same directory as the project.  This
would allow people to have say one Python module and reuse it over
more then one project if they live in the same directory.

>
>> How are you going to save the python code? In an external file or
>> embedded into XML file or even something else?
>
> I would save it into the project (embedded in the XML) until we will
> have a different way to pack project and related stuff together.
>
>>> I'm also adding a safe-check, it asks to the user if enabling them.
>>
>> Good, it would be good to have the check done in a way that does not
>> disturb the user with some popups - ideally something like a "yellow"
>> bar that currently browsers use when asking questions.
>
> I guess you're thinking to macros that make changes to the UI so
> it doesn't matter when the macro is executed,
> but IMHO this kind of macros should behave like a plugin connected
> to the projectRead() signal, so bound to a specific event and executed
> just after the event occurs.
>
> BTW one popup only would be needed, i.e. the project is loaded.
> If the user trust macros then they become active and ready to be
> executed.

Even if it is one popup that is still annoying IMO. Like Martin said,
try and think of a nicer way to do it rather then get in the face of
the user to much.  It is well known that users don't read dialogs and
most of the time just hit OK to get it out of there face, so you loose
the safety net.  Consider this approach by Office 2010:

http://peltiertech.com/images/2009-08/SecurityWarning2010.png

You can load the project, disable the marcos, tell the user nicely
that "there are macro in this project.  We have disabled them for your
safety.  What would like to do? Enable | Disable | Enable Always"

You get the idea.

Harder to implement but a nice user experience.

>
>>> 2. In a loaded project with trusted scripts (the user has trusted them)
>>> if the user changes their definitions from project properties dialog
>>> 2.a. should the new routines become active immediately when the user
>>> clicks on the apply button in the project properies dialog,
>>> 2.b. or should become active when he saves the project (the new
>>> projectSaved script has to be called just after the project is saved),
>>> 2.c. or should I keep the previous ones until the project is reloaded?
>>
>> I would vote for 2.a: in fact when the user applies changes done to
>> the python code, the python stuff could get reloaded, i.e. unload
>> (from old code) would be called, followed by load (from new code) - I
>> hope this will make the transition quite smooth.
>
> I would vote for 2.c instead, but now I understand we aren't so aligned
> as I thought :-)
>
> For you macros should be like a plugin embedded in the project file,
> so load and unload method, enabled asynchronously, ... (am I right?)
> I guess in that case it doesn't matter if the project saved macro exists,
> it could be just a iface signal the embedded-plugin load method
> connects itself to.
>
> For me they are project macros, hence strictly related to the project
> events, i.e not a plugin but slots (routines) connected to signals (project
> events), it has to be enabled synchronously and then a project saved
> macro makes sense.

Again this would be a case of giving the user a option to reload the
code or leave as is for now.  I would follow the same browser/office
style notification bar to let the user decide.  If they user ignores
it then so be it.


- Nathan