Discussion: MIME plugins existence

[takeshimiya]

Hi. I was thinking what are the advantages and disvantages of having MIME functionality as a plugin, or in the SDK.

Disvantages of having MIME as plugins:
In my opinion, it's a very common feature to having it as a plugin.
It introduces confussion between users and it's not convenient having different MIME plugins for every plugin (ie. wxSmith) that needs extension file handling.

And, what happens if you disable the Default MIME plugin?
Well, I have a personality of C::B that doesn't load any plugin.
So it's weird that I can open .h/.cpp files, but if I try to open a .txt or any other file, nothing happens, no question nor message box.

I can't think of any app that manages MIME as plugins, but I can think of apps that does not (Firefox, SciTE).

So far, to me it makes sense moving the MIME functionality to the SDK.
What do you think?

[David Perfors]

I think it is a good idea to move the MIME to the SDK, I can't find a reason not to do so...

What I want to know is:
What is the advantage to have a MIME plugin?
What is the disadvantage to move it to the SDK? (it takes some time, and not every one does have that time... I know )

[mandrav]

It introduces confussion between users

This will be handled by the imminent renaming to "File associations".

and it's not convenient having different MIME plugins for every plugin (ie. wxSmith) that needs extension file handling.

wxSmithMime, as every future MIME plugin, has no configuration. It just handles *.wxs files by opening the form for editing. That's the point. The default handler asks the user what to do, maps extensions to actions etc. Other MIME plugins must not do that. Just handle what they 're capable of handling...
So, I don't think "convenient" applies here since you won't ever know about these plugins (other than seeing them in the list).

And, what happens if you disable the Default MIME plugin?
Well, I have a personality of C::B that doesn't load any plugin.

So it's weird that I can open .h/.cpp files, but if I try to open a .txt or any other file, nothing happens, no question nor message box.

Well, I see your point about .txt files and it would make sense to open .txt files in the editor by default, without asking. But anything more than that and the editor won't know what to do with the file.

Either all MIME handling is done by plugins or they all must enter the SDK (highly inconvenient, not to mention hard to extend).
A single call to PluginManager::GetMimeOffers() (IIRC) returns all available MIME handlers (of type cbMIMEPlugin). If DefaultMIMEHandler went into the SDK, it wouldn't be a cbMIMEPlugin anymore so what gives?

[takeshimiya]

I agree that plugins must handle what to do with the files, and not the SDK.

But what I'm refering is having in the SDK a 'file extensions binder'.

For example, now we have key shortcut bindings.
Well, the SDK could provide a 'file extensions binder' on which the user can select what to do with that extension.
ie.
*.txt Open in cbEditor
*.cpp Open in cbEditor
*.xrc Open in wxSmith
*.rc Open in external tool

That's for the SDK part (let's call it MimeManager).

And then the MimeManager would notify the plugins (ie. wxSmith) that are associated with that extension, so they can do whatever they want with it.

It is understandeable?

[280Z28]

Something to consider is files that don't have extensions might still need highlighting (makefiles). Files with the same extension might need different highlighting (.conf files for different programs). I'm still thinking of a way to do this.

[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.