Re: [Development] Calendar Systems proposal
Edward Welbourne wrote: > Soroush Rabiei >> 3. Number of months in all years are fixed. > > Is there no lunar calendar with occasional extra months ? Of course there is. Any lunar calendar adjusted for consistency with the solar year necessarily has occasional intercalar months. The Jewish calendar is the most prominent example. (The Islamic calendar, on the other hand, is the most prominent example of a lunar calendar that is NOT adjusted for the solar year, which explains why e.g. Ramadan rotates all over the solar year over the years.) Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New library in qtbase
> On 6 Dec 2016, at 15:44, Shawn Rutledge wrote: > > >> On 3 Dec 2016, at 00:36, Kevin Kofler wrote: >> >> Shawn Rutledge wrote: >>> http://www.galago-project.org/about.php >>> >>> sounds like it’s just for “presence” to tell instant-messaging clients >>> whether you are using the computer or not. >> >> I did not suggest you use the Galago software, just this specification: >> https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html >> older versions of which were hosted on: >> http://www.galago-project.org/specs/notification/ >> (which is how it came to be known as the "Galago (notification) spec”). > > That page doesn’t mention Galago. Anyway org.freedesktop.Notifications is > the specification we are already using in qtbase/src/platformsupport/dbustray. > > But we know that increasingly notifications are being used independently from > tray icons, and that basically every platform has some kind of notifications, > so maybe we’ll end up with another Qt API for that eventually. It’s > unintuitive that if you only want to show notifications but don’t need a tray > icon, you have to use QSystemTrayIcon::showMessage(). > >> If you want to use an existing library, libnotify is what you are looking >> for: >> https://developer.gnome.org/libnotify/ > > Well why should Qt depend on another library which does the D-Bus > communication in its own way, when we already have Qt D-Bus? > >> All these are GNOME URLs, but the protocol is also supported by KDE Plasma >> and by other desktop environments: >> https://wiki.archlinux.org/index.php/Desktop_notifications > > Yeah, that was the idea of implementing it that way, to get it working on > Gnome and Ubuntu and KDE. > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Hi guys, Thanks for the suggestions provided. However this is now derailing the thread’s original purpose: decide where the notification related stuff should go. Short summary, we have three possibilities: 1) Own module (and current implementation) 2) One “core" module and one GUI module to separate concerns for system not requiring a GUI connection (Jake’s suggestion) 3) Put everything in QtGui and implement the stuff in the QPA parts with the implication that a QGuiApplication will be required. Can we come to an agreement about which one to implement ? Note that creating a completely separated module (meaning out of qtbase) is not an option since one of the goal beside providing our fellow developers an easy to use API is to replace the current QSystemTrayIcon code with the use of that module and it wouldn’t make sense to have qtbase depending on an external module. Just to be clear, we are talking here about local notifications not push notifications. That’s another subject with other requirements. Thanks, Samuel signature.asc Description: Message signed with OpenPGP ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Source break policy for function overloads
On 2016-07-13 23:55, Lars Knoll wrote: On 13 Jul 2016, at 20:10, Marc Mutz wrote: [...] It should also be noted that there are two categories of SiCs: a. those that can be fixed client-side without breaking compat with older Qt versions, and b. those which cannot IMO, SiCs of type (a) are acceptable, those of type (b) are obviously no-no's. Adding an overload (both cases: 1 + 2 above) is type (a), so is acceptable. Adding explicit to a ctor that should have been but wasn't is also SiC Type (a). In these cases, code that breaks is code that deserves to be broken, because it was brittle. Renaming a public inline function of a non-exported class is BC, but SiC Type (b), so not acceptable. I think Marc has summed it up very nicely. This is IMO exactly the policy we should apply. QUIP 6 has been created from this: https://codereview.qt-project.org/182311 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9
On Fri, Jan 13, 2017 at 01:58:45AM +, Stottlemyer, Brett (B.S.) wrote: > On 12 January 2017 at 08:39, Lars Knoll wrote: > >* The module solves a problem our users have > > - It either implements new and so far non existent functionality > > - Or it solves an existing problem in a new and better way (and is > > intended to replace the old functionality over time) > > It seems like the two potentially competing current projects are Qt Service > Framework and QtDBus. I believe QtRO is > different from both, with “better” being subjective. At the risk of being > flamed for why I prefer QtRO, I’d put it > this way: > > The Qt Service Framework deals with OS Services/daemons, and only works > inter-process, not inter-device. If I can > distinguish between a service and a Service, Service being a different class > than a program (I.e., on windows, services > run when no user is logged on). If you need a Service, the Service Framework > makes sense. This isn’t the problem > QtRO is trying to solve. > > QtDBus is more similar in intent to QtRO. QtRO is peer-to-peer, while Dbus > by default goes through a daemon. Bus is > common on Linux platforms, but has additional dependencies on other platforms > (Windows, QNX, etc). The key difference > though, is that DBus is intended to translate between languages (java, C, > python). This is a disadvantage of QtRO > in many cases, but when Qt is available for both client/server, it provides a > much richer level of communication. For > instance, QtRO supports QAIM, including selection, across processes/devices. > It supports state (current PROPERTY > values). It supports any type Qt can (or can be made to) pass in Queued > connections. Without additional code. > > My view is that QtRO complements the other two options, providing strong > benefits for the right use-cases. > for my taste, there are way too many inconclusive/irrelevant details in this description. a more layer-oriented approach would be more convincing imo: qtdbus is a pure rpc layer. qtro is a distributed object layer which builds on top of rpc. signals and slots are exposed rpc. no idea whether you implemented property propagation on top of generic rpc or via a dedicated protocol part, but that's just an implementation detail. it would be perfectly feasible to implement qtro over qtdbus (networked dbus has been on the table for a decade; dunno if somebody ever pulled it off). qtserviceframework is a registration/management layer on top of (local) rpc. its intended use appears to be more the creation of platforms rather than applications, which might explain why it's now bitrotting. ;) it appears to me that it would be possible to build it on top of a higher-level representation like qtro, but principally it's indeed rather orthogonal. from a purely design perspective, it would seem optimal to have a QtRpc system of which QtDbus provides a concrete implementation, while QtRo would be the state extension building on top of it. this would imply multiple inheritance for an actual instance of qtro. the principal advantage of this would be a shared idl and surrouding tooling, which would reduce redundancy on the implementation side. otoh, we have the existing implementations, and in particular qtdbus really isn't at a point where it could be just redesigned. we can't drop the existing qtdbus-xml, and it would be sado-maso to make .rep an extension of that format. a more realistic appoach would be having qtdbus as an "invisible" backend implementation of the generalized qtrpc. note that qtserviceframework has some of this, which is probably why alex considered it relevant in the first place. so a concrete action point would be investigating in how for it's possible (and actually sensible) to factor out the rpc layer (including the underlying transport layer, obviously). it's not really clear to me why you're apparently discarding the idea of integrating qtro with other object distribution frameworks at the outset. the systems really aren't fundamentally different, and providing such integrations may significantly improve qtro adoption where a system is already established (or is being prescribed). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Soroush Rabiei > Sorry for being noisy on this list, but I think we have several issues > needed discussion before going further. I should note that Lars still holds to the view that we should keep this out of QDate: which seems to imply roughly just upstreaming KCalendarSystem, albeit with the opportunity to make any improvements we want in the process. > First we have a design decision to make, the minimal set of > assumptions on calendaring systems. According to my minute research we > can assume following facts on every calendar that is in-use: > > 1. All calendaring systems, show dates in three levels: Year, Month and Day > 2. The week is 7 days. It may start at any of these days. French revolutionary calendar: https://en.wikipedia.org/wiki/French_Republican_Calendar Not that I propose supporting it ! However, it would be best to design a system which doesn't preclude someone else implementing it. If we can avoid hard-coding the assumption of a seven-day week, so much the better. > 3. Number of months in all years are fixed. Is there no lunar calendar with occasional extra months ? > Please let me know about any problem. > > Second issue is on CLDR data. I was all mistaken about CLDR. The new > versions (including v29) include month name data for many calendars > (Gregorian, Buddhist, Chinese, Coptic, Dangi, Ethiopic, Hebrew, > Indian, Islamic, Japanese and Persian). I managed to modify the > scripts (cldr2qlocalexml.py and qlocalexml2cpp.py) to prepare data for > Jalali calendar (named as Persian in CLDR terminology). On the other > hand, QLocale integration is completed. Now there is `months_data_per' > array in qlocale_data_p.h and it's working well. > > The problem however, is that this data is bigger than what I had in > mind. Apparently there are many communities using Jalali calendars. > There are strange month names for Korean, Russian, Turkish and several > more. (I was expecting data only for Persian and Afghani languages, > maybe Tajik too...) The array containing month names is 2419 bytes. > There is also another 6*2=12 bytes per locale in locale's index table. > considering number of supported locales in qt, we will have 552 * 12 = > 6624 bytes there and as a result the overhead in Qt's binary, will be > 9.043 KB only for Jalali calendar. Islamic civil calendar is almost > three times bigger if I'm not much mistaken, and I have no idea about > other calendars. I guess adding five calendars will blow QtCore up to > 5~7 Megabytes. Not something we want to impose on all users of Qt. > I have changed qlocalexml2cpp.py such that it generates data for each > calendar in a separate array. So it can be excluded by preprocessor > directives. My suggestion is to make calendaring support, > configurable, and provide data only for Gregorian calendar by default. > And also we can give users the option to choose among locales they > want to include in their builds: > > ./configure -developer-build -opensource -confirm-license -debug > -calendars gregorian,persian,islamic_civil That sounds reasonable. Another approach might be to design a plugin-based architecture - with similar config, but controlling which plugins get built. This would make life easier for anyone who wants to add a calendar system we don't support: they'd just need to add their plugin to wherever we put ours. Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Sorry for being noisy on this list, but I think we have several issues needed discussion before going further. First we have a design decision to make, the minimal set of assumptions on calendaring systems. According to my minute research we can assume following facts on every calendar that is in-use: 1. All calendaring systems, show dates in three levels: Year, Month and Day 2. The week is 7 days. It may start at any of these days. 3. Number of months in all years are fixed. Please let me know about any problem. Second issue is on CLDR data. I was all mistaken about CLDR. The new versions (including v29) include month name data for many calendars (Gregorian, Buddhist, Chinese, Coptic, Dangi, Ethiopic, Hebrew, Indian, Islamic, Japanese and Persian). I managed to modify the scripts (cldr2qlocalexml.py and qlocalexml2cpp.py) to prepare data for Jalali calendar (named as Persian in CLDR terminology). On the other hand, QLocale integration is completed. Now there is `months_data_per' array in qlocale_data_p.h and it's working well. The problem however, is that this data is bigger than what I had in mind. Apparently there are many communities using Jalali calendars. There are strange month names for Korean, Russian, Turkish and several more. (I was expecting data only for Persian and Afghani languages, maybe Tajik too...) The array containing month names is 2419 bytes. There is also another 6*2=12 bytes per locale in locale's index table. considering number of supported locales in qt, we will have 552 * 12 = 6624 bytes there and as a result the overhead in Qt's binary, will be 9.043 KB only for Jalali calendar. Islamic civil calendar is almost three times bigger if I'm not much mistaken, and I have no idea about other calendars. I guess adding five calendars will blow QtCore up to 5~7 Megabytes. I have changed qlocalexml2cpp.py such that it generates data for each calendar in a separate array. So it can be excluded by preprocessor directives. My suggestion is to make calendaring support, configurable, and provide data only for Gregorian calendar by default. And also we can give users the option to choose among locales they want to include in their builds: ./configure -developer-build -opensource -confirm-license -debug -calendars gregorian,persian,islamic_civil Cheers, Soroush ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtIcoHandler
FYI, I'm tinkering with writing .ico files and tried to visualise the result on Linux, which gave me an error message: %> gwenview5 test.ico QImageReader::read() using format hint "ico" failed: "Unknown error" A bad Qt image decoder moved the buffer to 22 in a call to canRead()! Rewinding. Image format is actually "ico" not "ico" This is with Qt 5.7.1 , and it happens with ico files created by QtIcoHandler itself, and with the 3rd party icotool utility. The number of icons in the file makes no difference. Is this a bug? R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reusing Qt code (or: saving .ico files)
Александр Волков wrote: > 13.01.2017 13:58, Александр Волков пишет: >> 13.01.2017 13:52, Konstantin Tokarev пишет: >>> Why not just use QImageWriter? >> QImageWriter doesn't support wrting miltiple images into one file. >> > > Possible fix: https://codereview.qt-project.org/#/c/182255/ Yep, that should do the trick: QtIcoHandler always supported writing multiple images, it was just not exposed through the QImageWriter API. Qt is late to catch up with the animage GIF hype! ;) R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reusing Qt code (or: saving .ico files)
On Friday January 13 2017 13:52:36 Konstantin Tokarev wrote: >Why not just use QImageWriter? Because it doesn't append but writes only a single image, the 1st image in the sequence, suprisingly (and I presume not just on Friday the 13th :)) ? R ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.8 rc snapshot for testing
Hi, Slight correction: It's not a regression against 5.7, but it is still a regression [☹] . I'll fix it ASAP for 5.8.1 and back-port it also to the 5.6 branch. Simon From: Development on behalf of Simon Hausmann Sent: Friday, January 13, 2017 1:23:47 PM To: Ben Lau; Tim Blechmann Cc: development@qt-project.org; releas...@qt-project.org Subject: Re: [Development] New Qt 5.8 rc snapshot for testing Hi, While I agree that this (58133) is a bug, I would not classify it as a bug to halt the entire release. It's neither a regression or a particularly common scenario to run into, I would argue. That said, it's a crash, it needs fixing and I'll fix it. Simon From: Development on behalf of Ben Lau Sent: Friday, January 13, 2017 11:38:05 AM To: Tim Blechmann Cc: development@qt-project.org; releas...@qt-project.org Subject: Re: [Development] New Qt 5.8 rc snapshot for testing On 13 January 2017 at 14:15, Tim Blechmann mailto:t...@klingt.org>> wrote: > All known blockers should be fixed in these packages and we are > targeting to release Qt 5.8.0 Tue 17^th January if nothing really > serious found during testing. So please inform me immediately if there > is some new blocker in the packages. QTBUG-56163 is the main blocker for me, which prevents me from migrating to qt-5.8. have already reported it 3 months ago and requested it via the commercial support. thanks a lot, tim I just submitted QTBUG-58133 on yesterday. It will make applications that use QuickFlux crash when passing a signal with QJSValue (isUndefined == true) via a C++ class to QML. https://bugreports.qt.io/browse/QTBUG-58133 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.8 rc snapshot for testing
Hi, While I agree that this (58133) is a bug, I would not classify it as a bug to halt the entire release. It's neither a regression or a particularly common scenario to run into, I would argue. That said, it's a crash, it needs fixing and I'll fix it. Simon From: Development on behalf of Ben Lau Sent: Friday, January 13, 2017 11:38:05 AM To: Tim Blechmann Cc: development@qt-project.org; releas...@qt-project.org Subject: Re: [Development] New Qt 5.8 rc snapshot for testing On 13 January 2017 at 14:15, Tim Blechmann mailto:t...@klingt.org>> wrote: > All known blockers should be fixed in these packages and we are > targeting to release Qt 5.8.0 Tue 17^th January if nothing really > serious found during testing. So please inform me immediately if there > is some new blocker in the packages. QTBUG-56163 is the main blocker for me, which prevents me from migrating to qt-5.8. have already reported it 3 months ago and requested it via the commercial support. thanks a lot, tim I just submitted QTBUG-58133 on yesterday. It will make applications that use QuickFlux crash when passing a signal with QJSValue (isUndefined == true) via a C++ class to QML. https://bugreports.qt.io/browse/QTBUG-58133 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reusing Qt code (or: saving .ico files)
On Friday January 13 2017 14:01:10 Konstantin Tokarev wrote: Hi, > Alternatively you can import QtIcoHandler from Qt 5.6 which is licensed as > LGPL 2.1 Thanks, that'd be easy, only the license is different, nothing else :) > Why not just use QImageWriter? I understand from CodeReview 182255 that I'd have to call QImageWriter::write() for each individual image? If that works cross-platform it would evidently be better. R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reusing Qt code (or: saving .ico files)
13.01.2017 13:58, Александр Волков пишет: 13.01.2017 13:52, Konstantin Tokarev пишет: Why not just use QImageWriter? QImageWriter doesn't support wrting miltiple images into one file. Possible fix: https://codereview.qt-project.org/#/c/182255/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reusing Qt code (or: saving .ico files)
13.01.2017, 13:29, "René J.V. Bertin" : > Hello, > > Can someone please have a look at the KDE RR below and tell us whether or not > it's OK to include qicohandler.* the way I propose in the patch under review? > There are some whitespace changes and I added a preprocessor token to exclude > ico read support. > My understanding of the GPL legalese is that it should be OK but Christoph is > right that we have to double-check. Your ksvg2ico.cpp is licensed as LGPL 2.1 or 3, while QtIcoHandler is licensed as LGPL3, so combined work cannot be used as LGPL 2.1. If these is fine, I don't see any problems here (but IANAL) Alternatively you can import QtIcoHandler from Qt 5.6 which is licensed as LGPL 2.1 > > Maybe we all overlooked something and there is another way to create .ico > files, without needing to use (and thus include) QtIcoHandler explicitly? I > see that the relevant QtBase code is built on Linux and Mac but I cannot tell > whether it is also installed (the header isn't in any case). > > Thanks, > René > > --- > Forwarded message: > Date: Friday January 13 2017 > From: Christoph Feck > Subject: Re: Review Request 129807: proposal: add ksvg2ico > > https://git.reviewboard.kde.org/r/129807/#review101968 > > Someone more experienced with legal matters should review the verbatim > inclusion of Qt code; in particular the license header. > > - Christoph Feck > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reusing Qt code (or: saving .ico files)
13.01.2017 13:52, Konstantin Tokarev пишет: Why not just use QImageWriter? QImageWriter doesn't support wrting miltiple images into one file. I wonder is there a bugreport for it? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Reusing Qt code (or: saving .ico files)
13.01.2017, 13:29, "René J.V. Bertin" : > Hello, > > Can someone please have a look at the KDE RR below and tell us whether or not > it's OK to include qicohandler.* the way I propose in the patch under review? > There are some whitespace changes and I added a preprocessor token to exclude > ico read support. > My understanding of the GPL legalese is that it should be OK but Christoph is > right that we have to double-check. > > Maybe we all overlooked something and there is another way to create .ico > files, without needing to use (and thus include) QtIcoHandler explicitly? I > see that the relevant QtBase code is built on Linux and Mac but I cannot tell > whether it is also installed (the header isn't in any case). Why not just use QImageWriter? > > Thanks, > René > > --- > Forwarded message: > Date: Friday January 13 2017 > From: Christoph Feck > Subject: Re: Review Request 129807: proposal: add ksvg2ico > > https://git.reviewboard.kde.org/r/129807/#review101968 > > Someone more experienced with legal matters should review the verbatim > inclusion of Qt code; in particular the license header. > > - Christoph Feck > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.8 rc snapshot for testing
On 13 January 2017 at 14:15, Tim Blechmann wrote: > > All known blockers should be fixed in these packages and we are > > targeting to release Qt 5.8.0 Tue 17^th January if nothing really > > serious found during testing. So please inform me immediately if there > > is some new blocker in the packages. > > QTBUG-56163 is the main blocker for me, which prevents me from migrating > to qt-5.8. have already reported it 3 months ago and requested it via > the commercial support. > > thanks a lot, > tim > I just submitted QTBUG-58133 on yesterday. It will make applications that use QuickFlux crash when passing a signal with QJSValue (isUndefined == true) via a C++ class to QML. https://bugreports.qt.io/browse/QTBUG-58133 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Reusing Qt code (or: saving .ico files)
Hello, Can someone please have a look at the KDE RR below and tell us whether or not it's OK to include qicohandler.* the way I propose in the patch under review? There are some whitespace changes and I added a preprocessor token to exclude ico read support. My understanding of the GPL legalese is that it should be OK but Christoph is right that we have to double-check. Maybe we all overlooked something and there is another way to create .ico files, without needing to use (and thus include) QtIcoHandler explicitly? I see that the relevant QtBase code is built on Linux and Mac but I cannot tell whether it is also installed (the header isn't in any case). Thanks, René --- Forwarded message: Date: Friday January 13 2017 From: Christoph Feck Subject: Re: Review Request 129807: proposal: add ksvg2ico https://git.reviewboard.kde.org/r/129807/#review101968 Someone more experienced with legal matters should review the verbatim inclusion of Qt code; in particular the license header. - Christoph Feck ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9
Hi, I scheduled a test build in the CI against 5.8 (as dev continues to be broken). The results are public at http://testresults.qt.io/coin/integration/playground/qtremoteobjects/tasks/web_playground_qtremoteobjects_1484293648911 There are few issues: 1) namespaced build doesn't work 2) license check fails 3) tests run qmake infinitely on Windows. 4) winrt / msvc 2013 build broken Simon From: Simon Hausmann Sent: Jan 13, 2017 08:38 To: Lars Knoll; Stottlemyer, Brett (B.S.) Cc: Qt development mailing list Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9 Hi, From a CI perspective nothing needs to be done. From the Gerrit side the UI needs to be changed from submit to merge to staging. Gerrit admins can do that. The module itself needs to support "make install" and be able to run tests against the installed version of the module. By default the module will be built against the dev branch of qt5.git. If you use for example a 5.8 branch in qtro, then we'll use qt5 5.8. (there are more options, but this is the gist :) There are a few modules outside of qt/ that are also CI controlled, it's a rather common thing. Simon From: Lars Knoll Sent: Jan 13, 2017 08:25 To: Stottlemyer, Brett (B.S.) Cc: Qt development mailing list Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9 Hi Brett, > On 13 Jan 2017, at 02:58, Stottlemyer, Brett (B.S.) wrote: > > On 12 January 2017 at 08:39, Lars Knoll wrote: > >> From the discussion so far I didn't hear too many things that speak against >> a TP, the code duplication with moc is one of the issues that fall into the >> 'flagged and need to be resolved before moving out of TP' category for me. >> How about the other >> points in the list above that haven't been discussed yet here? > > Moving the points to below instead of above. My opinion is (obviously) > biased. > >> * The module solves a problem our users have >> - It either implements new and so far non existent functionality >> - Or it solves an existing problem in a new and better way (and is intended >> to replace the old functionality over time) > > It seems like the two potentially competing current projects are Qt Service > Framework and QtDBus. I believe QtRO is > different from both, with “better” being subjective. At the risk of being > flamed for why I prefer QtRO, I’d put it > this way: > > The Qt Service Framework deals with OS Services/daemons, and only works > inter-process, not inter-device. If I can > distinguish between a service and a Service, Service being a different class > than a program (I.e., on windows, services > run when no user is logged on). If you need a Service, the Service Framework > makes sense. This isn’t the problem > QtRO is trying to solve. > > QtDBus is more similar in intent to QtRO. QtRO is peer-to-peer, while Dbus > by default goes through a daemon. Bus is > common on Linux platforms, but has additional dependencies on other platforms > (Windows, QNX, etc). The key difference > though, is that DBus is intended to translate between languages (java, C, > python). This is a disadvantage of QtRO > in many cases, but when Qt is available for both client/server, it provides a > much richer level of communication. For > instance, QtRO supports QAIM, including selection, across processes/devices. > It supports state (current PROPERTY > values). It supports any type Qt can (or can be made to) pass in Queued > connections. Without additional code. > > My view is that QtRO complements the other two options, providing strong > benefits for the right use-cases. Agreed. > >> * The module builds inside the Qt build system on all platforms >> - Compilation could be disabled on some platforms, but is not allowed to >> break any platform we support >> * The module is CI controlled > > Umm, this feels like a chicken and egg problem to me. The Qt Company > controls the CI, and it doesn’t run against play- > ground projects. We have worked with KDAB and implemented CI on 4 platforms, > targeting only Qt 5.6.2 currently. Until > Qt’s CI is applied to it, there isn’t a clear way to evaluate build issues. > I’ve manually built against 5.8.0rc1 but > not on all platforms. I feel like there needs to be a way to enable Qt’s CI > against QtRO before deciding whether to > accept it as a TP project. Can the Qt Company CI team help with this? It is > a playground project already hosted on > qt.io. If not, what options are there? It should be pretty straightforward to enable CI on the module. Pre-conditions are mainly that it’s structured like the other Qt modules. Frederik & Simon what would it take to enable CI on it? > >> * There is a decent set of automated tests covering the main functionality >> and most of the API of the module >> - The tests pass on all platforms where the module is supported >> * APIs have
