I agree with Lars. I think we need two tools - one for determining mime types (qmime) which fully accords to freedesktop.org specification and second for settings default application for file path or mime type.
First tool should be platform independent, and second should behave natively, possibly use native database. Structure of the second tool is out scope of this thread. 22.09.2011, в 10:46, <[email protected]> <[email protected]> написал(а): > On 9/21/11 5:09 PM, "ext Wolf-Michael Bolle" > <[email protected]> wrote: > >> On Wednesday 21 September 2011 15:19:59 ext Иван Комиссаров wrote: >> >>> I explored native mime database in Windows. It is stored in registry and >>> contains data for most common extensions. It is a map from "*.extension" >>> to mime type name. This mime type name is equal to freedesktop.org, >>> however for most of types it is not set. >> >> I wouldn't be surprised if those mappings are added during the >> installation of >> applications. >> >>> So, if we will try to generate database from registry, this database >>> will >> not be complete. >> >> Why do we need to duplecate the database? >> >>> Next problem i couldn't find description and icon for mime types. Are >>> they >> missing? >> >> The file properties dialog is able to show that kind of information. >> Also, when >> I install the VLC media player all mp3 icons change. >> >>> And the last problem that we lose feature of determining mime type by >>> content (i didn't find any magic matchers in registry too). >> >> Would it be an option for platforms to not support that? >> >>> Also we have to forgot about aliases. >> >> Then the Windows platform will not return aliases. No problem. >> >>> We need to have single behavior of a database on all platforms - >> >> I actually disagree. I believe an application needs to perform natively. >> >>> in particular, we need to have same mime types names. >> >> I actually believe that if a platform natvely calls a MIME type something >> else >> than freedesktop.org then we should mess with that. What is worse than an >> application that is behaving different than every other application on >> that >> platform? >> >>> Aliases and content-type spelling will give you headache. >>> >>> I'm not sure what about other systems that Qt supports, but i think we >>> can't use native database - it is very poor on win >> >> So be it then. Or, the implementation for the Windows platform could use >> the >> freedesktop.org database and map back the MIME type names. >> >>> and i'm not sure it exists on Symbian (correct me, if i'm wrong). >> >> I honestly don't know yet (I'm still in the process of determining that). >> Still, I believe we should leave embedded platforms with ways to preserve >> precious flash memory. >> >>> Until we can be sure that we can retrieve ALL information about mime >>> types, >>> including localized comments and icons (on mac and win) i suggest to use >>> freedesktop.org specification on all systems. >> >> I vote against that. >> >>> If we will use freedesktop.org spec, we need to use rather Qt installer >>> to >>> install mime database or we have to support embedding files in >>> application >>> directory. I think storing mime types with application should be very >>> frequent use case on windows, because we only need small subset of mime >>> types specific for given application. Also it is common way to deploy >>> applications on win - to deploy all tools they depends on with >>> application. >> >> Do we really want to re-implement OS functionality? The VLC media player >> - a >> Qt based application - for example would have to register first with >> Windows >> and then with Qt? That doesn't sound very appealing. > > I agree with you when it comes to registering apps as handlers for > mimetypes. But the more generic extension -> mimetype and file > content/magic -> mimetype mapping could most likely be handled with 100% > platform independent code. > > Cheers, > Lars _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
