Re: [Development] [Interest] Printer-specific options in Qt5's print dialog (Linux, CUPS)

2017-01-30 Thread Andrew, Shaw 


Development på vegne av Thiago Macieira 
 skrev følgende den 30.01.2017, 17.57:

Resending this to the development mailing list.

Others: please read Michael's email below.

On segunda-feira, 30 de janeiro de 2017 14:12:32 PST you wrote:
> Hi,
> 
> in September 2015, I asked about the status of printer-specific options
> in the Qt 5 print dialog on Linux (with CUPS as printing system), s.
> thread at [1].
> 
> As John Layt explained, a rework of the print dialog had started for Qt
> 5 but could not be finished until then. The implementation for
> printer-specific options had been rather broken in Qt 4 and was removed
> for Qt 5, with the plan to reimplement them as part of a new printing
> system. John explained that unfortunately, work on the new printing
> system could not be continued then due to lack of time and money. As far
> as I can see, the situation now is still mostly the same.

Unfortunately it would seem that John is no longer working on the printing 
system in Qt, so little has been done on it lately, though there are some of us 
doing changes to it still but they are mainly fixes and not actual features.

> As printer-specific options (like e.g. selecting a particular input
> tray, setting a PIN for a confidential print job, punching, creating a
> booklet, ...) are quite an important feature for us (City of Munich), we
> are currently evaluating different options for how to continue. One
> option is to implement that functionality ourselves or have a contractor
> implement it for us.
> 
> We would very much like this feature to be available upstream so that
> everybody can benefit from it and we do not have to maintain it in our
> own "fork" of Qt.
> 
> Before we make any further plans, I wanted to ask about the Qt project's
> current plan for the print dialog.
> 
> While I am very grateful for the links John has given about the new
> print system back then, some points are still a bit vague to me and I
> currently do not know what the next concrete steps in the implementation
> of the new print system would be to get closer to the desired goal. (Any
> further information on that is welcome.)
> 
> Back then, John had written that various new features need to be
> implemented for the new Qt print system and a temporary solution based
> on the current code might be a better approach at first. In case no
> activities are currently planned on Qt's side, our current technical
> approach would probably be to implement the feature based on the current
> 
> code base and make an implementation similar to what John wrote in [2]:
> > Given the dependency tree of new features required to reach the end
> > point, a temporary implementation might be a better bet than waiting
> > for the new print system, i.e. reimplement the old extra page but
> > smarter. The main problem with the old page was it duplicated settings
> > from the main dialog, and hid the fact you could actually edit the
> > values. The UX I had in mind for Qt4 was to choose all the features
> > that could be supported directly in the main dialog and add them
> > there, then filter those out in the extra page in a generic editing
> > view. It would require a lot of work around parsing PPD's and matching
> > option codes to existing ui, but it's doable.
> 
> I would be very grateful for any further information on the topic,
> particularly on the following questions:
> 
> 1) Are there (concrete) plans for the next steps considering the Qt
> print dialog?

Currently there are none as, to my knowledge, no one is working on the print 
dialog specifically.

> 2) Is the Qt project interested in us working together with them to get
> the feature implemented upstream?

I would be willing to look at the changes and review them, I am sure there are 
others out there too who would be willing too.

> 3) Is a temporary implementation as described above considered as a good
> approach for now?

To be honest I am not entirely sure, I personally would be in favour of 
implementing it the right way the first time if it is going to go into Qt 
rather than having a stop-gap solution. There is nothing to gain I think from 
an intermediate solution, though if you are referring to doing it in your own 
code then it is probably ideal for the short-term.

> 4) Are there other people/organisations that have the same problem? Do
> you have approaches to deal with that?

Not to my knowledge, but that is not to say that there is no one out there.

> Possibly, Qt's development mailing list might be a better place when it
> comes to more details about a a possible implementation, but I wanted to
> start here where the discussion took place in 2015.

Personally I would go ahead and submit

Re: [Development] Calendar Systems proposal

2017-01-30 Thread Robin Burchell 
On Mon, Jan 30, 2017, at 09:07 PM, Hamed Masafi wrote:
> My prefer option is form (3)
> We can add an enumeration to global space.
> var date = new Date;
> var out = date.toString(Qt.JalaliCalendar, "-MM-dd");

I would prefer to not modify standard APIs if we can avoid it (unless we
have a good reason to do so and such a change is pretty low risk).
Keeping close to the rest of the JS ecosystem means that skills learned
in one place are easily translated to another (meaning less
QJSEngine-specific knowledge and docs are required). In the particular
case of Date.prototype.toString(), it also means that should any future
specification start supporting additional arguments there, we aren't
going to open ourselves up to future unexpected problems.

> > Have you considered whether Date.prototype.toLocaleDateString could be
> > of use for this? See:
> >
> http://ecma-international.org/ecma-402/3.0/index.html#sup-date.prototype.tolocaledatestring
> Date.prototype.toLocaleDateString is used to converting date to a string
> bases on a Locale. we can use this function for accepting an CalendarType
> (CalendarType is a QEnum that contains list of calendar types like;
> gregorian, jalali, hindi or etc)
> date.toLocaleString(format);
> date.toLocaleString(CalendarType, format);
> date.toLocaleString(locale, format);
> date.toLocaleString(CalendarType, locale, format);

Right, if you look at the spec I linked you to, that's what it
specifies- converting a date to a string in a locale-specific way. They
don't use an enum, but a string to describe the calendar system (plus
some additional options to control the formatting result in an
additional optional parameter). I can admit the spec is a bit hard to
read. Here's a slightly less formal description, with some examples:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString

If you want to see it in action, in a browser, try something like this
in a web browser JS console:

console.log(new Date().toLocaleDateString("ar-EG"))

I see:

٣٠‏/١‏/٢٠١٧

Which I hope is something useful/meaningful, I'm unfortunately not
familiar enough with that locale to tell. I've confirmed this to work in
recent releases of Safari, Firefox and Chrome on OS X. Outside of
browsers, YMMV. I didn't get Nodejs to respect the locale options, for
instance.

What we implement now is nothing close to this (in fact, we simply
ignore all arguments and return the argument using local formatting) -
my guess is that it is down to most of this being added after ES5.

> But there are some bugs related to this prototype, We have to solve that
> within this process.

As I said, as it stands, our implementation is currently not doing what
you need - it would need to be fleshed out to actually use the provided
arguments. However, I think that extending this seems to be a pretty
good match for the functionality you are wanting to add?

-- 
  Robin Burchell
  ro...@crimson.no
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Calendar Systems proposal

2017-01-30 Thread Hamed Masafi 
> That shall complement Soroush Rabiei's work on the C++ side:
Yes, that's right. I'm trying to port Soroush's calendar mechanism to qml
side of Qt.

> If I understand Lars correctly, he prefers an API where the calendar
> object carries methods that act on a date and any further arguments it
> may need (similar to QLocale), so cal.toString(date, "-MM-dd") is
> more likely (although I personally like the style of API you give above,
> where the date object has the calendar-aware methods; too many of the
> details are the same between calendar systems).  Aside from that, this
> is roughly the shape the C++ API shall have, making it a natural model
> for the QML to follow.
I'm not sure we can add an global type to script engine that are not in
ecma script.

> Not sure what you're proposing here - you don't mention Qt.calendar in
> the code example, which looks more like 1) with JalaliCalendar moved to
> the Qt object - which may indeed be a better place for it than as a
> naked global object.
No; in this case Qt.JalaliCalendar is a QEnum and not an object (my
suggestion explained below)

> I don't know what rules QML might impose.  Each of these would, in one
> way or another, require the calendar system code to register itself in
> some way with QML, associated with the name by which QML is to refer to
> it.  The details of whether that name is in the namespace of some
> visible object (the ECMAScript global object or the Qt object) or in
> some internal mapping (for 2) are a matter of what's practical or
> convenient - someone with more QML fu than I can claim can advise you
> better there.
My prefer option is form (3)
We can add an enumeration to global space.
var date = new Date;
var out = date.toString(Qt.JalaliCalendar, "-MM-dd");

> Have you considered whether Date.prototype.toLocaleDateString could be
> of use for this? See:
>
http://ecma-international.org/ecma-402/3.0/index.html#sup-date.prototype.tolocaledatestring
Date.prototype.toLocaleDateString is used to converting date to a string
bases on a Locale. we can use this function for accepting an CalendarType
(CalendarType is a QEnum that contains list of calendar types like;
gregorian, jalali, hindi or etc)
date.toLocaleString(format);
date.toLocaleString(CalendarType, format);
date.toLocaleString(locale, format);
date.toLocaleString(CalendarType, locale, format);

But there are some bugs related to this prototype, We have to solve that
within this process.
https://bugreports.qt.io/browse/QTBUG-32492
https://bugreports.qt.io/browse/QTBUG-41712

> var out = date.toString("/MM/dd", Qt.JalaliCalendar); // Is
> this possible?
This is my choice too. And answer is "yes". This is possible. But for that
we must conclusion below paragraph [*]:

> There are differences between those concepts that are implemented as
> plugins and calendars. A calendar system is not an image format nor a
> database implementation. There will be no new calendar (at least, it's
> unlikely to have a brand new calendar) and there will be no newer
> versions of existing calendars. What is the point of having calendars
> as plugins? And we have to keep QGregorianCalendar everywhere after
> all... And we will have the problem of instantiation. While plugins
> have no public header, then how we are supposed to use them in code?
> Like this:
[*]: I'm agree with Soroush. Calendar system must bot be pluginable. Due
the facts that soroush said.

I think to continue we must conclusion on that calendar types must be
plugin or not?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Matthew Woehlke 
On 2017-01-30 12:29, André Pönitz wrote:
> *If* it turns out to be a problem elsewhere, which I don't expect,
> there needs to be an explanation why a transcription of "ä" can be
> considered a more severe "legal issue" than the "legal issue"
> originating from transcribing "©" as "(C)" in the same line.

Well, since (fortunately) those lines seem to start with "Copyright", a
"©" would be redundant, so for that case there is no issue. (Really, all
those "(C)"s ought to just be removed.)

-- 
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Feature Freeze Exception: QStringView

2017-01-30 Thread Marc Mutz 
Hi,

QStringView is ready to be merged, but the maintainer has asked for another 
week before he can properly review the class.

In case you don't remember, here's the discussion thread from 2015: 
http://lists.qt-project.org/pipermail/development/2015-October/023358.html

Here's the evolving patch series:
https://codereview.qt-
project.org/#/q/status:open+project:qt/qtbase+topic:qstringview,n,z

I feel the patch addresses all concerns raised in the discussion:

1. size_type: we agreed on on ssize_t equivalent to strike a balance between
   the Qt preference of 32-bit signed types over the STL preference for 64-bit
   unsigned types.
2. Do this in Qt vs. do this in QtCreator. I believe that a QStringView
   without deeply-routed support in QString would be a still-born. We also
   don't have time come Qt 6 to port all of Qt to a QStringView developed
   elsewhere. The current patches just scratch the surface. Everywhere
   QStringRef is currently used, QStringView can be used. And a lot of places
   that traditionally only took QString should take QStringView, too, e.g.
   QFile::encodeName(). So I added it to Qt.
3. Keeping existing QString overloads for implicit sharing.
   The patch does not remove anything. It will, as it progresses, implement
   QT_STRINGVIEW_LEVELs 2 and 3 which remove existing QString and QStringRef
   overloads (2: only where the function read from the string, 3: also where
   it stores the string), so that at some later point in time we can just flip
   a preprocessor switch and compare executable size and execution speed of
   both sets of overloads, everything else being equal.

So, in order to give the maintainers more time for review, I'd like to ask for 
a feature freeze extension for QStringView until end of next week, plus a few 
days to deal with maintainer review comments.

Why should it be granted? Because QStringView is by far the biggest revolution 
in Qt since 5.0, all the while integrating naturally and step-by-step into 
existing code, _tremendously_ simplifying it along the way (cf. the commits 
that start to make use of QStringView: https://codereview.qt-
project.org/183864 https://codereview.qt-project.org/183925), esp. where, in 
private API, we can already remove the other overloads.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread André Pönitz 
On Mon, Jan 30, 2017 at 11:23:30AM +, Simon, Hausmann wrote:
> We practically support three different front-ends: GCC, clang and
> MSVC. All three - MSVC with the help of an option - can
> grok UTF-8. Let's use it at least inside Qt :)

Qt source is handled by a variety of tools, not only compilers.

Nowadays they kind of all kind of always support kind of UTF-8, yeah, so
use it, if it works. Fine.

But I absolutely don't get the point of trying to run with my head into
a wall because I know there is a door in the wall on the construction
drawing in this place, even if my eyes tell me it's a couple of feet to
the left.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread André Pönitz 
On Sun, Jan 29, 2017 at 05:21:57PM -0800, Thiago Macieira wrote:
> On domingo, 29 de janeiro de 2017 10:33:39 PST André Pönitz wrote:
> > We should remove non-ASCII characters from the sources if they cause
> > problems.
> 
> We've had this discussion. One of our largest contributors has a full legal 
> name that doesn't fit in ASCII.
> 
>   Klarälvdalens Datakonsult AB

That's the very reason why I wrote:
 
> > If some non-ASCII is unproblematic (like the 'ä' in some copyright lines)
> > on all supported compilers, that's fine to have
> 
> That's usually one of the problematic ones.

Not in the case here, and not in the other case attempting to fix build
problems recently, namely https://codereview.qt-project.org/#/c/173622/
which is, by the way, *still* in a state inconsistent with the project
governance rules.
 
> Not on this file, though:
> 
> qCDebug(lcTuioSet) << "Processing SET for token " << classId << id << " @ 
> " << x << y << "∡" << angle <<
> 
> That's easy to fix by using "\342\210\241" instead.

The fix I would use is something like

 qCDebug(lcTuioSet) << "Processing SET for token " << classId << id
<< " @ " << x << y << "angle:" << angle << ...

There is no need to use non-ASCII here at all. "\nnn" is fine in case
where \nnn is *really* needed, e.g. some auto tests.

> So, we should:
>  a) still avoid non-ASCII in our source files, aside from comments

Yes.

>  b) allow non-ASCII in comments, as needed

If *really* needed, or proven to be no problem in practice.

The mentioning of "Klarälvdalens" is a red herring in predecessors of
this discussion.  The 'ä' in the comments is not a problem in the two
controversial changes.  *If* it turns out to be a problem elsewhere,
which I don't expect, there needs to be an explanation why a transcription
of "ä" can be considered a more severe "legal issue" than the "legal
issue" originating from transcribing "©" as "(C)" in the same line. 

>  c) turn the -utf-8 option on for MSVC2015U3.

Yes.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Interest] Printer-specific options in Qt5's print dialog (Linux, CUPS)

2017-01-30 Thread Thiago Macieira 
Resending this to the development mailing list.

Others: please read Michael's email below.

On segunda-feira, 30 de janeiro de 2017 14:12:32 PST you wrote:
> Hi,
> 
> in September 2015, I asked about the status of printer-specific options
> in the Qt 5 print dialog on Linux (with CUPS as printing system), s.
> thread at [1].
> 
> As John Layt explained, a rework of the print dialog had started for Qt
> 5 but could not be finished until then. The implementation for
> printer-specific options had been rather broken in Qt 4 and was removed
> for Qt 5, with the plan to reimplement them as part of a new printing
> system. John explained that unfortunately, work on the new printing
> system could not be continued then due to lack of time and money. As far
> as I can see, the situation now is still mostly the same.
> 
> As printer-specific options (like e.g. selecting a particular input
> tray, setting a PIN for a confidential print job, punching, creating a
> booklet, ...) are quite an important feature for us (City of Munich), we
> are currently evaluating different options for how to continue. One
> option is to implement that functionality ourselves or have a contractor
> implement it for us.
> 
> We would very much like this feature to be available upstream so that
> everybody can benefit from it and we do not have to maintain it in our
> own "fork" of Qt.
> 
> Before we make any further plans, I wanted to ask about the Qt project's
> current plan for the print dialog.
> 
> While I am very grateful for the links John has given about the new
> print system back then, some points are still a bit vague to me and I
> currently do not know what the next concrete steps in the implementation
> of the new print system would be to get closer to the desired goal. (Any
> further information on that is welcome.)
> 
> Back then, John had written that various new features need to be
> implemented for the new Qt print system and a temporary solution based
> on the current code might be a better approach at first. In case no
> activities are currently planned on Qt's side, our current technical
> approach would probably be to implement the feature based on the current
> 
> code base and make an implementation similar to what John wrote in [2]:
> > Given the dependency tree of new features required to reach the end
> > point, a temporary implementation might be a better bet than waiting
> > for the new print system, i.e. reimplement the old extra page but
> > smarter. The main problem with the old page was it duplicated settings
> > from the main dialog, and hid the fact you could actually edit the
> > values. The UX I had in mind for Qt4 was to choose all the features
> > that could be supported directly in the main dialog and add them
> > there, then filter those out in the extra page in a generic editing
> > view. It would require a lot of work around parsing PPD's and matching
> > option codes to existing ui, but it's doable.
> 
> I would be very grateful for any further information on the topic,
> particularly on the following questions:
> 
> 1) Are there (concrete) plans for the next steps considering the Qt
> print dialog?
> 2) Is the Qt project interested in us working together with them to get
> the feature implemented upstream?
> 3) Is a temporary implementation as described above considered as a good
> approach for now?
> 4) Are there other people/organisations that have the same problem? Do
> you have approaches to deal with that?
> 
> Possibly, Qt's development mailing list might be a better place when it
> comes to more details about a a possible implementation, but I wanted to
> start here where the discussion took place in 2015.
> 
> Regards,
> Michael
> 
> PS: Besides the implementation of printer-specific options, there are a
> few other things in the Qt 5 print dialog that we would like to address,
> but that will be done separately.
> 
> 
> [1]
> http://lists.qt-project.org/pipermail/interest/2015-September/thread.html#18
> 692 [2]
> http://lists.qt-project.org/pipermail/interest/2015-September/018700.html
> ___
> Interest mailing list
> inter...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Calendar Systems proposal

2017-01-30 Thread Thiago Macieira 
On segunda-feira, 30 de janeiro de 2017 15:43:30 PST Soroush Rabiei wrote:
> Can we have calendars for 5.9 ? It's not FF yet I suppose. And there's
> not much to do. Either we implement calendars as factory classes
> operating on QDate, or adding to QDate's API, there is not much work
> left to do.

I'll review your change proposal to QDate, but don't hold your hopes up that 
it'll pass in time for the feature freeze.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Thiago Macieira 
On segunda-feira, 30 de janeiro de 2017 09:58:30 PST Edward, Welbourne wrote:
> I'm not sure how that works on MS-Windows, but I'd just set
> LANG=en.UTF-8 in my environment on any Unix; this would then only affect
> the process in which I set it.  So it might be worth seeing if you can
> do that (or something equivalent) for the process that runs configure &&
> make for you.

It's not always possible. Changing the system language on Windows is possible, 
but it's not always available (not always free), applies to all processes and 
I wouldn't be surprised if it required a reboot.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Thiago Macieira 
On segunda-feira, 30 de janeiro de 2017 14:43:22 PST Konstantin Tokarev wrote:
> What about Intel? (IIRC they use EDG frontend, aren't they?)

icc on Mac and Windows operates like GCC and Clang.

I'll check icl.exe on Windows. It is supposed to operate like MSVC, but it 
might have some other options or have never complained.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Thiago Macieira 
On segunda-feira, 30 de janeiro de 2017 09:56:46 PST Giuseppe D'Angelo wrote:
> Il 30/01/2017 02:21, Thiago Macieira ha scritto:
> > So, we should:
> >  a) still avoid non-ASCII in our source files, aside from comments
> >  b) allow non-ASCII in comments, as needed
> 
> Didn't we have issues with UTF-8 in comments too, when using MSVC?

Yes, which means that if it chokes on KDAB's name in qglobal.h, too bad.

> >  c) turn the -utf-8 option on for MSVC2015U3.
> 
> But just for Qt own build, not push this option onto the users. Also,
> does this fix anything? Is MSVC 2015 U3 the only one complaining, and we
> can live with UTF-8 in the source when using other compilers?

This will affect the Qt build only. Only MSVC 2015 U3 gets the fix, the older 
versions and MSVC 2013 will still be affected.

Sorry, tough luck for the others.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Thiago Macieira 
On segunda-feira, 30 de janeiro de 2017 09:42:05 PST Marc Mutz wrote:
>   // ∡

Better:  // U++2221 MEASURED ANGLE

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request for Qt 3D

2017-01-30 Thread Sean Harmer 
On Monday 30 January 2017 13:45:49 Frederik Gladhorn wrote:
> On torsdag 26. januar 2017 14.11.33 CET Sean Harmer wrote:
> > Hi,
> > 
> > Could somebody create me a new wip/physics branch for the Qt 3D branched
> > off of dev please? This is to start preparing a physics aspect hopefully
> > for Qt 5.10.
> 
> Looks like this has been done, the branch is there.

Yes, thanks. Ossi did it on Friday.

Cheers,

Sean

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request for Qt 3D

2017-01-30 Thread Frederik Gladhorn 
On torsdag 26. januar 2017 14.11.33 CET Sean Harmer wrote:
> Hi,
> 
> Could somebody create me a new wip/physics branch for the Qt 3D branched off
> of dev please? This is to start preparing a physics aspect hopefully for Qt
> 5.10.

Looks like this has been done, the branch is there.

Cheers,
Frederik


> 
> The existing wip/animation and wip/qtquickintegration branches should be
> going away shortly to keep things under control.
> 
> Thanks in advance,
> 
> Sean
> --
> Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
> ___
> 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] Calendar Systems proposal

2017-01-30 Thread Soroush Rabiei 
Can we have calendars for 5.9 ? It's not FF yet I suppose. And there's
not much to do. Either we implement calendars as factory classes
operating on QDate, or adding to QDate's API, there is not much work
left to do.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] Change file process & improvement proposal

2017-01-30 Thread Tor Arne Vestbø 


On 26/01/2017 13:28, Kai Koehne wrote:

So, any strong opinion against enforcing a [ChangeLog] line, with
"[ChangeLog] -" for commits that don't need one?


Yes. Absolutely not. This will just reverse the problem, creating noise 
in the commits and lots of useless ChangeLog entries, we might as well 
use git log directly.


tor arne

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Lars, Knoll 

On 30 Jan 2017, at 12:23, Simon, Hausmann 
mailto:simon.hausm...@qt.io>> wrote:


Making a warning go away for compilers that we know support utf-8 may not come 
at the price of your life :)

I for one am all in favor of requiring just the Qt source code (not talking 
about customer code) to be encoded in a 24 year
old standard and add all the necessary flags to the compilers to make them 
understand it instead of producing a warning.

We practically support three different front-ends: GCC, clang and MSVC. All 
three - MSVC with the help of an option - can
grok UTF-8. Let's use it at least inside Qt :)

+1. Let’s enable it.

Btw, this had actually been planned for Qt 5.0. Unfortunately we couldn’t 
implement it back then, as MSVC was not allowing us to set the input encoding 
to utf8.

Cheers,
Lars


Simon

From: Development 
mailto:development-bounces+simon.hausmann=qt...@qt-project.org>>
 on behalf of Viktor Engelmann 
mailto:viktor.engelm...@qt.io>>
Sent: Monday, January 30, 2017 12:06:19 PM
To: development@qt-project.org
Subject: Re: [Development] Shall we turn on /utf-8 compiler option when build 
qt for Windows?


Am 30.01.2017 um 11:40 schrieb Giuseppe D'Angelo:
> Il 30/01/2017 11:35, Viktor Engelmann ha scritto:
>> As far as I can see, all our codes *are* UTF-8 encoded (a least they
>> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
>> 2017!) instead of just telling the compiler the encoding we are using?
> So *all* of our compilers happily support UTF-8 encoded sources?

I wouldn't bet my life on that (especially not for windows!)

--

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

viktor.engelm...@qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


___
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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Lars, Knoll 

> On 30 Jan 2017, at 12:06, Viktor Engelmann  wrote:
> 
> 
> Am 30.01.2017 um 11:40 schrieb Giuseppe D'Angelo:
>> Il 30/01/2017 11:35, Viktor Engelmann ha scritto:
>>> As far as I can see, all our codes *are* UTF-8 encoded (a least they
>>> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
>>> 2017!) instead of just telling the compiler the encoding we are using?
>> So *all* of our compilers happily support UTF-8 encoded sources?
> 
> I wouldn't bet my life on that (especially not for windows!)

I think MSVC 2013 still doesn’t support utf8 as input encoding. But that 
compiler will get phased out at some point.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Konstantin Tokarev 


30.01.2017, 14:24, "Simon, Hausmann" :
> Making a warning go away for compilers that we know support utf-8 may not 
> come at the price of your life :)
>
> I for one am all in favor of requiring just the Qt source code (not talking 
> about customer code) to be encoded in a 24 year
>
> old standard and add all the necessary flags to the compilers to make them 
> understand it instead of producing a warning.
>
> We practically support three different front-ends: GCC, clang and MSVC. All 
> three - MSVC with the help of an option - can

What about Intel? (IIRC they use EDG frontend, aren't they?)

>
> grok UTF-8. Let's use it at least inside Qt :)
>
> Simon
> 
> From: Development  
> on behalf of Viktor Engelmann 
> Sent: Monday, January 30, 2017 12:06:19 PM
> To: development@qt-project.org
> Subject: Re: [Development] Shall we turn on /utf-8 compiler option when build 
> qt for Windows?
>
> Am 30.01.2017 um 11:40 schrieb Giuseppe D'Angelo:
>> Il 30/01/2017 11:35, Viktor Engelmann ha scritto:
>>> As far as I can see, all our codes *are* UTF-8 encoded (a least they
>>> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
>>> 2017!) instead of just telling the compiler the encoding we are using?
>> So *all* of our compilers happily support UTF-8 encoded sources?
>
> I wouldn't bet my life on that (especially not for windows!)
>
> --
>
> Viktor Engelmann
> Software Engineer
>
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
>
> viktor.engelm...@qt.io
> +49 151 26784521
>
> http://qt.io
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin
> Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
>
> ___
> 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


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Konstantin Tokarev 


30.01.2017, 14:37, "Viktor Engelmann" :
> Am 30.01.2017 um 12:23 schrieb Simon, Hausmann:
>> Making a warning go away for compilers that we know support utf-8 may not 
>> come at the price of your life :)
>>
>> I for one am all in favor of requiring just the Qt source code (not talking 
>> about customer code) to be encoded in a 24 year
>>
>> old standard and add all the necessary flags to the compilers to make them 
>> understand it instead of producing a warning.
>>
>> We practically support three different front-ends: GCC, clang and MSVC. All 
>> three - MSVC with the help of an option - can
>>
>> grok UTF-8. Let's use it at least inside Qt :)
>>
>> Simon
>
> personally, I want
> - every file in the world converted to UTF8
> - every software made compatible to UTF8
> - compatibility to any other encoding removed from every software
> - everyone burned at stake for heresy who says that any other encoding has 
> ever existed

... still UTF8 requires conversion into UTF16 to be used with most parts of Qt. 
Arrrgh.

>
> -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 
> D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io 
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der 
> Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> ,
>
> ___
> 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] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Viktor Engelmann 


Am 30.01.2017 um 12:23 schrieb Simon, Hausmann:
>
>
> Making a warning go away for compilers that we know support utf-8 may
> not come at the price of your life :)
>
>
> I for one am all in favor of requiring just the Qt source code (not
> talking about customer code) to be encoded in a 24 year
>
> old standard and add all the necessary flags to the compilers to make
> them understand it instead of producing a warning.
>
>
> We practically support three different front-ends: GCC, clang and
> MSVC. All three - MSVC with the help of an option - can
>
> grok UTF-8. Let's use it at least inside Qt :)
>
>
> Simon
>

personally, I want
- every file in the world converted to UTF8
- every software made compatible to UTF8
- compatibility to any other encoding removed from every software
- everyone burned at stake for heresy who says that any other encoding
has ever existed

-- 

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

viktor.engelm...@qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Simon, Hausmann 

Making a warning go away for compilers that we know support utf-8 may not come 
at the price of your life :)


I for one am all in favor of requiring just the Qt source code (not talking 
about customer code) to be encoded in a 24 year

old standard and add all the necessary flags to the compilers to make them 
understand it instead of producing a warning.


We practically support three different front-ends: GCC, clang and MSVC. All 
three - MSVC with the help of an option - can

grok UTF-8. Let's use it at least inside Qt :)


Simon


From: Development  on 
behalf of Viktor Engelmann 
Sent: Monday, January 30, 2017 12:06:19 PM
To: development@qt-project.org
Subject: Re: [Development] Shall we turn on /utf-8 compiler option when build 
qt for Windows?


Am 30.01.2017 um 11:40 schrieb Giuseppe D'Angelo:
> Il 30/01/2017 11:35, Viktor Engelmann ha scritto:
>> As far as I can see, all our codes *are* UTF-8 encoded (a least they
>> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
>> 2017!) instead of just telling the compiler the encoding we are using?
> So *all* of our compilers happily support UTF-8 encoded sources?

I wouldn't bet my life on that (especially not for windows!)

--

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

viktor.engelm...@qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


___
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] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Viktor Engelmann 

Am 30.01.2017 um 11:40 schrieb Giuseppe D'Angelo:
> Il 30/01/2017 11:35, Viktor Engelmann ha scritto:
>> As far as I can see, all our codes *are* UTF-8 encoded (a least they
>> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
>> 2017!) instead of just telling the compiler the encoding we are using?
> So *all* of our compilers happily support UTF-8 encoded sources?

I wouldn't bet my life on that (especially not for windows!)

-- 

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

viktor.engelm...@qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Giuseppe D'Angelo 
Il 30/01/2017 11:35, Viktor Engelmann ha scritto:
> As far as I can see, all our codes *are* UTF-8 encoded (a least they
> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
> 2017!) instead of just telling the compiler the encoding we are using?

So *all* of our compilers happily support UTF-8 encoded sources?

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Viktor Engelmann 


Am 30.01.2017 um 02:21 schrieb Thiago Macieira:
> That's usually one of the problematic ones.
>
> Not on this file, though:
>
> qCDebug(lcTuioSet) << "Processing SET for token " << classId << id << " @ 
> " << x << y << "∡" << angle <<
>
> That's easy to fix by using "\342\210\241" instead.

But that's just cheating - the UTF8 is still there, you only hide it...
Also, this way the UTF8 codes are hard-coded - if UTF8 is ever
deprecated or you want to write non-ASCII to a shell that doesn't
support UTF8, you'd have to change all these codes *manually*.
As far as I can see, all our codes *are* UTF-8 encoded (a least they
should be, IMHO), so why would we sneak our UTF8 in behind it's back (in
2017!) instead of just telling the compiler the encoding we are using?

-- 

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

viktor.engelm...@qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Improve performance (listview + onVerticalVelocityChanged)

2017-01-30 Thread Ulf Hermann 

Am 26.01.2017 um 20:09 schrieb Bernhard B:
I think I solved my problem. In case someone is interested, that's my 
solution:


Can't you bind the "visible" properties to the velocity? Then it doesn't 
have to execute so much javascript and the code looks cleaner and more 
declarative. The bindings will still be executed on every change in 
velocity, but it's likely that they'll be better optimized:


Something {
id: backToTopButton
visible: listView.verticalVelocity < -flickTabBarThreshold
}

SomethingElse {
id: tabBar
visible: backToTopButton.visible
}

br,
Ulf
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Calendar Systems proposal

2017-01-30 Thread Robin Burchell 
On Mon, Jan 30, 2017, at 08:59 AM, Hamed Masafi wrote:
> I'm working on qml support of calendar system,
> for porting this mechanism to qml we have two option:

Have you considered whether Date.prototype.toLocaleDateString could be
of use for this? See:
http://ecma-international.org/ecma-402/3.0/index.html#sup-date.prototype.tolocaledatestring

Disclaimer: I'm not intimately familiar with this API, but stumbled
across it while looking into other possible alternatives for this
problem.

-- 
  Robin Burchell
  ro...@crimson.no
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Viktor Engelmann 
I have a unit test for webengine that sends an HTTP Post request
which includes several unicode characters (outside of ä,ö,ü or other
Latin1 characters). I deliberately did that to make the test harder
to pass.


Am 29.01.2017 um 10:33 schrieb André Pönitz:
> On Sun, Jan 29, 2017 at 12:13:48PM +0800, Liang Jian wrote:
>> Start from qt-5.8 I can't build qt anymore under Windows(simplified
>> chinese locale). Since there is a file
>> src/plugins/generic/tuiotouch/qtuiohandler.cpp which contain non-latin-1
>> character, msvc2015 assume the source code's character set should be CP936
>> which make the complilation fail.
>> I can only build qt by comment the line which contain the specical
>> character in src/plugins/generic/tuiotouch/qtuiohandler.cpp.
>> But if I turn on -developer-build in configuration step, thing will get
>> worse than before, since -developer-build means treat warning as error, and
>> again I can't build qt anymore since there are other files contain
>> non-latin1 character (such as qstring.cpp), the build will fail due to the
>> character set warning.
>> I am working on a Windows 10 x64 simplifed chinese machine, msvc2015
>> update3
>> For more detail please refer to
>> https://bugreports.qt.io/browse/QTBUG-58161
>>
>> As a workaround, I have to modify the file
>> qtbase/mkspecs/common/msvc-desktop.conf
>> QMAKE_CFLAGS= -nologo -Zc:wchar_t /utf-8
>> After I add /utf-8 compiler option the build goes well.
>> Shall we turn on this compiler option by default?
> We should remove non-ASCII characters from the sources if they cause problems.
>
> If some non-ASCII is unproblematic (like the 'ä' in some copyright lines)
> on all supported compilers, that's fine to have, but mining log messages
> or comments with characters that are known to cause issues in the processing
> are a mindless waste of resources.
>
> Andre'
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 

Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

viktor.engelm...@qt.io
+49 151 26784521

http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Calendar Systems proposal

2017-01-30 Thread Soroush Rabiei 
> Now question is that: witch form is preferred? Will be case (1) break Qt
> rules?

I don't know about QML and it'd design principles, but I like option
3. Though it must take that calendar instance as second argument I
suppose:

var out = date.toString("/MM/dd", Qt.JalaliCalendar); // Is
this possible?

Speaking of the API, I wish to share an idea about not to put calendar
implementations in a plugin subsystem.

There are differences between those concepts that are implemented as
plugins and calendars. A calendar system is not an image format nor a
database implementation. There will be no new calendar (at least, it's
unlikely to have a brand new calendar) and there will be no newer
versions of existing calendars. What is the point of having calendars
as plugins? And we have to keep QGregorianCalendar everywhere after
all... And we will have the problem of instantiation. While plugins
have no public header, then how we are supposed to use them in code?
Like this:

QDate d;
d.setDate(y,m,d,QCalendar::fromName("jalali"));

Or maybe:

d.setDate(y,m,d,"jalali");


Let's add all calendar systems that do have locale information in
CLDR, and make all of them configurable as to be built or not, except
QGregorianCalendar. Then decide on a default subset of calendars to be
compiled into qtbase. That will be something like:

++-++++
|No. |Name |Variant |Configurable|Default |
++-++++
|1   |Gregorian||No  |Yes |
++-++++
|2   |Islamic  |Astronomical|Yes |No  |
++-++++
|3   |Islamic  |Civil (Algorithmic) |Yes |Yes |
++-++++
|4   |Persian  ||Yes |Yes |
++-++++
|5   |Hebrew   ||Yes |Yes |
++-++++
|6   |Chinese  ||Yes |Yes |
++-++++
|7   |Japanese ||Yes |No  |
++-++++
|8   |Buddhist ||Yes |No  |
++-++++
|9   |Republic of China||Yes |No  |
++-++++
|10  |Coptic   ||Yes |No  |
++-++++
|11  |Ethiopic |Amete Alem  |Yes |No  |
++-++++
|12  |Ethiopic |Amete Mihret|Yes |No  |
++-++++
|13  |Indian   ||Yes |No  |
++-++++

For historical calendars, Qt users are unlikely to add marginal
calendar systems -> A reason to avoid plugin system. Though having
current schema, they can subclass QAbstractCalendar and add their
calendar (not as a loadable plugin) in their own code.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Edward, Welbourne 
Liang Jian (29 January 2017 05:13):
>Start from qt-5.8 I can't build qt anymore under Windows(simplified
> chinese locale). Since there is a file
> src/plugins/generic/tuiotouch/qtuiohandler.cpp which contain
> non-latin-1 character, msvc2015 assume the source code's character set
> should be CP936 which make the complilation fail.

Stray thought: this sounds like something that would be fixed (on Unix)
by setting the locale-controlling environment variables, so that your
build happens in a local using UTF-8 as its encoding; hopefully, that
would then coax the compiler into using this by default and not getting
upset.  I'm not sure how that works on MS-Windows, but I'd just set
LANG=en.UTF-8 in my environment on any Unix; this would then only affect
the process in which I set it.  So it might be worth seeing if you can
do that (or something equivalent) for the process that runs configure &&
make for you.

If that *does* work ... perhaps we should hack this into our Makefiles,

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Calendar Systems proposal

2017-01-30 Thread Edward, Welbourne 
Hamed Masafi (30 January 2017 08:59):
> I'm working on qml support of calendar system,

That shall complement Soroush Rabiei's work on the C++ side:
https://codereview.qt-project.org/182341
http://bugreports.qt.io/browse/QTBUG-58404
Prior discussion:
http://lists.qt-project.org/pipermail/development/2016-December/028125.html
http://lists.qt-project.org/pipermail/development/2017-January/028234.html

> for porting this mechanism to qml we have two option:
>
> 1)
> Add a global object to jsengine?
> Somthing like that :
>
> var date = new Date;
> var cal = new JalaliCalendar;
> var out = date.toString(cal, "-MM-dd");
>
> In this case JalaliCalendar is a new global object type (like date,
> string, regex, array and etc).

If I understand Lars correctly, he prefers an API where the calendar
object carries methods that act on a date and any further arguments it
may need (similar to QLocale), so cal.toString(date, "-MM-dd") is
more likely (although I personally like the style of API you give above,
where the date object has the calendar-aware methods; too many of the
details are the same between calendar systems).  Aside from that, this
is roughly the shape the C++ API shall have, making it a natural model
for the QML to follow.

That C++ API is designed, however, with an eye on the long tail of less
widely used calendars - we aim to let their users be able to add a C++
class, possibly via a plugin, whose instances implement their calendar.
With this model for QML's API, that would require them to *also* add a
QML aspect of their C++ class.  I'm not sure how easy that is, or how
pluggable.

> 2)
> Or another option may be adding calendar() to global Qt function, the
> usage example can be like that:
>
> var date = new Date;
> var out = date.toString(Qt.calendar('jalali'), "-MM-dd");

This would require some infrastructure behind Qt.calendar() that would
let authors of calendar system classes register them so that it knows
how to instantiate them.  If that's easier than whatever it takes to add
a global object to QML (or an property of the Qt object), it might be a
good way to make life easier for calendar system implementors.

> ​3)
>
> var date = new Date;
> var out = date.toString(Qt.JalaliCalendar, "-MM-dd");
>
> In this method Qt.calendar like Qt.locale initialize with a string.

Not sure what you're proposing here - you don't mention Qt.calendar in
the code example, which looks more like 1) with JalaliCalendar moved to
the Qt object - which may indeed be a better place for it than as a
naked global object.

> Now question is that: witch form is preferred? Will be case (1) break
> Qt rules?

I don't know what rules QML might impose.  Each of these would, in one
way or another, require the calendar system code to register itself in
some way with QML, associated with the name by which QML is to refer to
it.  The details of whether that name is in the namespace of some
visible object (the ECMAScript global object or the Qt object) or in
some internal mapping (for 2) are a matter of what's practical or
convenient - someone with more QML fu than I can claim can advise you
better there.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Giuseppe D'Angelo 
Il 30/01/2017 02:21, Thiago Macieira ha scritto:
> So, we should:
>  a) still avoid non-ASCII in our source files, aside from comments
>  b) allow non-ASCII in comments, as needed

Didn't we have issues with UTF-8 in comments too, when using MSVC?

>  c) turn the -utf-8 option on for MSVC2015U3.

But just for Qt own build, not push this option onto the users. Also,
does this fix anything? Is MSVC 2015 U3 the only one complaining, and we
can live with UTF-8 in the source when using other compilers?

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Liang Jian 
https://codereview.qt-project.org/#/c/183817/

On Mon, Jan 30, 2017 at 4:42 PM, Marc Mutz  wrote:

> On Monday 30 January 2017 02:21:57 Thiago Macieira wrote:
> > qCDebug(lcTuioSet) << "Processing SET for token " << classId << id
> << "
> > @  " << x << y << "∡" << angle <<
> >
> > That's easy to fix by using "\342\210\241" instead.
>
> Which is totally and utterly opaque. So much so that one feels forced to
> add a
> comment
>
>   // ∡
>
> but then MSVC complains, too.
>
> Lose-lose.
>
> The question really is: why does this come up only now? Is it because of
> MSVC2015, and does it thus mean that only compilers that provide the /utf-8
> option warn? In that case, the correct thing is to enable the option and
> leave
> UTF-8 chars in the source alone.
>
> Thanks,
> Marc
>
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> 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] Policy for examples with large resources?

2017-01-30 Thread Julius Bullinger 
Hi Konstantin

On Friday, 27 January, 2017 at 17:48, Konstantin Tokarev wrote:
> 27.01.2017, 19:41, "Oswald Buddenhagen" :
>> On Fri, Jan 27, 2017 at 03:48:54PM +, Sean Harmer wrote:
>>>  Is there a way we can get a git-lfs repo set up as a submodule to be
>>>  referenced by the qt3d repo?
>>
>> sure. you just need to prototype a solution which i can deploy to our
>> server. as of now, you have gerrit 2.7 and apache at your disposal.
>>
>>>  Or is there some other solution that would be preferred?
>>
>> one quite ugly variant is doing poor man's "lfs" by putting a script in
>> the repo which uses wget and such to fetch data from some well-known
>> location. the file names on the server should be versioned, of course.
>> the problem is of course reviewing and uploading the files ...
> 
> Another variant which is similar but (arguably) somewhat less ugly is to put
> assets into Conan[1] package. We already have necessary qt5.git infrastructure
> in place.
> 
>  [1] https://www.conan.io/

What do you mean by "We already have necessary qt5.git infrastructure in place"?

As a Conan user myself, I'd like to learn more about these packages. Are there 
official Qt packages for Conan available? I've found a few unofficial ones, but 
didn’t know anything about official support. Could you provide a link or some 
documentation?

Thanks,

Julius
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

2017-01-30 Thread Marc Mutz 
On Monday 30 January 2017 02:21:57 Thiago Macieira wrote:
> qCDebug(lcTuioSet) << "Processing SET for token " << classId << id << "
> @  " << x << y << "∡" << angle <<
> 
> That's easy to fix by using "\342\210\241" instead.

Which is totally and utterly opaque. So much so that one feels forced to add a 
comment

  // ∡

but then MSVC complains, too.

Lose-lose.

The question really is: why does this come up only now? Is it because of 
MSVC2015, and does it thus mean that only compilers that provide the /utf-8
option warn? In that case, the correct thing is to enable the option and leave 
UTF-8 chars in the source alone.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development