Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Stottlemyer, Brett (B.S.)]

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

[Oswald Buddenhagen]

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

Re: [Development] Calendar Systems proposal

[Edward Welbourne]

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 

[Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Stottlemyer, Brett (B.S.)]

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] Jira action buttons

[Alexander Blasche]

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

Re: [Development] Jira action buttons

[Samuel Gaist]

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

[Sean Harmer]

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