Plugin Manager overhaul #43
Comments
|
@alexbruy is this something which requires an API break? |
|
Not sure if API break required, maybe it can be implemented without breaking API just extending it. |
|
But I guess for 3.0 API breaks would be allowed anyway - so it is a good chance to get the plugin manager into a perfect state and learn from what is missing now. |
|
Another possible improvement — replace or merge Plugin Manager with new Resourse Sharing plugin developed during GSoC. This way we will have single platform for sharing all kinds of resources in QGIS |
|
+1 |
|
[copied to the issue description] More ideas :-)
|
|
@alexbruy what do you mean by directory-based plugins repositories? |
|
@borysiasty I mean local repositories without web-server. E.g. directory with plugin packages and XML file (or even without it). This can be useful in situations when setting-up web-server is not possible, like small computer class or workshops when there is no internet access. |
|
@alexbruy: what about just using the file:// protocol? It works properly at mine, on Debian and Windows. Or is it too inconvinient for end users? |
|
Fine for me. |
|
Does using file:// work currently in QGIS 2.x?
|
|
@NathanW2 yep, works for me in 2.14 (with file:///c:/blahblah and file:///c:\blahblah notation on Windows). It's just QNetworkRequest. What I didn't test (and probably doesn't work) is a local network. Let me know if you observe any problems. |
|
Nice. That's a easy win
…On Sat., 28 Oct. 2017, 6:53 pm Borys Jurgiel, ***@***.***> wrote:
@NathanW2 <https://github.com/nathanw2> yep, works for me in 2.14 (with
file:///c:/blahblah and file:///c:\blahblah notation on Windows). It's just
QNetworkRequest. What I didn't test (and probably doesn't work) is a local
network.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#43 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAXS3NVQuU_V0BnIdSQNKYIUcYIzllgKks5swuufgaJpZM4H8prN>
.
|
|
Reading this thread, may I add another argument to either not even load any plugin, or load them whenever QGIS itself is loaded? |
|
That's a bit trigger because some plugins want to do stuff at load time. I
have a solution but can do it until 3.2
…On Sat., 28 Oct. 2017, 10:23 pm Richard Duivenvoorde, < ***@***.***> wrote:
Reading this thread, may I add another argument to either not even load
any plugin, or load them whenever QGIS itself is loaded?
I've had several requests from people here in NL which try to run QGIS in
thin client environments, be it either citrix or vmware based stuff. But
ALL see that QGIS (and then especially the python part) loads awfully slow
(like in >2-4 minutes the first cold start). Some report it is a problem
with virus scanners (which apparently have to check every *.pyc file
then....) others don't know, but blame python (as even in their osgeo4w
environments starting the python interpreter takes ten's of seconds.
If anybody has hints: please let me know.
BUT in either case: not preloading plugins would be a win for this setups.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#43 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAXS3KiwVy1UYvp1Y27CsIIiHN0OclD2ks5swxy-gaJpZM4H8prN>
.
|
|
Tricky
…On Sat., 28 Oct. 2017, 10:42 pm Nathan Woodrow, ***@***.***> wrote:
That's a bit trigger because some plugins want to do stuff at load time. I
have a solution but can do it until 3.2
On Sat., 28 Oct. 2017, 10:23 pm Richard Duivenvoorde, <
***@***.***> wrote:
> Reading this thread, may I add another argument to either not even load
> any plugin, or load them whenever QGIS itself is loaded?
> I've had several requests from people here in NL which try to run QGIS in
> thin client environments, be it either citrix or vmware based stuff. But
> ALL see that QGIS (and then especially the python part) loads awfully slow
> (like in >2-4 minutes the first cold start). Some report it is a problem
> with virus scanners (which apparently have to check every *.pyc file
> then....) others don't know, but blame python (as even in their osgeo4w
> environments starting the python interpreter takes ten's of seconds.
> If anybody has hints: please let me know.
> BUT in either case: not preloading plugins would be a win for this setups.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#43 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAXS3KiwVy1UYvp1Y27CsIIiHN0OclD2ks5swxy-gaJpZM4H8prN>
> .
>
|
|
what should a plugin do if it's disabled? |
|
Ok, so we can remove the preloading: qgis/QGIS#5532 Do we want to merge it now and prepare a nicer error reporting for enabled plugins for 3.2? @NathanW2 I'm curious what solution do you have? :) My idea is to make a better error dialog and store the changelog for later display in the manager, so the plugin is only marked as an invalid after a failed loading (and only for the session lifetime). |
|
@wonder-sk @rduivenvoorde @alexbruy, how do you like the solution above? |
|
hi @borysiasty ! Do you mean qgis/QGIS#5532 to avoid preloading of plugins? I like that! |
|
@wonder-sk yes, just didn't want to disable an existing feature without common enthusiasm ;) |
While Plugin Manager was improved in QGIS 2.x it still missed some important functionality:
<QGIS root>/python/plugins) and user's plugins directory (~/.qgis2/plugins)CHANGELOGfile and display it in case the relevant metadata key is empty.More ideas from Martin:
...and from Matthias:
The text was updated successfully, but these errors were encountered: