Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9
On 1/9/17, 10:54 AM, "Development on behalf of Oswald Buddenhagen" wrote: >i had a quick look at the repo: >- there is still copy of moc's c++ parser in there. not much to do about > it at this point, except that repc is mostly redundant with moc to > start with. This is a direction I hadn’t really considered. I don’t like duplicating moc code, but my thought was to put repc into qtbase (if that would be accepted. Thiago?) and keep the rest of QtRO in a separate repository. The primary job of repc is to generate QObject code, and the mkspecs add those automatically for moc processing. I.e, it takes the API definition, in .rep format, and generates an asymmetric pair of files, one for the Source and one for the Replica. The processing of QObject code by repc to generate the .rep input file format was added afterwards. It allows existing Qt header files to be used with QtRO with compile time checks. We don’t use that feature much internally, but others are. > - why not make it an output mode of moc? or at least, it would seem >sensible to make moc output an intermediate json file with the meta >info it extracted, and still leave the code generation to repc - >that would remove the double parsing, and always ensure consistency. If you are willing to take the .rep format as a moc input (?) this might work. If your thought is to take a QObject header file as input, I’m not sure it does. As a concrete example, Q_PROPERTY on the Source side can be CONSTANT, but on the Replica side it can’t (it can have a default value which is then updated when the connection to the Source is established.) This asymmetry seems like it would be very confusing if it was output by moc. > - i see that repc creates qdatastream operators for q_enums & co. - >that *really* seems like generic moc stuff. Only in certain cases. It lets moc handle this if possible. I’ll have to look at this again, the intent was to let moc do as much as possible. > - please verify that improvements to moc and the meta type system have >not obsoleted some repc functionality in the first place. Pretty sure that for the primary use case they don’t, but if you can point me to specific enhancements to look at, that would be appreciated. >- was that promised discussion vs. qtsystems actually ever had? No, but I don’t remember promising to have the discussion. I know there was a proposal to look for commonality with web sockets. That didn’t happen either. Are these blockers? >- formalities: > - lots of build system hacks for obsolete qt versions To be honest, Ossi, you see stuff instantly that I need to study in the build system. We can keep working on it, but patches would be welcomed. > - lagging in coding style practice (replace foreach, other c++11 >stuff) Yes, we have been on LTS, so there are necessary changes for 5.7+. Are these needed before feature freeze? Or can they be addressed as we move to 5.9? Overall, I can’t quite tell from your response which items are nice to have, need to have (by feature freeze) or need to have (by 5.9 release). I’d appreciate clarification. Thanks, and thanks for the review, Brett ___ 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 Mon, Jan 09, 2017 at 02:50:52PM +, Stottlemyer, Brett (B.S.) wrote: > As the maintainer for the Qt Remote Objects (QtRO) playground project, > I would like to officially request moving it from a playground project > to a Qt project. > i had a quick look at the repo: - there is still copy of moc's c++ parser in there. not much to do about it at this point, except that repc is mostly redundant with moc to start with. - why not make it an output mode of moc? or at least, it would seem sensible to make moc output an intermediate json file with the meta info it extracted, and still leave the code generation to repc - that would remove the double parsing, and always ensure consistency. - i see that repc creates qdatastream operators for q_enums & co. - that *really* seems like generic moc stuff. - please verify that improvements to moc and the meta type system have not obsoleted some repc functionality in the first place. - was that promised discussion vs. qtsystems actually ever had? - formalities: - lots of build system hacks for obsolete qt versions - lagging in coding style practice (replace foreach, other c++11 stuff) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9
As the maintainer for the Qt Remote Objects (QtRO) playground project, I would like to officially request moving it from a playground project to a Qt project. For now (Qt 5.9), I’d like to keep it as a Tech Preview, as there are some elements of the API we would still like to extend, and we’d certainly like to protect for changes based on additional feedback. In a nutshell, Qt Remote Objects takes the mechanisms that Qt already provides for multithreaded processing (Queued connections, marshaling arguments) and extends them to allow QObjects to work across process and/or device boundaries. It does this by allowing a Source object (with a full implementation of the Qt Properties, Signals and Slots) to be shared on the QtRO bus. Replica versions of this object can be acquired, where QtRO handles sending any changes to the Source to all Replicas. I think of the Replicas as “latent copies” of the original object. This seems like a great extension to Qt, and based on discussions at the last Qt World Summit, one that is makes sense to have as an official Qt module. From a maturity standpoint, it has been running as a playground project for several years now. We have several platforms checked via our own CI, but would like to get coverage on all supported platforms and will certainly address any issues found. Giuseppe D’Angelo was kind enough to add QtRO to the Qt LTS Coverity scans, and except for several issues tied to a copy of moc, it is in good shape. It supports qmake docs, although the docs need some care and feeding (this is ok for a Tech Preview as I understand it). If this request is well received, I do have one sub-request. According to http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt, “the playground name needs to be changed to a descriptive Qt module or tool name.” The current name is qtremoteobjects. Are there issues keeping this name? Thanks for your consideration, Brett ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
I observed: >> Issue: Q(Date|Time)+ think day-changes happen at midnight. [...] Has >> secular society shifted the day boundary to midnight in practice ? Soroush replied: > Indeed they do the simplification needed to adopt modern lifestyle. OK, good - then we have an excuse to keep the simple model ! > As far as I know, modern lunar calendars being used in ME as official > calendars, have loads of simplifications applied compared to the > original calendars. The start of a month in Islamic calendar in Fiqh > (regional calendar) is based on observing new moon (by unaided eye) in > the sky. That's why Saudi Arabia sometimes celebrate end of Ramadan > one day after Turkey, and one day before Iran. That's why number of > days differ from a year to another. All of which argues for us to support the simplified official version, while making it possible for apps and user-communities to add in their own implementations taking account of local quirks. > Though, the start of the day is 00:00 in modern calendars. And number > of days in months are fixed. That, at least, is reassuring ;-) > Anyway, the only country using lunar calendar (Saudi Arabia) just > switched to solar system (Gregorian). But we have to support Islamic > calendar (modern version) of course. Indeed - even if it's not the official state calendar, there are folk still using it who shall want their software to respect that. We can make that *possible*, even where we aren't going to do all of the work ourselves ... > My current implementation looks like KCalendarSystem with some > differences. Calendar classes are subclassed from QAbstractCalendar, > and have to implement several methods. I tried to make this class as > generic as possible, there is no assumption on month days and number > of months. Sounds promising. If you can push it to gerrit as a work in progress (start the subject line of the commit message with "WIP: " and the system shall know what you mean; you can also push to refs/drafts/dev to make it a draft review, until you eventually push to refs/for/dev to turn it into a "real" review), I'll take a look at it and we can discuss more there (taking traffic off this list). I was tidying up in our Wiki after wearing out my brain on Friday and stumbled upon [0], a 2011 write-up of relevant ideas - written by John Layt, who is the author of KCalendarSystem. (Speaking of: if anyone is in touch with him and can reach him other than via his @KDE e-mail, which I've pinged, please do bring this discussion to his attention.) It may be a source of some fruitful insights. [0] https://wiki.qt.io/Qt-contributors-summit-2011-QDateTime > I just finished adding new methods to QDate and it's working for > Jalali Calendar. > > QDate d = QDate::currentDate(); > int gyear1 = d.year(); // 2017 > int gyear2 = d.year(QGregorianCalendar); // 2017 > int jyear1 = d.year(QJalaliCalendar()); // 1395 > int jyear2 = d.year(QAbstractCalendar::fromName("jalali")); // 1395 Nice. I interpolate a missing () on the end of QGregorianCalendar(). > I didn't touch Gregorian calculations in QDate, just added more > functions. Does removing static members count as an ABI change? I'm > planning to move all the math out of QDate into QGregorianCalendar. A static function is invisible to anything outside its own compilation unit, so turning assorted static functions in qdatetime.cpp into methods of QGregorianCalendar is entirely feasible. You can even mess with QDateTimePrivate - see the warning comment in qdatetime_p.h ;^> Static members of a public class, however, have to stay (I suppose). Not that you have to continue *using* them, if something else makes them redundant ... > About calendaring widgets, The widget obviously needs to keep > information on what calendar system it uses. I think it's possible to > add members to private API classes? After all it's **private** and > there's only a pointer to private API class in main class. So it would > be A[BP]I compatible I suppose. Check for that warning comment, or a header-name ending _p.h - you can get away with plenty of change there. > And also we need to add some functions to main class: > > void QDateEdit::setCalendar(QAbstractCalendar* cal); // maybe a QString? > QAbstractCalendar* QDateEdit::calendar() const; // meh... Those make sense. Definitely pass QAbstractCalendar * to the setter; otherwise, client code can't supply a custom calendar that's not known to our abstract base class's method. The advantage of an overload taking QString is minor - it'll package a call to fromName - and I fear it would add confusions, with folk expecting too much of it, or a matching getter returning QString. Please keep QDateEdit changes in a separate commit from QDateTime changes; ideally, even separate the creation of QCalendarSystem's base class (at least) from re-working QDateTime to break out QGregorianCalendar. > There is another issue: How do we add calendar localization to QLocale? I don't
Re: [Development] Jira action buttons
On 09/01/2017 08:21, Alexander Blasche wrote: Hi, -Original Message- From: Development [mailto:development- bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Samuel Gaist Sent: Sunday, 8 January 2017 23:44 Is there any rule/filter that are applied on the bug reports related to the actions made available ? For example: https://bugreports.qt.io/browse/QTBUG-57991: I have Edit, Comment, Assign, More https://bugreports.qt.io/browse/QTBUG-57996 : Same as above plus Not enough info, Accept, Close I wanted to close https://bugreports.qt.io/browse/QTBUG-57993 as a duplicate of https://bugreports.qt.io/browse/QTBUG-57992 but I can’t do it currently because for both of them I only get the reduced set of buttons. This is a bug. Nobody had any state transition options for this task. Jira ran out of disk space last week. Maybe this has caused the problem. In any case, I have recovered the work flow state and marked QTBUG-57993 as duplicate of QTBUG-57992. Hi Alex, could you do the same for https://bugreports.qt.io/browse/QTBUG-55824 and https://bugreports.qt.io/browse/QTBUG-55825 please? I only have a reduced set of actions available. Thanks, Sean -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Jira action buttons
Hi,On 9 Jan 2017, at 09:21, Alexander Blasche wrote:Hi,-Original Message-From: Development [mailto:development-bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Samuel GaistSent: Sunday, 8 January 2017 23:44Is there any rule/filter that are applied on the bug reports related to the actionsmade available ?For example:https://bugreports.qt.io/browse/QTBUG-57991: I have Edit, Comment, Assign,Morehttps://bugreports.qt.io/browse/QTBUG-57996 : Same as above plus Notenough info, Accept, CloseI wanted to close https://bugreports.qt.io/browse/QTBUG-57993 as a duplicateof https://bugreports.qt.io/browse/QTBUG-57992 but I can’t do it currentlybecause for both of them I only get the reduced set of buttons.This is a bug. Nobody had any state transition options for this task. Jira ran out of disk space last week. Maybe this has caused the problem. In any case, I have recovered the work flow state and marked QTBUG-57993 as duplicate of QTBUG-57992.--Alex___Development mailing listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/developmentIt might not be fully solved yet.https://bugreports.qt.io/browse/QTBUG-57991 still shows me a reduced set of action.In any case, thanks for checking !Samuel___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Jira action buttons
Hi, > -Original Message- > From: Development [mailto:development- > bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Samuel Gaist > Sent: Sunday, 8 January 2017 23:44 > Is there any rule/filter that are applied on the bug reports related to the > actions > made available ? > > For example: > > https://bugreports.qt.io/browse/QTBUG-57991: I have Edit, Comment, Assign, > More > > https://bugreports.qt.io/browse/QTBUG-57996 : Same as above plus Not > enough info, Accept, Close > > I wanted to close https://bugreports.qt.io/browse/QTBUG-57993 as a duplicate > of https://bugreports.qt.io/browse/QTBUG-57992 but I can’t do it currently > because for both of them I only get the reduced set of buttons. This is a bug. Nobody had any state transition options for this task. Jira ran out of disk space last week. Maybe this has caused the problem. In any case, I have recovered the work flow state and marked QTBUG-57993 as duplicate of QTBUG-57992. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development