Long running processes should be run in backgroun

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Long running processes should be run in backgroun

Michael Kirk
Hi UX,

I’ve been using the “Vector > Analysis > Points in Polygon” tool lately. This one can be particularly long running when using larger data sets, sometimes many hours long. I really appreciate that the developers do this processing in a background thread. This allows me to continue to use QGIS, starting other non-dependent analysis, inspecting features, etc. while  analysis runs.

Compare this to, for example, the “Vector > Analysis > Line Intersections" tool. When I have a large set of intersections to compute, I can’t interact with QGIS until the job is done.

Are there any UX guidelines written on when something should be done in a background process vs on the main thread? Would a zero tolerance policy be too severe? E.g. “all processing must be done in thread separate from the main application.”

Michael
_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux
Reply | Threaded
Open this post in threaded view
|

Re: Long running processes should be run in backgroun

DelazJ
Hi,
Michael, there's an ongoing work at https://qgisgsoc2015.wordpress.com/project-plan/ that may be worth reading.
Cheers

Envoyé depuis mon HTC

----- Reply message -----
De : "Michael Kirk" <[hidden email]>
Pour : <[hidden email]>
Objet : [QGIS-UX] Long running processes should be run in backgroun
Date : ven., oct. 30, 2015 21:24

Hi UX,

I’ve been using the “Vector > Analysis > Points in Polygon” tool lately. This one can be particularly long running when using larger data sets, sometimes many hours long. I really appreciate that the developers do this processing in a background thread. This allows me to continue to use QGIS, starting other non-dependent analysis, inspecting features, etc. while  analysis runs.

Compare this to, for example, the “Vector > Analysis > Line Intersections" tool. When I have a large set of intersections to compute, I can’t interact with QGIS until the job is done.

Are there any UX guidelines written on when something should be done in a background process vs on the main thread? Would a zero tolerance policy be too severe? E.g. “all processing must be done in thread separate from the main application.”

Michael
_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux

_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux
Reply | Threaded
Open this post in threaded view
|

Re: Long running processes should be run in backgroun

DelazJ
In reply to this post by Michael Kirk
Hi,
Michael, there's an ongoing work at https://qgisgsoc2015.wordpress.com/project-plan/ that may be worth reading.
Cheers

Envoyé depuis mon HTC

----- Reply message -----
De : "Michael Kirk" <[hidden email]>
Pour : <[hidden email]>
Objet : [QGIS-UX] Long running processes should be run in backgroun
Date : ven., oct. 30, 2015 21:24

Hi UX,

I’ve been using the “Vector > Analysis > Points in Polygon” tool lately. This one can be particularly long running when using larger data sets, sometimes many hours long. I really appreciate that the developers do this processing in a background thread. This allows me to continue to use QGIS, starting other non-dependent analysis, inspecting features, etc. while  analysis runs.

Compare this to, for example, the “Vector > Analysis > Line Intersections" tool. When I have a large set of intersections to compute, I can’t interact with QGIS until the job is done.

Are there any UX guidelines written on when something should be done in a background process vs on the main thread? Would a zero tolerance policy be too severe? E.g. “all processing must be done in thread separate from the main application.”

Michael
_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux

_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux
Reply | Threaded
Open this post in threaded view
|

Re: Long running processes should be run in backgroun

DelazJ
In reply to this post by Michael Kirk
Hi,
Michael, there's an ongoing work at https://qgisgsoc2015.wordpress.com/project-plan/ that may be worth reading.
Cheers

Envoyé depuis mon HTC

----- Reply message -----
De : "Michael Kirk" <[hidden email]>
Pour : <[hidden email]>
Objet : [QGIS-UX] Long running processes should be run in backgroun
Date : ven., oct. 30, 2015 21:24

Hi UX,

I’ve been using the “Vector > Analysis > Points in Polygon” tool lately. This one can be particularly long running when using larger data sets, sometimes many hours long. I really appreciate that the developers do this processing in a background thread. This allows me to continue to use QGIS, starting other non-dependent analysis, inspecting features, etc. while  analysis runs.

Compare this to, for example, the “Vector > Analysis > Line Intersections" tool. When I have a large set of intersections to compute, I can’t interact with QGIS until the job is done.

Are there any UX guidelines written on when something should be done in a background process vs on the main thread? Would a zero tolerance policy be too severe? E.g. “all processing must be done in thread separate from the main application.”

Michael
_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux

_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux
Reply | Threaded
Open this post in threaded view
|

Re: Long running processes should be run in backgroun

DelazJ
In reply to this post by Michael Kirk
Hi,
Michael, there's an ongoing work at https://qgisgsoc2015.wordpress.com/project-plan/ that may be worth reading.
Cheers

Envoyé depuis mon HTC

----- Reply message -----
De : "Michael Kirk" <[hidden email]>
Pour : <[hidden email]>
Objet : [QGIS-UX] Long running processes should be run in backgroun
Date : ven., oct. 30, 2015 21:24

Hi UX,

I’ve been using the “Vector > Analysis > Points in Polygon” tool lately. This one can be particularly long running when using larger data sets, sometimes many hours long. I really appreciate that the developers do this processing in a background thread. This allows me to continue to use QGIS, starting other non-dependent analysis, inspecting features, etc. while  analysis runs.

Compare this to, for example, the “Vector > Analysis > Line Intersections" tool. When I have a large set of intersections to compute, I can’t interact with QGIS until the job is done.

Are there any UX guidelines written on when something should be done in a background process vs on the main thread? Would a zero tolerance policy be too severe? E.g. “all processing must be done in thread separate from the main application.”

Michael
_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux

_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux
Reply | Threaded
Open this post in threaded view
|

Re: Long running processes should be run in backgroun

DelazJ
In reply to this post by Michael Kirk
Hi,
Michael, there's an ongoing work at https://qgisgsoc2015.wordpress.com/project-plan/ that may be worth reading.
Cheers

Envoyé depuis mon HTC

----- Reply message -----
De : "Michael Kirk" <[hidden email]>
Pour : <[hidden email]>
Objet : [QGIS-UX] Long running processes should be run in backgroun
Date : ven., oct. 30, 2015 21:24

Hi UX,

I’ve been using the “Vector > Analysis > Points in Polygon” tool lately. This one can be particularly long running when using larger data sets, sometimes many hours long. I really appreciate that the developers do this processing in a background thread. This allows me to continue to use QGIS, starting other non-dependent analysis, inspecting features, etc. while  analysis runs.

Compare this to, for example, the “Vector > Analysis > Line Intersections" tool. When I have a large set of intersections to compute, I can’t interact with QGIS until the job is done.

Are there any UX guidelines written on when something should be done in a background process vs on the main thread? Would a zero tolerance policy be too severe? E.g. “all processing must be done in thread separate from the main application.”

Michael
_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux

_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux
Reply | Threaded
Open this post in threaded view
|

Re: Long running processes should be run in backgroun

Michael Kirk
In reply to this post by DelazJ
Hi Junior, Thanks for the info.

The GSOC project looks pretty interesting. As I understand it, among other things, that project intended to put all the algorithms from the processing chain in a non-ui thread. Do you know if this code was merged into master? The report kind of trails off at the end, so it’s unclear what goals were delivered. Anyway - it sounds like some good work was done there.

I must confess that I didn’t understand until this conversation that “processing” referred to a specific python module called “processing”. I thought it was being used generally to talk about the processing algorithms in qgis.

The actual algorithm that caused me to look into this was from fTools. I was using this simply because ‘ftools’ it is enabled by default. Default choices are very powerful, very important. Had I known that processing offered the same functionality (plus more) in a  non-blocking UI I probably never would have used fTools. Also, based on the commit activity, it seems like processing gets much more attention than fTools.

No disrespect to the fTools developers. I’ve gotten a ton of value out of that code - but I’m wondering if we can provide a different default which would help our new users be happier and more productive. If there is a reason to keep fTools the default, I’m more inclined to work on testing and improving them.

Michael


On Oct 30, 2015, at 2:56 PM, Junior <[hidden email]> wrote:

Hi,
Michael, there's an ongoing work at https://qgisgsoc2015.wordpress.com/project-plan/ that may be worth reading.
Cheers

Envoyé depuis mon HTC

----- Reply message -----
De : "Michael Kirk" <[hidden email]>
Pour : <[hidden email]>
Objet : [QGIS-UX] Long running processes should be run in backgroun
Date : ven., oct. 30, 2015 21:24

Hi UX,

I’ve been using the “Vector > Analysis > Points in Polygon” tool lately. This one can be particularly long running when using larger data sets, sometimes many hours long. I really appreciate that the developers do this processing in a background thread. This allows me to continue to use QGIS, starting other non-dependent analysis, inspecting features, etc. while  analysis runs.

Compare this to, for example, the “Vector > Analysis > Line Intersections" tool. When I have a large set of intersections to compute, I can’t interact with QGIS until the job is done.

Are there any UX guidelines written on when something should be done in a background process vs on the main thread? Would a zero tolerance policy be too severe? E.g. “all processing must be done in thread separate from the main application.”

Michael
_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux
_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux


_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux
Reply | Threaded
Open this post in threaded view
|

Re: Long running processes should be run in backgroun

berndv.
Hi Michael,

you hit the nail on the head. The Processing toolbox (formerly SEXTANTE) was introduced a while ago, but isn't as prominent as the old (or lets say very old) ftools. I can see from a lot of issues on the mailing list and also on stackexchange, that people start their thread with "I used Vector -> some algorithm" and do not have an idea that tons of other functions slumber in the processing toolbox.

But recently, the developers seem to have understood the problem, and as far as I know, the Vector menu will in the future serve as shortcuts to Processing functions, as most or all function there are already replicated within Processing.

At the moment, Processing functions will block the UI as well, but hopefully this also will change soon. But most functions in the toolbox are much faster and versatile than the native ftool functions. Since the toolbox was introduces, I personally used the ftool only when there was a bug with the Processing equivalent or when it was missing.
On the other hand, newbies seem to be overwhelmed by the sheer amount of functions, so they ask for easy to reach menus for common operations.

Cheers
Bernd


Am 31.10.2015, 22:24 Uhr, schrieb Michael Kirk <[hidden email]>:

Hi Junior, Thanks for the info.

The GSOC project looks pretty interesting. As I understand it, among other things, that project intended to put all the algorithms from the processing chain in a non-ui thread. Do you know if this code was merged into master? The report kind of trails off at the end, so it’s unclear what goals were delivered. Anyway - it sounds like some good work was done there.

I must confess that I didn’t understand until this conversation that “processing” referred to a specific python module called “processing”. I thought it was being used generally to talk about the processing algorithms in qgis.

The actual algorithm that caused me to look into this was from fTools. I was using this simply because ‘ftools’ it is enabled by default. Default choices are very powerful, very important. Had I known that processing offered the same functionality (plus more) in a  non-blocking UI I probably never would have used fTools. Also, based on the commit activity, it seems like processing gets much more attention than fTools.

No disrespect to the fTools developers. I’ve gotten a ton of value out of that code - but I’m wondering if we can provide a different default which would help our new users be happier and more productive. If there is a reason to keep fTools the default, I’m more inclined to work on testing and improving them.

Michael


On Oct 30, 2015, at 2:56 PM, Junior <[hidden email]> wrote:

Hi,
Michael, there's an ongoing work at https://qgisgsoc2015.wordpress.com/project-plan/ that may be worth reading.
Cheers

Envoyé depuis mon HTC

----- Reply message -----
De : "Michael Kirk" <[hidden email]>
Pour : <[hidden email]>
Objet : [QGIS-UX] Long running processes should be run in backgroun
Date : ven., oct. 30, 2015 21:24

Hi UX,

I’ve been using the “Vector > Analysis > Points in Polygon” tool lately. This one can be particularly long running when using larger data sets, sometimes many hours long. I really appreciate that the developers do this processing in a background thread. This allows me to continue to use QGIS, starting other non-dependent analysis, inspecting features, etc. while  analysis runs.

Compare this to, for example, the “Vector > Analysis > Line Intersections" tool. When I have a large set of intersections to compute, I can’t interact with QGIS until the job is done.

Are there any UX guidelines written on when something should be done in a background process vs on the main thread? Would a zero tolerance policy be too severe? E.g. “all processing must be done in thread separate from the main application.”

Michael
_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux
_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux




--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374

_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux
Reply | Threaded
Open this post in threaded view
|

Re: Long running processes should be run in backgroun

Richard Duivenvoorde
In reply to this post by Michael Kirk
On 31-10-15 22:24, Michael Kirk wrote:

> Hi Junior, Thanks for the info.
>
> The GSOC project looks pretty interesting. As I understand it, among
> other things, that project intended to put all the algorithms from the
> processing chain in a non-ui thread. Do you know if this code was merged
> into master? The report kind of trails off at the end, so it’s unclear
> what goals were delivered. Anyway - it sounds like some good work was
> done there.
>
> I must confess that I didn’t understand until this conversation that
> “processing” referred to a specific python module called “processing”. I
> thought it was being used generally to talk about the processing
> algorithms in qgis.
>
> The actual algorithm that caused me to look into this was from fTools. I
> was using this simply because ‘ftools’ it is enabled by default. Default
> choices are very powerful, very important. Had I known that processing
> offered the same functionality (plus more) in a  non-blocking UI I
> probably never would have used fTools. Also, based on the commit
> activity, it seems like processing gets much more attention than fTools.
>
> No disrespect to the fTools developers. I’ve gotten a ton of value out
> of that code - but I’m wondering if we can provide a different default
> which would help our new users be happier and more productive. If there
> is a reason to keep fTools the default, I’m more inclined to work on
> testing and improving them.

Hi Michael,

as a pretty long running project we have newer and older parts of code.
fTools was one of the first plugins adding these spatial algorithms to
QGIS. Later it was made a 'core plugin'.
Nowadays, I would say processing is the preferred way to run these
algorithms, though fTools is often the first accounter of newbies to
these kind of algorithms. But as you saw, it can be limited when you
have bigger datasets etc.

There have been already several discussions on the dev/user lists to
either merge or remove fTools, OR rewriting them to c++ to make them
faster and/or more stable.
Untill now I think the result of this discussions is to keep fTools as
is, mainly for new users. There are more voices to modernize fTools, OR
let it use the same code as processing, so if you think you can polish
the code, feel free off course. Maybe discuss your plans on the dev list
first.

Regards,

Richard Duivenvoorde

_______________________________________________
QGIS-UX mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-ux