Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Discussion: MIME plugins existence

<< < (2/2)

thomas:
What is the actual problem if the MIME handler is a plugin? This is a technical sophistry without any real issues. The only difference between the SDK and a plugin is that you cannot disable the SDK. And if you disable the MIME plugin, that's your own fault really. If someone disabled the compiler plugin and was complaining that the IDE does not compile without it, then you would not take him serious, either.

The confusion which some users have experienced is a mere user interface problem, it has nothing to do with the fact that the MIME plugin is a plugin. On the other hand, it makes the application more modular, which is a good thing both for customisability and development. Personally, I would go the exact opposite way and transform even more components into plugins (for example keybinder or DevCPP/MSVC import). If a user is really sure that he does not need them or experiences problems, he can disable them, and if someone feels like adding Eclipse project import, he can add another plugin.

Except for a small event handling overhead when NotifyPlugins is called, a plugin has no disadvantage over builtin funcitonality. And this particular part has recently been optimized to run about 50-60 times faster than it used to in previous releases, so I don't see this as a real problem ;)

takeshimiya:
Well, my reasoning of this is because if all would be modular, it would be the ok.

Because it made little sense to me that MIME functionality is a plugin,
when cbEditor, KeyBinder, Project handling, Search functionality, are not.

It is not very logical that if I want to use C::B as a text editor, I have a built in Scintilla, but I can't open *.txt files (it simply doesn't do anything).

So either all a plugin, or the opposite, seems more logical.

Navigation

[0] Message Index

[*] Previous page