| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
It would be useful to have a OS specific QDir::Plugins filter to allow easy selection of plugin candidates on the various OSes. AFAICS at the moment, code to select plugins must be hand-rolled specifically on each OS. -- [ signature omitted ]
Stephen Collyer wrote: > It would be useful to have a OS specific QDir::Plugins > filter to allow easy selection of plugin candidates on > the various OSes. AFAICS at the moment, code to select > plugins must be hand-rolled specifically on each OS. For the record, I notice that this can also be achieved by using the QLibrary::isLibrary() method which has the relevant logic already hardcoded. -- [ signature omitted ]
Stephen Collyer wrote: >It would be useful to have a OS specific QDir::Plugins >filter to allow easy selection of plugin candidates on >the various OSes. AFAICS at the moment, code to select >plugins must be hand-rolled specifically on each OS. I think that you should obtain a list of available plugins from somewhere more trustworthy than a directory listing. Or, if you know your directory to contain only your plugins (and none else, especially not older versions linking to older libraries), then you already know that all files are plugins. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira wrote: > Stephen Collyer wrote: >> It would be useful to have a OS specific QDir::Plugins >> filter to allow easy selection of plugin candidates on >> the various OSes. AFAICS at the moment, code to select >> plugins must be hand-rolled specifically on each OS. > > I think that you should obtain a list of available plugins from somewhere > more trustworthy than a directory listing. I can't think of anywhere more trustworthy than a directory listing. I assume you're suggesting that an app should implement some kind of plugin registry ? If so, that strikes me as a bad idea in general. 1. It requires extra code with the possibility of extra bugs. 2. It requires that the registry be populated. Who does this ? The user ? If so, it's extra work for the user. 3. It requires that the registry and the directory contents be synchronized. This is a pain, in general. What happens if the registry claims that a plugin exists but it's not found in the directory ? More hassle for the user, more code, more error logic. OTOH, if we implement a plugin architecture by embedding sufficient identifying data in the plugin itself, we can avoid the need for any user intervention, for code for plugin registeries, for error messages when the registery and the directory are out of step. When we want to add a plugin, we install a single file into the appropriate directory, and the app. detects it as start-up, and makes it available to the user without any further intervention required by the user. If we remove (accidentally or by design) the plugin file, then the app. automatically detects this, with no need to worry itself or the user about the registery being out of sync with the actual plugin configuration. Of course, if you were thinking of something else, ignore everthing above :-) > Or, if you know your directory > to contain only your plugins (and none else, especially not older > versions linking to older libraries), then you already know that all > files are plugins. No. You *hope* that all files are plugins. Who says that someone or something didn't screwup and put a Word file there by mistake, or an older version of the plugin. You still need to interrogate the files to decide if a) they are in fact genuine plugins (which functionality is supported by Qt) and b) that you actually want to use any particular plugin (which functionality is app. specific) -- [ signature omitted ]