why arent plugins updated out of band to fix bugs like
https://forum.xojo.com/25507-ms-sql-server-and-begin-transaction
They could be since they are easily replaceable in any given install of Xojo and also bundled with the complete download
I know MBS has version’s assign (right click on a plugin and use Get Info). Einhugur does not and neither does Xojo. Ideally you’d want to be able to see what version of plugin you have rather than having to look at created date (is that even reliable?)
This has been a long standing wish of mine as we juggle plugin sets between projects and Xojo versions. It would make life easier if all plugins had an easily accessible version at the OS level. Since this isn’t a thing now we tend to run with a minimum set that covers all current projects which is a drag to swap out since compiling for 64-bit is glacially slow with large numbers of plugins.
Wouldn’t it be great to have the cache know that it has these plugins with these versions and if you change it out it checks for an existing cache with that Xojo version, plugin set (and version), and just reuses it rather than recompiling every single time?
[quote=438072:@Bob Keeney]I know MBS has version’s assign (right click on a plugin and use Get Info). Einhugur does not and neither does Xojo. Ideally you’d want to be able to see what version of plugin you have rather than having to look at created date (is that even reliable?)
This has been a long standing wish of mine as we juggle plugin sets between projects and Xojo versions. It would make life easier if all plugins had an easily accessible version at the OS level.
[/quote]
On macOS Finder meta data (extended attributes) might permit this on individual files
See https://developer.apple.com/library/archive/documentation/CoreServices/Reference/MetadataAttributesRef/Reference/CommonAttrs.html#//apple_ref/doc/uid/TP40001694-SW1
I’d expect there’s something similar on Linux & Windows - but lord knows
Since plugins ARE just zip files it would have to be some kind of cross platform format and I dont think that exists
In the IDE I would expect that a version number could be added to the Plugin SDK and the IDE could display that
[quote=438072:@Bob Keeney] Since this isn’t a thing now we tend to run with a minimum set that covers all current projects which is a drag to swap out since compiling for 64-bit is glacially slow with large numbers of plugins.
[/quote]
I have a set of applescripts that swap plugin sets around for me as I have 6 different sets
Only downside is that you do have to quit, run the script (from the script menu), and restart the IDE
Created date is definitely not reliable.
I guess some sort of shell extension could be made to read the versions from the Zip files (plugins are just zip files) on Windows and Mac, am not expert in that and not sure many would install it. (We have xml file inside the zip plugin file that stores the version)
Issue with embedding version in the name of the plugin is that then you have new set of problems, as in half the users will have 2 or more versions of same plugin installed.
[quote=438072:@Bob Keeney]I know MBS has version’s assign (right click on a plugin and use Get Info). Einhugur does not and neither does Xojo. Ideally you’d want to be able to see what version of plugin you have rather than having to look at created date (is that even reliable?)
This has been a long standing wish of mine as we juggle plugin sets between projects and Xojo versions. It would make life easier if all plugins had an easily accessible version at the OS level. Since this isn’t a thing now we tend to run with a minimum set that covers all current projects which is a drag to swap out since compiling for 64-bit is glacially slow with large numbers of plugins.
Wouldn’t it be great to have the cache know that it has these plugins with these versions and if you change it out it checks for an existing cache with that Xojo version, plugin set (and version), and just reuses it rather than recompiling every single time?[/quote]
I usually rename the plugin files to add some kind of version information if they don’t have it in the properties.
I would really like to see plugin sets as it would make working on several projects with different requirements so much easier. Currently, I make the Xojo Plugins folder an alias to the plugins for the project I am working on which does simplify plug-in management a bit. It doesn’t prevent the nasty preparing plugins step though.
even on macos plugin sets only go so far
just because of how things work you still have to quit and restart the IDE to unload the old plugins and load the new ones
its just how macOS works once it loads a dylib
had many conversations with joe about this
would still like to have a comment from @Geoff Perlman or @Travis Hill about this
for MBS Plugin, we include info in dll and dylibs, so you can see it in built apps with Finder and Explorer.
On Mac in the disk images, the plugins for MBS have version info in resource fork, so Finder can show it.
[quote=438065:@Norman Palardy]why arent plugins updated out of band to fix bugs like
https://forum.xojo.com/25507-ms-sql-server-and-begin-transaction
They could be since they are easily replaceable in any given install of Xojo and also bundled with the complete download[/quote]
I have never understood why Xojo don’t take more advantage of their own plugin technology to break the framework up into more manageable chunks. Surely it would make framework development, maintenance and release easier to manage. For example, if URLConnection had been a plugin it would have made it possible to release the recent bug fixes quicker.
[quote=438080:@Norman Palardy]even on macos plugin sets only go so far
just because of how things work you still have to quit and restart the IDE to unload the old plugins and load the new ones
its just how macOS works once it loads a dylib
had many conversations with joe about this[/quote]
Does the IDE need to actually load the plugins?
Couldn’t the IDE launch a helper application which loaded the plugins, extracted the relevant data for the IDE and then quit.
Of course not. An precompiling could also run in helper apps.
But that is a change which may take some days and there is probably more important work to do.
[quote=438085:@Kevin Gale]Does the IDE need to actually load the plugins?
Couldn’t the IDE launch a helper application which loaded the plugins, extracted the relevant data for the IDE and then quit.[/quote]
Yes
They cant draw in the IDE if they are not loaded 
You should say “I assume” [quote] it would make framework development, maintenance and release easier to manage[/quote]
It might
And some stuff IS done this way but its not plugins that you can just up and replace (ie/ they are not in your “Plugins” dir like database ones)
Some of that is due to dependencies across various classes
I’m still hoping one of Xojo’s staff will respond to this query (or any of the others I’ve sent)
[quote=438093:@Norman Palardy]Yes
They cant draw in the IDE if they are not loaded :)[/quote]
Ah - okay. I didn’t realise plugins could draw in the IDE. I thought that they were represented by a static image.
nope they are actually code that runs and can draw
hence they can react to property changes in the inspector
[quote=438100:@Norman Palardy]nope they are actually code that runs and can draw
hence they can react to property changes in the inspector[/quote]
Never thought of that (-:
Plugin sets would still be good from the point of having to avoid the precompiling step every time you switch them.
you have the whole “quit unload restart” cycle …
not sure you could not save ~/Library/Caches/Xojo//Precompiled Plugins as you swapped sets around
that might actually work with the kind of set up I have for managing them using an applescript