[Development] File chooser dialog as a Qt Component - API design
Hi all! I really miss a QML version of QFileDialog. There currently isn't a Qt Component for choosing a file or a directory from the filesystem, and I think we should fill this gap ASAP. There's a bug I created to keep track of this: https://bugreports.qt-project.org/browse/QTCOMPONENTS-1242 Now I'd like to start discussing the API design for such a component, so I've added a comment to that bug with a proposal. I would appreciate if you have a look at it, and tell me if it's sane. :-) I'm working on a MeeGo implementation of it right now, but I will also need a desktop version eventually. Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Documentation bug maintenance
Hi all, Thiago mentioned some time ago that all bugs that nobody is working on should be set to Unassigned. Therefore I would like to propose that the QTBUG Documentation component and QTWEBSITE doc.qt.nokia.com component set the assignee to Unassigned by default to allow anyone in the community to work on them. It seems like the Documentation component assignee is set to Qt Documentation Team and I think this is not valid anymore, unless we get a public mailing list where all of the bug emails for this user are sent to. The default assignee for doc.qt.nokia.com seems to be a user who does not work in the Qt Documentation Team anymore. I created the following JIRA dashboard: https://bugreports.qt-project.org/secure/Dashboard.jspa?selectPageId=11521 It lists most of the currently open bugs that are related to documentation (I'm not checking for things like docs since that might not be valid). There are almost 900 bugs there which should be triaged by the community. Casper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On Monday 23 Apr 2012 22:17:15 John Layt wrote: For Mac I propose moving QCocoaPrinterSupport into plugins/printsupport/cocoa and moving the private methods from QCocoaNativeInterface to QCocoaPrinterSupportPlugin. I'll do a patch. A harder question is where QMacPrintEngine should be, should it go to plugins/printsupport/cocoa, or to printsupport/kernel like the current Windows and Cups implementations? The QMacPrintDialog could have the same question, does it belong in plugins/printsupport/cocoa, or to printsupport/dialogs? I'm inclined to have all the platform specific code in the plugin if possible, and change Windows and Cups to match. Hi, Well I've tried doing this and ended up moving QCocoaPrinterSupport, QQMacPrintEngine and QCoreGraphicPaintEngine all into the the printsupport plugin as they are all only used by QtPrintSupport, and as the plugin returns the native QPrintEngine as its main purpose so it seems logical. Unfortunately, QCoreGraphicsPaintEngine needs to link against the Cocoa platform plugin to use classes/methods in QCocoaAutoReleasePool and QCocoaHelpers, but I can't figure out how to do that in qmake. QtGui and QtWidget both use these classes/methods as well, but I can't figure out how they are linking against the Cocoa plugin. Any hints on linking qtcocoa into cocoaprintersupport, or is that just not possible? Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
