Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
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 :P)
mandrav:
--- Quote from: Takeshi Miya on December 08, 2005, 02:28:16 pm ---It introduces confussion between users
--- End quote ---
This will be handled by the imminent renaming to "File associations".
--- Quote from: Takeshi Miya on December 08, 2005, 02:28:16 pm --- and it's not convenient having different MIME plugins for every plugin (ie. wxSmith) that needs extension file handling.
--- End quote ---
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).
--- Quote from: Takeshi Miya on December 08, 2005, 02:28:16 pm ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version