Re: [Development] Let's discuss QPluginManager
On 20 Jan 2012, at 12:57, ext Mathias Hasselmann wrote: Hi, Qt nicely supports extending applications and libraries via plugins, still in my opinion one major building block is missing: Some reusable object which iterates the shared object files in relevant plugin folders and returns all instances implementing a given set of interfaces. This seems a pretty common task. Just had to think about implementing such a thing today. Yes, once again. Actually rather wondered from where to copy-and-paste it: I've stopped counting how many of them I touched during the last two years. Something that's even worse than the need of copy-and-paste: Most of them were created with some kind of ad-hoc mentality, so of course most of them are highly inefficient, if not even plainly broken. Hope you still reading and got somewhat hooked. Also hope you agree we need something like QPluginManager, so let's discuss the feature set it should have: 1. Iterate relevant plugin folders to find plugins implementing a given set of QObject interfaces. 2. Introspect as few plugin files as possible to keep application startup time low. This could be done by caching the interfaces each plugin file provides. 3. Do we need meta informations like vendor name, description or dependencies? Think of QtCreator's .pluginspec files. Once we figured out the needed feature set, we should figure out how to implement the object. Most importantly: Is there some code, are there some specifications we could reuse? Guess this should be enough to get the discussion started. The plugin manager of Qt Creator might be a good starting point. It has been created with the possibility in mind that this might be of more general interest, and should have no dependency on Qt Creator itself. * iterates directories for plugin specification files, that describe plugins to be loaded, their license, vendor, description, webpage, etc * plugin dependencies versioning * plugins can register for command line arguments * plugin life cycle management * object registry where objects implementing (qobject based) interfaces can be registered, and retrieved by type, object name and type name. Br, -- Eike Ziller Principal Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Let's discuss QPluginManager
On 23 Jan 2012, at 10:58, ext eike.zil...@nokia.com wrote: On 20 Jan 2012, at 12:57, ext Mathias Hasselmann wrote: Hi, Qt nicely supports extending applications and libraries via plugins, still in my opinion one major building block is missing: Some reusable object which iterates the shared object files in relevant plugin folders and returns all instances implementing a given set of interfaces. This seems a pretty common task. Just had to think about implementing such a thing today. Yes, once again. Actually rather wondered from where to copy-and-paste it: I've stopped counting how many of them I touched during the last two years. Something that's even worse than the need of copy-and-paste: Most of them were created with some kind of ad-hoc mentality, so of course most of them are highly inefficient, if not even plainly broken. Hope you still reading and got somewhat hooked. Also hope you agree we need something like QPluginManager, so let's discuss the feature set it should have: 1. Iterate relevant plugin folders to find plugins implementing a given set of QObject interfaces. 2. Introspect as few plugin files as possible to keep application startup time low. This could be done by caching the interfaces each plugin file provides. 3. Do we need meta informations like vendor name, description or dependencies? Think of QtCreator's .pluginspec files. Once we figured out the needed feature set, we should figure out how to implement the object. Most importantly: Is there some code, are there some specifications we could reuse? Guess this should be enough to get the discussion started. The plugin manager of Qt Creator might be a good starting point. It has been created with the possibility in mind that this might be of more general interest, and should have no dependency on Qt Creator itself. * iterates directories for plugin specification files, that describe plugins to be loaded, their license, vendor, description, webpage, etc * plugin dependencies versioning * plugins can register for command line arguments * plugin life cycle management * object registry where objects implementing (qobject based) interfaces can be registered, and retrieved by type, object name and type name. https://qt.gitorious.org/qt-creator/qt-creator/trees/master/src/libs/extensionsystem http://doc.qt.nokia.com/qtcreator-extending/creating-plugins.html (fwiw) -- Eike Ziller Principal Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Let's discuss QPluginManager
On Fri, Jan 20, 2012 at 7:38 PM, Artur Souza (MoRpHeUz) artur.so...@openbossa.org wrote: Another feature related to plugins that KDE implemented and I find it very useful and elegant is KPluginFactory: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/kdecore/util/kpluginfactory.h In addition to plugins which provide non-visual features, what about something like KParts that could be embedded in applications? Some guidelines to avoid ABI problems might be needed, but I think this is a good opportunity to create a marked for 3rd-party companies developing components. It's huge in Delphi and .NET and I have always wondered why it does not really exist in the Qt world. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Object destruction in QML 2
Hi I've done a patch for https://bugreports.qt.nokia.com/browse/QTBUG-23451 and I've faced an interesting problem. The bug says that the changed signal is not raised when an Item property is pointing to a dynamic object and this object gets destructed (changing the value of the Item property to null). My first patch works perfectly on QtQuick 1.1 ( https://qt.gitorious.org/~thiagolacerda/qt/thiagolacerdas-qt/commit/89ee5315e3739d36cd2b9feb958a6f48df0130da ), but when I test it with QtQuick 2.0 the Item property assumes a intermediate value, instead of changing directly to null it first gets undefined value and then changes to null. Then, by investigating the code, I've seen that in src/declarative/qml/v8/qv8qobjectwrapper.cpp, at v8::Handlev8::Value QV8QObjectWrapper::newQObject(QObject *object) method, this condition exists: if (QObjectPrivate::get(object)-wasDeleted) return v8::Undefined(); This is causing the undefined value of the property when the value of the property is retrieved between the destroy function call and the real destruction of the object. I think this can cause some strange behaviors on the applications developed using QtQuick. Why don't just return the null value, since we know that this object was destructed and won't be available to the user anymore? For that, I've updated my patch and submitted to gerrit as a Qt5 issue correction (http://codereview.qt-project.org/#change,13986) Cheers -- Thiago de Barros Lacerda OpenBossa - INdT ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On 1/23/12 10:42 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: On Monday, 23 de January de 2012 21.21.13, John Layt wrote: On Wednesday 18 Jan 2012 00:47:31 you wrote: * If we can port the QLocalePrivate number routines to call ICU instead of their current implementations, the rest of Qt will just work, Small wrinkle just turned up here, ICU only does parse/format for base 10 numbers and not for binary, octal or hex, which is technically correct as they are not localised formats, but it's a pain none-the-less. Because QLocale, QByteArray, QString and QTextStream offers the base option in the public API, we will need to keep the existing code to do it. If the requested parse/format is for base 10 then we'll pass it to ICU, otherwise we'll use the current code. We will just need to document the behaviour that other bases will always use the standard digits and not the local one. You mean QLocale and QTextStream. I am very tempted to simply break this. localized binary numbers simply don't make any sense. Cheers, Lars QByteArray and QString do not need ICU since they are locale-independent. Parse LC_ALL=C in them only. It's also a good idea to keep that code for when QT_NO_LOCALE is in effect. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New QUrl implementation
On 1/23/12 6:47 PM, ext David Faure fa...@kde.org wrote: On Wednesday 28 December 2011 16:43:10 David Faure wrote: On Tuesday 27 December 2011 12:24:23 Thiago Macieira wrote: On Tuesday, 27 de December de 2011 13.42.10, David Faure wrote: On Friday 23 December 2011 17:22:38 Thiago Macieira wrote: QUrl: Always lowercase the scheme Change-Id: I8d467014d22384f1be15fdd746e20b1153a82a4e Do we want this? I think so. I would say yes, too. This simplifies the checks in application code. PS: great work on QUrl! Isn't this going to go to gerrit for review before merging? I'm surprised that this is in gitorious branches for now, but I suppose that's because topic branches don't really work there iirc. I'm not allowed to submit to Gerrit. I can only publish as open source. Hmm, so what now? How do we get this into Qt? (I suspect that this is a touchy legal issue I probably shouldn't dig into, but this has a huge effect on kde frameworks 5, so I need to know if this is going to be solved...) After more discussion with Thiago, it turns out that Intel still hasn't signed the CLA that would allow him to contribute to Qt, which is why this work is blocked at the moment. It looks like this might take a while still, but we really need these changes into Qt. If this is delayed too much, we won't be able to get it in at all, after the SC freeze. So I have a proposal to make: how about I make the API and behavior incompatible changes now, while there's still time, so that later on Thiago can still commit his work even after the api freeze? In concrete terms, the plan would be that I change the non-encoded methods, like toString and the QUrl(QString) constructor, so that they work on partially-encoded data. This would fix the long-standing issue that toString() is basically unusable, except for displaying to the user in non-editable format. If a file contains a '#' in the name, toString doesn't escape it, so if that string is given back to a QUrl, it won't be parsed correctly. Thiago's code rewrites the whole qurl internals, but as a short-term solution to get the API and behavior in place, I could just drop the QString members in the current Private, and pass the encoded form through some pretty decoding code. This would be slower, but the behavior would be fixed, and we can make it faster later. After that we can deprecate all the encoded methods, but that in itself doesn't need to be done before the freeze, does it? It's SC/BC technically, like any deprecation that will happen for 5.1 or later. I would prefer not to have to do this redundant work, but it seems like a better solution than having to live with Qt4's QUrl for the whole life time of Qt 5 (which also means keeping a KDE layer on top, to fix these issues, but I really want to get rid of that). Sounds ok to me, even though I hate seeing the duplicated work happen. Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
