I observed two cases, where the installation of a plugin via extension manager failed. The files were downloaded and placed in the extensions/plugins directory, but then failed to load, throwing an error message.

This may well happen and the extension manager is perhaps not to blame for that.

But here is where the bug comes. The extension manager does not list the installed files under local storage, thus there is no possibility to deactivate/delete them. However, the files are still there and cause error messages on each program startup. The only way to get rid of the problem is to manually remove the files from the extension dir.

I had no problem installing the recent plugins from Online Galery made by uni and w3b5urf3r , provided all the previous user plugins deleted from the installation folder. However, there are now two folders where the plugins resides with the SMath Desktop (I think) - Installation folder ..\SMath\plugins - users folder *WIn7* ..\AppData\Roaming\SMath\extensions\plugins . I am not sure what is happening with the "SMath plugins" (made by Martin) and how that can be "portable". By the way, I mentioned this on Ubuntu that the recent build does not work. Closing the Extension manager will close SMath. I do not know if this has anything with the behavior Martin mentioned.

Not quite sure yet how is all of this going to work. Manual copying or of plugins may cause the problems. In the recent nightbuld it is said that the external plugins must be deleted and used only via Extension manager. I managed once to crash SMath by copying a plugin into the installation folder, but some other plugins cause no problems by manual copying into the plugins folder (both of them).

I think this needs to be clarified a bit.

Regards,
Radovan

You can't use the old plug-ins with the regions. Therefore, a simple copy of the old version will fail. Do not use this way for old such plugins. As I said, they need to be recompiled with a small addition. New plugins can be copied. Do not use the plug-ins from my ftp, they are all old. Plugin Manager is not completed yet, Andrey is working on it. In any case, if there is a problem, try to remove all user's plugins manually from ..\SMath\plugins and ..\AppData\[username]\SMath\extensions\plugins, then install them from the gallery.

As for me, everything works fine:

[albumimg]203[/albumimg] [albumimg]206[/albumimg]

For me as well

There is still already mentioned problem of saving graphs and the graphs settings. Am I right about it?

[albumimg]207[/albumimg]

We are still thinking about it. ZedGraph has too many parameters and we have not come up with a simple way to save them to a file. It should be transparent to the programmer. In addition, we are thinking about how to make a dynamic display properties of the graph depending on the experience level (convenience).

Wrote

You can't use the old plug-ins with the regions. Therefore, a simple copy of the old version will fail. Do not use this way for old such plugins. As I said, they need to be recompiled with a small addition. New plugins can be copied. Do not use the plug-ins from my ftp, they are all old. Plugin Manager is not completed yet, Andrey is working on it. In any case, if there is a problem, try to remove all user's plugins manually from ..\SMath\plugins and ..\AppData\[username]\SMath\extensions\plugins, then install them from the gallery.

Sorry, did not quite understand. Does it mean that the Linux-portable with plugins (made By Martin) can not exist anymore? Or that it can, only by copying the newly compiled plugins into the "...\SMath\plugins" as it is now ?

Regards,
Radovan

EDIT: Hmm..., it seems Martin had troubles with it

Uni, thanks for the answer. I can just envy you and Radovan the neat work of the plugins in the new SMath version. I am using the portable version of 4902 for testing. I just now removed the complete extensions folder (residing just besides the portable exe) and re-installed everything from the extensions manager. Thus, no manual file copying.

What fails to install (and needs to be removed manually for clean program start)

3D plot region
XY-Plot
Zedgraph region

What installs successfully (without function check, just loading)

alglib
checkbox
combobox
customFunctions
imageregion
MapleWrapper (with the files being installed in subdirs of extensions/plugin and also in extensions/plugin directly)
Statistical tools

But never mind, I anyways do not use 4902 for productive work due to the ; arg delimiter bug.

Still, the topic was not on failed plugin installation but on how to handle that in the extension manager.

As to the settings of graphs: How about having a hardwired default set of settings and just saving the changed ones? Hardly any one is going to touch everything, and if so, he has good reasons for that and has to accept larger file size.

Similarly, you could allow the user to have own defaults, which then would need to be included in every file that uses corresponding plots (sort of 3 level settings, 1. built in, 2. user defaults, 3. per plot settings. You could add a per document setting level, just to effectively reformat all plots of a sheet.

That implies, of course, that there is generic way to handle read and write of individual settings without the need to code them individually.


Gnuplot scripts are generally just some lines of text. If you save the plot from the gui or from the command line, then you get hundreds of settings. The trace specification, however, is still very compact and smart.

Wrote

Sorry, did not quite understand. Does it mean that the Linux-portable with plugins (made By Martin) can not exist anymore? Or that it can, only by copying the newly compiled plugins into the "...\SMath\plugins" as it is now ?

I made the portable version with plugins in order to save the users from collecting the plugins from all over the forum (I point to this installation in the Handbuch).

I could try to put something similar together for the 4902 version. However, I do not think that this is a good idea.

First: This version has the ; arg delim bug, which would force me to use different settings wrt the handbook.
Second: there are more working plugins in the old version (4884 based), in particular, the plot regions by uni don't work here.
Third: As soon as the extensions manager is mature enough, my inofficial distribution shall be obsolete, because there is a convenient way to install all the plugins upon request.

If there are other reasons to keep the distrib up to date, please tell me, than I can do that (preferrably after solution of points 1 and 2)

Wrote

...I am using the portable version of 4902 for testing. I just now removed the complete extensions folder (residing just besides the portable exe) and re-installed everything from the extensions manager. Thus, no manual file copying.

Martin, I don't get it sorry. Does it mean that this is the third place where the extension folder resists, and it is reserved for the *.tar,mono version?
It seems I made a mess because I did not see that extension folder. Maybe because I tried to use them both on the same computer.

Regards,
Radovan

Цитата

As to the settings of graphs: How about having a hardwired default set of settings and just saving the changed ones? Hardly any one is going to touch everything, and if so, he has good reasons for that and has to accept larger file size.

Yes, this is a good idea, thank you. Also the problem is in the depth of the hierarchy. The way in which we have used before is not convenient for the programmer when working with a such complex component.

Цитата

Similarly, you could allow the user to have own defaults, which then would need to be included in every file that uses corresponding plots (sort of 3 level settings, 1. built in, 2. user defaults, 3. per plot settings. You could add a per document setting level, just to effectively reformat all plots of a sheet.

That implies, of course, that there is generic way to handle read and write of individual settings without the need to code them individually.

Ok, I'll think about it.

Цитата

Gnuplot scripts are generally just some lines of text. If you save the plot from the gui or from the command line, then you get hundreds of settings. The trace specification, however, is still very compact and smart.

With scripts, if you make a mistake in the syntax, it is not so easy to find fault. That is why to select the settings I use the PropertyGrid component.

Wrote

Wrote

Sorry, did not quite understand. Does it mean that the Linux-portable with plugins (made By Martin) can not exist anymore? Or that it can, only by copying the newly compiled plugins into the "...\SMath\plugins" as it is now ?

I made the portable version with plugins in order to save the users from collecting the plugins from all over the forum (I point to this installation in the Handbuch).

I could try to put something similar together for the 4902 version. However, I do not think that this is a good idea.

First: This version has the ; arg delim bug, which would force me to use different settings wrt the handbook.
Second: there are more working plugins in the old version (4884 based), in particular, the plot regions by uni don't work here.
Third: As soon as the extensions manager is mature enough, my inofficial distribution shall be obsolete, because there is a convenient way to install all the plugins upon request.

If there are other reasons to keep the distrib up to date, please tell me, than I can do that (preferrably after solution of points 1 and 2)

I still think that your portable version including the plugins is still a very good solution. An official version with plugins and extensions to be installed from the Net upon request is one thing, but having the portable version is more convenient and it should not be obsolete IMHO. I do not understand why the extension was removed in the Apps folder. Why it is not inside the installation folder as the "plugin" folder is (not quite sure about it). To make long story short, the portable version including the plugins is quite useful and should not be canceled. Just a simple explanation for that. It is easier for me to make a portable version with included the chosen plugins and distribute to my students. Than I will not care about what they should install afterwards, the Net connections, proxies etc. Actually, If I can make a portable version using the official one, or using the tar, mono version, or using your unofficial one, every solution will be Ok with me.

Regards,
Radovan

Wrote

I still think that your portable version including the plugins is still a very good solution. An official version with plugins and extensions to be installed from the Net upon request is one thing, but having the portable version is more convenient and it should not be obsolete IMHO. I do not understand why the extension was removed in the Apps folder. Why it is not inside the installation folder as the "plugin" folder is (not quite sure about it). To make long story short, the portable version including the plugins is quite useful and should not be canceled. Just a simple explanation for that. It is easier for me to make a portable version with included the chosen plugins and distribute to my students. Than I will not care about what they should install afterwards, the Net connections, proxies etc. Actually, If I can make a portable version using the official one, or using the tar, mono version, or using your unofficial one, every solution will be Ok with me.

Regards,
Radovan

OK, if the 4902 is mature enough to think of a distribution for teaching, then I see what I can do.

Wrote

DataExchange Plugin is installed but it is not working for me. See attached message

Hmm..., I think w3b5urf3r_reloaded (Davide Carpi) did not recompile it yet, and this must have been the old one. I do not see it in the Extension Manager. I might be wrong of course.

Regards,
Radovan

Wrote

DataExchange Plugin is installed but it is not working for me. See attached message

Actually there is a problem with third party plugins and the latest nigthly build, when this will be solved I'll upload the new Data Exchange on the gallery

BTW the xlsx functions will be moved in a new plugin (Xlsx Import/Export - NET framework 3.5 required) leaving Date Exchange as independent plugin (NET framework 2.0 and no more multiple builds)


Best regards,

w3b5urf3r

Wrote

DataExchange Plugin is installed but it is not working for me. See attached message

Correct GUID must be set for every plugin in Assembly Info to make it possible to work with Extensions Manager.

Regards.