The request (already posted by some users in other sections) is to enable a way to add more categories to group functions.


best regards,

Davide

---

Wrote

The request (already posted by some users in other sections) is to enable a way to add more categories to group functions.

One of them could be me . The question is, how to do that? What additional categories should be made? How to manage all these things?

I think that the simplest idea is to just make a category with the same name as the plugin from which the particular function originated. This way, the name of the plugin could not be mentioned in the function description. The situation where you select a function name and do not know where from is it - is the most undesirable. Some other thing is about naming convention of the functions inside external plugins and the Andreys core functions. What about the collision between the functions of the same name like in the external plugin (I remember round() function caused trouble some time ago).

Another idea is Adnrey just simple to make additional categories, following the plugin makers request. Some of the categories, say, to be reserved for the core functions (made by Andrey) and some of them to be freely used by plugin makers. The collision between the functions of the same name still remains

Another thing is about the (non existing yet) the Help system. From the point of view of a user, I would rather appreciate when I install a plugin, at the same time to have a dedicated explanation of the plugin functions inside the Help Reference Book.

The external plugins management situation should be left to Andrey, I think. The fact is that by including additional functions and external plugins, the keeping track and to choose the desired and particular one, become quite troublesome. One other thing (which I would like to happen more often ) was the situation the two plugin makers revised the same plugin at the same time (an interesting coincidence ).

Maybe to many questions, and not so many answers, sorry.

Any other ideas?

Regards,
Radovan

Are exactly my thinks, and the reason because I've opened a topic instead of making a direct request to Andrey, I hope this help to choose a good way

BTW the function collision is not a problem, a Plugin developper may and should take into account the program features; f.e. a good way for a plugin developer is to uppercase the first character for his functions (f.e. Max(#) of Custom Functions and built-in max(#)). The norme(#) patch was made possible because there are no restrictions so, as for me, there's no need to have restrictions.

[EDIT] Additional catergories could be: statistical, ODE, financials, plugin (where plugin in front-end take the name from the assembly)

Wrote

Another thing is about the (non existing yet) the Help system. From the point of view of a user, I would rather appreciate when I install a plugin, at the same time to have a dedicated explanation of the plugin functions inside the Help Reference Book.

In this post, I summarized my current recommendations with respect to the help system.

Based on the assumption that SMath internally knows, which plugin a particular function is from, I propose to scan the handbook dir structure for a directory or file of appropriate name and take the function category description out of that. In principle this information could be provided by the plugin creator. However, the independent way allows to distribute the work share of documenting.

Most programmers do not like documenting, neither do I, but what to do if you want to use the program in teaching...

Wrote

Wrote

Another thing is about the (non existing yet) the Help system. From the point of view of a user, I would rather appreciate when I install a plugin, at the same time to have a dedicated explanation of the plugin functions inside the Help Reference Book.

In this post, I summarized my current recommendations with respect to the help system.

Based on the assumption that SMath internally knows, which plugin a particular function is from, I propose to scan the handbook dir structure for a directory or file of appropriate name and take the function category description out of that. In principle this information could be provided by the plugin creator. However, the independent way allows to distribute the work share of documenting.

Wrote

Most programmers do not like documenting, neither do I, but what to do if you want to use the program in teaching...

I couldn't agree with you more .

We can make examples, tutorials, etc. but the Help system (it has not need to be to extensive) is just inevitable.

Regards,
Radovan

About naming plugin fuctions the same as the built-in ones but starting with capital letter, what would happen if there were several functions with the same name from different plugins ?
I like the side panel idea suggested by Rise Eagle, I think it'd be a good way to show diverse information in a transparent way, the information would be adjusted automatically according to the cursor position without the intervention of the user: avoiding the search of menus, keystrokes to bring up help..
some of the information to show in this sidebar could be: category of the function, sortable list of plugin functions used in that worksheet, available help.. aside from the features suggested by Rising Eagle regarding variables status, operators configurations..