On Sat, Feb 23, 2013 at 2:45 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Sounds like -noplugins would be a good idea, but it does not exist. None of those flags will disable plugins in the user folders (~/pd-externals).
You shouldn't need a Recent Files plugin any more with 0.43.4, its included on all platforms. But maybe its not as good as the plugin version?
The plugin overwrites the original ::pd_menus::update_recentfiles_on_menu so I guess it's aiming to do something better.
About the -noplugins option: yes it would be nice, and btw, I've just realised that the planned evolution of plugins-plugin to use pd::guiprefs instead of "/disabled" folders cannot be done in a plugin form but needs the mechanism to go into pd-gui.tcl This sounds like a good case to overhaul the plugin loading code a bit.
What do you think?
András
On 03/03/13 11:46, András Murányi wrote:
The plugin overwrites the original ::pd_menus::update_recentfiles_on_menu so I guess it's aiming to do something better.
the plugin just prepend numbers to recentfile names and add keyboard shortcuts so, combined with menubar plugin[1], you can access your most recently used patch by doing:
ALT-F 1
ps: [OT] I notice that recentfile support was broken on linux by 356fa6abd89d9 will submit a patch later to fix that..
cheers, y
[1] https://github.com/gusano/pd_stuffs/tree/master/gui-plugins/menubar
On 03/03/13 12:29, yvan volochine wrote:
ps: [OT] I notice that recentfile support was broken on linux by 356fa6abd89d9 will submit a patch later to fix that..
done:
https://sourceforge.net/tracker/?func=detail&aid=3606687&group_id=55...
cheers, y
On 03/03/2013 10:05 AM, yvan volochine wrote:
On 03/03/13 12:29, yvan volochine wrote:
ps: [OT] I notice that recentfile support was broken on linux by 356fa6abd89d9 will submit a patch later to fix that..
done:
https://sourceforge.net/tracker/?func=detail&aid=3606687&group_id=55...
cheers, y
Sorry about that, I broke that. Thanks for fixing it!
.hc
On 03/03/2013 08:46 AM, András Murányi wrote:
On Sat, Feb 23, 2013 at 2:45 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Sounds like -noplugins would be a good idea, but it does not exist. None of those flags will disable plugins in the user folders (~/pd-externals).
You shouldn't need a Recent Files plugin any more with 0.43.4, its included on all platforms. But maybe its not as good as the plugin version?
The plugin overwrites the original ::pd_menus::update_recentfiles_on_menu so I guess it's aiming to do something better.
About the -noplugins option: yes it would be nice, and btw, I've just realised that the planned evolution of plugins-plugin to use pd::guiprefs instead of "/disabled" folders cannot be done in a plugin form but needs the mechanism to go into pd-gui.tcl This sounds like a good case to overhaul the plugin loading code a bit.
What do you think?
András
I'm happy to review patch submissions for this, the plugins handling certainly can be improved. What do you have in mind?
.hc
On Tue, Mar 26, 2013 at 1:34 AM, Hans-Christoph Steiner hans@at.or.atwrote:
On 03/03/2013 08:46 AM, András Murányi wrote:
On Sat, Feb 23, 2013 at 2:45 AM, Hans-Christoph Steiner <hans@at.or.at wrote:
Sounds like -noplugins would be a good idea, but it does not exist.
None
of those flags will disable plugins in the user folders (~/pd-externals).
You shouldn't need a Recent Files plugin any more with 0.43.4, its included on all platforms. But maybe its not as good as the plugin version?
The plugin overwrites the original ::pd_menus::update_recentfiles_on_menu so I guess it's aiming to do something better.
About the -noplugins option: yes it would be nice, and btw, I've just realised that the planned evolution of plugins-plugin to use pd::guiprefs instead of "/disabled" folders cannot be done in a plugin form but needs the mechanism to go into pd-gui.tcl This sounds like a good case to overhaul the plugin loading code a bit.
What do you think?
András
I'm happy to review patch submissions for this, the plugins handling certainly can be improved. What do you have in mind?
.hc
basically, implementing a -noplugins option, and wiring plugins preferences to pd::guiprefs
András
On 03/26/2013 07:52 AM, András Murányi wrote:
On Tue, Mar 26, 2013 at 1:34 AM, Hans-Christoph Steiner hans@at.or.atwrote:
On 03/03/2013 08:46 AM, András Murányi wrote:
On Sat, Feb 23, 2013 at 2:45 AM, Hans-Christoph Steiner <hans@at.or.at wrote:
Sounds like -noplugins would be a good idea, but it does not exist.
None
of those flags will disable plugins in the user folders (~/pd-externals).
You shouldn't need a Recent Files plugin any more with 0.43.4, its included on all platforms. But maybe its not as good as the plugin version?
The plugin overwrites the original ::pd_menus::update_recentfiles_on_menu so I guess it's aiming to do something better.
About the -noplugins option: yes it would be nice, and btw, I've just realised that the planned evolution of plugins-plugin to use pd::guiprefs instead of "/disabled" folders cannot be done in a plugin form but needs the mechanism to go into pd-gui.tcl This sounds like a good case to overhaul the plugin loading code a bit.
What do you think?
András
I'm happy to review patch submissions for this, the plugins handling certainly can be improved. What do you have in mind?
.hc
basically, implementing a -noplugins option, and wiring plugins preferences to pd::guiprefs
I think that a -noplugins flag is a no brainer, that should be included. I'm still on the fence about adding the ability to disable plugins via the interface. The model so far for installing and disabling externals, plugins, etc. is putting them in the user-installed folder or moving them out of that folder. Its very simple and easy to maintain.
I have no objections for adding the possibility to allow plugin management in a plugin, but I'm not sure about including it by default.
.hc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-03-27 21:12, Hans-Christoph Steiner wrote:
I think that a -noplugins flag is a no brainer, that should be included. I'm still on the fence about adding the ability to disable plugins via the interface. The model so far for installing and disabling externals, plugins, etc. is putting them in the user-installed folder or moving them out of that folder. Its very simple and easy to maintain.
definitely not.
i find myself cursing everytime i want to use/not use a given gui-plugin.
moving files around is _not_ a way to configure your system. at least i know of no system that is configured like that; not that there *are* some system settings that work like that (`find /etc -type d -name "*.d") but those are not for user-preferences that might change today *and* tomorrow.
also, there might be a reason why Pd-extended switched from loading all libraries by default to a scheme, where the user has to explicitely enable a given feature. taking your gui-plugins argument to PdX, we could have simply told the users to just move all the objects/externals they don't want to use to a save place (and turn off the "couldn't find" errors)
I have no objections for adding the possibility to allow plugin management in a plugin, but I'm not sure about including it by default.
it's simply not possible to unload a given plugin with a plugin that is loaded afterwards. (at least not until all the gui-plugins implement an unloading mechanism).
if we have the opportunity to get a built-in gui-plugins management instead of the "last-files" i'm all for it (as the latter can be easily implemented as a plugin, unlike the former)
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 03/27/2013 01:27 PM, IOhannes m zmoelnig wrote:
On 2013-03-27 21:12, Hans-Christoph Steiner wrote:
I think that a -noplugins flag is a no brainer, that should be included. I'm still on the fence about adding the ability to disable plugins via the interface. The model so far for installing and disabling externals, plugins, etc. is putting them in the user-installed folder or moving them out of that folder. Its very simple and easy to maintain.
definitely not.
i find myself cursing everytime i want to use/not use a given gui-plugin.
moving files around is _not_ a way to configure your system. at least i know of no system that is configured like that; not that there *are* some system settings that work like that (`find /etc -type d -name "*.d") but those are not for user-preferences that might change today *and* tomorrow.
also, there might be a reason why Pd-extended switched from loading all libraries by default to a scheme, where the user has to explicitely enable a given feature. taking your gui-plugins argument to PdX, we could have simply told the users to just move all the objects/externals they don't want to use to a save place (and turn off the "couldn't find" errors)
I have no objections for adding the possibility to allow plugin management in a plugin, but I'm not sure about including it by default.
it's simply not possible to unload a given plugin with a plugin that is loaded afterwards. (at least not until all the gui-plugins implement an unloading mechanism).
if we have the opportunity to get a built-in gui-plugins management instead of the "last-files" i'm all for it (as the latter can be easily implemented as a plugin, unlike the former)
The plugin-management plugin can just move the plugin files itself to disable them, so we could just make the system plugin loader ignore a folder called DISABLED/ inside each path. Then people can make plugin-management plugins using that mechanism, and customize the rest however they see fit. This would also be easy to understand for people who are just moving files around manually.
.hc
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-dev@iem.at Cc: Sent: Wednesday, March 27, 2013 4:27 PM Subject: Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-03-27 21:12, Hans-Christoph Steiner wrote:
I think that a -noplugins flag is a no brainer, that should be included. I'm still on the fence about adding the ability to disable plugins via the interface. The model so far for installing and disabling externals, plugins, etc. is putting them in the user-installed folder or moving them out of that folder. Its very simple and easy to maintain.
definitely not.
i find myself cursing everytime i want to use/not use a given gui-plugin.
I think what Hans means is that it's very simple and easy for him to maintain as the Pd-Extended guy. Got a handy plugin for managing plugins? Throw it in this directory. Is it pretty stable? He'll throw it in the distro. Not maintaining it anymore? He can just remove it from the distro. In none of those scenarios does Hans end up with new functionality in the core of the GUI that he is now forced to maintain or remove altogether.
-Jonathan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-03-27 22:06, Jonathan Wilkes wrote:
I think what Hans means is that it's very simple and easy for him to maintain as the Pd-Extended guy. Got a handy plugin for managing plugins? Throw it in this directory. Is it pretty stable? He'll throw it in the distro. Not maintaining it anymore? He can just remove it from the distro. In none of those scenarios does Hans end up with new functionality in the core of the GUI that he is now forced to maintain or remove altogether.
i'm not talking about PdX. i'm talking about Pd (vanilla): just like the loading of externals is managed in Pd-core, the loading of gui plugins should be managed by Pd-gui. and "managing" should not translate to automatically loading whatever is there. i don't think that a simple plugin manager is too complicated (and needs too much maintainance attention). what's more: if you don't like it, you can always create a pluginmanager-plugin and tell the default pluginmanager to _only_ load the new pluginmanager-plugin, which in turn can do a nicer job.
the problem we are facing right now, is that a lot of gui-plguins get activated automatically, and i have no choice to disable that. at least without switching to my favourite filesystem browser, search for the offending plugin (while the documentation only mentions 2 paths where the plugins can be installed, there are really 3-4 that are always searched, not counting the paths added with "-path", so where the hell should i start searching? how am i to guess that the file "wurdel.tcl" is really the plugin that colorizes all text light-green?) and move it out of the way (after asking my sysadmin for the root-password, since that plugin really was installed somewhere i am not allowed to change files).
an intermediate way could be: - - keep the current behaviour of loading all gui-plugins - - only install a _single_ guiplugin by default, that in turn loads gui-plugins from _another_ search path. - - people can download a more sophisticated guiplugin ("plugin-manager") and replace that "load-all-plugins" plugin. (not really ideal, as it kind of perverts the documentation, where to install plugins; also the "load-all-plugins" is most likely installed with root priviliges, so again i have to ask my sysadmin to replace it)
similar, though slightly better: - - only automatically load a specially-named plugin (e.g. "autoloaded-plugin.tcl") that handles the loading of the other plugins. - - ideally Pd-gui would only try to load a single plugin of that name (so if you have ~/pd-externals/autoloaded-plugin.tcl and /usr/local/lib/pd-externals/autoloaded-plugin.tcl and /usr/lib/pd-extended/autoloaded/plugin.tcl it will only load the one in ~/pd-externals) - - in case this special plugin is not available, revert to the default behaviour of loading all plugins in all search-paths (this would allow to have the old behaviour, but to be easily able to override this behaviour if you don't like it)
all these require to modify the pd-gui. but so does any bugfix (and i'm pretty sure that the solution to bugs is to fix, even if the bugfix might not see much "maintenance" by the original submitter afterwards)
gfmasdrs IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 03/28/2013 03:58 AM, IOhannes m zmoelnig wrote:
On 2013-03-27 22:06, Jonathan Wilkes wrote:
I think what Hans means is that it's very simple and easy for him to maintain as the Pd-Extended guy. Got a handy plugin for managing plugins? Throw it in this directory. Is it pretty stable? He'll throw it in the distro. Not maintaining it anymore? He can just remove it from the distro. In none of those scenarios does Hans end up with new functionality in the core of the GUI that he is now forced to maintain or remove altogether.
i'm not talking about PdX. i'm talking about Pd (vanilla): just like the loading of externals is managed in Pd-core, the loading of gui plugins should be managed by Pd-gui. and "managing" should not translate to automatically loading whatever is there. i don't think that a simple plugin manager is too complicated (and needs too much maintainance attention). what's more: if you don't like it, you can always create a pluginmanager-plugin and tell the default pluginmanager to _only_ load the new pluginmanager-plugin, which in turn can do a nicer job.
the problem we are facing right now, is that a lot of gui-plguins get activated automatically, and i have no choice to disable that. at least without switching to my favourite filesystem browser, search for the offending plugin (while the documentation only mentions 2 paths where the plugins can be installed, there are really 3-4 that are always searched, not counting the paths added with "-path", so where the hell should i start searching? how am i to guess that the file "wurdel.tcl" is really the plugin that colorizes all text light-green?) and move it out of the way (after asking my sysadmin for the root-password, since that plugin really was installed somewhere i am not allowed to change files).
an intermediate way could be: - keep the current behaviour of loading all gui-plugins - only install a _single_ guiplugin by default, that in turn loads gui-plugins from _another_ search path. - people can download a more sophisticated guiplugin ("plugin-manager") and replace that "load-all-plugins" plugin. (not really ideal, as it kind of perverts the documentation, where to install plugins; also the "load-all-plugins" is most likely installed with root priviliges, so again i have to ask my sysadmin to replace it)
similar, though slightly better: - only automatically load a specially-named plugin (e.g. "autoloaded-plugin.tcl") that handles the loading of the other plugins. - ideally Pd-gui would only try to load a single plugin of that name (so if you have ~/pd-externals/autoloaded-plugin.tcl and /usr/local/lib/pd-externals/autoloaded-plugin.tcl and /usr/lib/pd-extended/autoloaded/plugin.tcl it will only load the one in ~/pd-externals) - in case this special plugin is not available, revert to the default behaviour of loading all plugins in all search-paths (this would allow to have the old behaviour, but to be easily able to override this behaviour if you don't like it)
all these require to modify the pd-gui. but so does any bugfix (and i'm pretty sure that the solution to bugs is to fix, even if the bugfix might not see much "maintenance" by the original submitter afterwards)
How about we start with adding only the required mechanism so that people can make all sorts of plugin management plugins. Then revisit the rest later once we have a good idea of how it should be done. Making the plugin loader ignore a folder called DISABLED/ would make it possible to do what you describe in a regular plugin.
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-dev@iem.at Cc: Sent: Thursday, March 28, 2013 4:26 PM Subject: Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
[...]
How about we start with adding only the required mechanism so that people can make all sorts of plugin management plugins. Then revisit the rest later once we have a good idea of how it should be done. Making the plugin loader ignore a folder called DISABLED/ would make it possible to do what you describe in a regular plugin.
.hc
Do you want to require plugins to live in one specific "startup" directory that has user permissions to read/write/exec? If so, then I think the "startup/disabled" directory idea is adequate.
On the other hand, if you want Pd to search the standard paths for plugins then the "startup/disabled" idea is incompatible with that, no? Permission problems abide, plus when you want to re-enable a plugin how does Pd know which directory it previously lived in?
-Jonathan
On 03/28/2013 01:46 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-dev@iem.at Cc: Sent: Thursday, March 28, 2013 4:26 PM Subject: Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
[...]
How about we start with adding only the required mechanism so that people can make all sorts of plugin management plugins. Then revisit the rest later once we have a good idea of how it should be done. Making the plugin loader ignore a folder called DISABLED/ would make it possible to do what you describe in a regular plugin.
.hc
Do you want to require plugins to live in one specific "startup" directory that has user permissions to read/write/exec? If so, then I think the "startup/disabled" directory idea is adequate.
On the other hand, if you want Pd to search the standard paths for plugins then the "startup/disabled" idea is incompatible with that, no? Permission problems abide, plus when you want to re-enable a plugin how does Pd know which directory it previously lived in?
As I see it now, DISABLED/ would be ignored in all search paths. And when a plugin is disabled, it would be moved into the local DISABLED/ folder. So disabling a plugin in ~/pd-externals would place it into ~/pd-externals/DISABLED.
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at" pd-dev@iem.at Sent: Thursday, March 28, 2013 4:50 PM Subject: Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
On 03/28/2013 01:46 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-dev@iem.at Cc: Sent: Thursday, March 28, 2013 4:26 PM Subject: Re: [PD-dev] Gui plugins management (Was: I have 3 broken
installs)
[...]
How about we start with adding only the required mechanism so that
people
can make all sorts of plugin management plugins. Then revisit the rest later once we have a good idea of how it should be done. Making the
plugin
loader ignore a folder called DISABLED/ would make it possible to do
what
you describe in a regular plugin.
.hc
Do you want to require plugins to live in one specific "startup"
directory that
has user permissions to read/write/exec? If so, then I think the
"startup/disabled"
directory idea is adequate.
On the other hand, if you want Pd to search the standard paths for plugins then the "startup/disabled" idea is incompatible with that, no?
Permission problems
abide, plus when you want to re-enable a plugin how does Pd know which
directory
it previously lived in?
As I see it now, DISABLED/ would be ignored in all search paths. And when a plugin is disabled, it would be moved into the local DISABLED/ folder.
That method will fail when the user running Pd doesn't have permission to move those files.
-Jonathan
On 03/28/2013 09:28 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at" pd-dev@iem.at Sent: Thursday, March 28, 2013 4:50 PM Subject: Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
On 03/28/2013 01:46 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-dev@iem.at Cc: Sent: Thursday, March 28, 2013 4:26 PM Subject: Re: [PD-dev] Gui plugins management (Was: I have 3 broken
installs)
[...]
How about we start with adding only the required mechanism so that
people
can make all sorts of plugin management plugins. Then revisit the rest later once we have a good idea of how it should be done. Making the
plugin
loader ignore a folder called DISABLED/ would make it possible to do
what
you describe in a regular plugin.
.hc
Do you want to require plugins to live in one specific "startup"
directory that
has user permissions to read/write/exec? If so, then I think the
"startup/disabled"
directory idea is adequate.
On the other hand, if you want Pd to search the standard paths for plugins then the "startup/disabled" idea is incompatible with that, no?
Permission problems
abide, plus when you want to re-enable a plugin how does Pd know which
directory
it previously lived in?
As I see it now, DISABLED/ would be ignored in all search paths. And when a plugin is disabled, it would be moved into the local DISABLED/ folder.
That method will fail when the user running Pd doesn't have permission to move those files.
-Jonathan
That is true. That would only really affect multi-user setups where a sysadmin was installing plugins. Maybe Andras' idea for using a list that is stored in the GUI preferences makes the most sense here. If the plugin list is present, then it loads that, if not, it uses the search path method.
Or there is IOhannes' method with the autostart plugin. It has the advantage of being controlable via the file system, i.e. if the autostart plugin is removed, then its disabled. This list method would need to be disabled via the preferences.
One way to handle that would be that the plugin-plugin would have to handle the writing of the list to the preferences each time Pd runs, and Pd would load the list if it was present, then delete it from the preferences. Hmm, that might be hacky...
.hc
On Thu, Mar 28, 2013 at 9:26 PM, Hans-Christoph Steiner hans@at.or.atwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 03/28/2013 03:58 AM, IOhannes m zmoelnig wrote:
On 2013-03-27 22:06, Jonathan Wilkes wrote:
I think what Hans means is that it's very simple and easy for him to maintain as the Pd-Extended guy. Got a handy plugin for managing plugins? Throw it in this directory. Is it pretty stable? He'll throw it in the distro. Not maintaining it anymore? He can just remove it from the distro. In none of those scenarios does Hans end up with new functionality in the core of the GUI that he is now forced to maintain or remove altogether.
i'm not talking about PdX. i'm talking about Pd (vanilla): just like the loading of externals is managed in Pd-core, the loading of gui plugins should be managed by Pd-gui. and "managing" should not translate to automatically loading whatever is there. i don't think that a simple plugin manager is too complicated (and needs too much maintainance attention). what's more: if you don't like it, you can always create a pluginmanager-plugin and tell the default pluginmanager to _only_ load the new pluginmanager-plugin, which in turn can do a nicer job.
the problem we are facing right now, is that a lot of gui-plguins get activated automatically, and i have no choice to disable that. at least without switching to my favourite filesystem browser, search for the offending plugin (while the documentation only mentions 2 paths where the plugins can be installed, there are really 3-4 that are always searched, not counting the paths added with "-path", so where the hell should i start searching? how am i to guess that the file "wurdel.tcl" is really the plugin that colorizes all text light-green?) and move it out of the way (after asking my sysadmin for the root-password, since that plugin really was installed somewhere i am not allowed to change files).
an intermediate way could be: - keep the current behaviour of loading all gui-plugins - only install a _single_ guiplugin by default, that in turn loads gui-plugins from _another_ search path. - people can download a more sophisticated guiplugin ("plugin-manager") and replace that "load-all-plugins" plugin. (not really ideal, as it kind of perverts the documentation, where to install plugins; also the "load-all-plugins" is most likely installed with root priviliges, so again i have to ask my sysadmin to replace it)
similar, though slightly better: - only automatically load a specially-named plugin (e.g. "autoloaded-plugin.tcl") that handles the loading of the other plugins. - ideally Pd-gui would only try to load a single plugin of that name (so if you have ~/pd-externals/autoloaded-plugin.tcl and /usr/local/lib/pd-externals/autoloaded-plugin.tcl and /usr/lib/pd-extended/autoloaded/plugin.tcl it will only load the one in ~/pd-externals) - in case this special plugin is not available, revert to the default behaviour of loading all plugins in all search-paths (this would allow to have the old behaviour, but to be easily able to override this behaviour if you don't like it)
all these require to modify the pd-gui. but so does any bugfix (and i'm pretty sure that the solution to bugs is to fix, even if the bugfix might not see much "maintenance" by the original submitter afterwards)
How about we start with adding only the required mechanism so that people can make all sorts of plugin management plugins. Then revisit the rest later once we have a good idea of how it should be done. Making the plugin loader ignore a folder called DISABLED/ would make it possible to do what you describe in a regular plugin.
.hc
I think the only required mechanism would be to load plugins form a list in the preferences file. This may be even simpler than the current mechanism of going through the search path. Then the management plugin would take care of discovering, enabling, disabling plugins, and updating the list.
András
-
András Murányi -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
yvan volochine