[Development] [QtIFW] [Review Request] Relocatable Repository Set

[Konstantin Podsvirov]

Hello QtIFW developers!It's my first change.Can anybody review and merge It:https://codereview.qt-project.org/#/c/163220/Regards,Konstantin Podsvirov
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

[Ralf Nolden]

Am Mittwoch, 22. Juni 2016, 05:03:28 schrieb Jani Heikkinen:
> Hi!

> But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1
> would work then it is really ok for me to change the tag. But let's don't
> change that just because of opinions...
The naming scheme for alpha, beta, rc's is - so the 
packager scripts get all confused up assuming it's non-standard and not a 
patch release. If 5.6.2 is impossible, please go with 5.6.1.1


> And if for some reason it was too difficult to bump everything that was
> scheduled for 5.6.2 to 5.6.3, then at the very least we should have used
> v5.6.1.1, which is probably what everyone making Qt packages will need to
> use since a dash is completely unacceptable in release versions.
Ack
> 
> I propose that we delete the bad tag, retag and rerelease with a better
> name.
Ack
> 
> Let's not make rash decisions again.
> 
> --
> 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

-- 
Kind regards,

Ralf Nolden

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

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

[Jani Heikkinen]

Hi!


Actually https://bugreports.qt.io/browse/QTBUG-53761 is a blocker. Priority 
isn't correct at the moment but in reality the bug is preventing any bigger and 
a bit complex applications working correctly. Unfortunately bug isn't 
describing that well enough :(


That's why we need to update the packages just with that one fix. And that's 
why it isn't new 5.6.2 release (in my opinion), it is just 5.6.1 + hotfix. 
There was already request 'because you are doing new release please include 
this fixes' etc :) and that is unfortunately impossible now, just before summer 
holidays, sorry.


And what comes to tag: we have used '-1' tag earlier (in enterprise 
repositories) and we didn't see any reason to change that 'hotfix' tagging 
scheme. It was discussed in irc as well but at least for me no-one really says 
why '-1' pattern is wrong. There was just opinions for and against and because 
we have used '-1' tag earlier it was selected this time as well. Another reason 
was the package naming: We have some tools which cannot handle 5.6.1.1 but can 
handle 5.6.1-1 in package names and it is better to use same format in the tag 
what is used in package names.


But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1 would 
work then it is really ok for me to change the tag. But let's don't change that 
just because of opinions...


br,

Jani






From: Development  on 
behalf of Thiago Macieira 
Sent: Wednesday, June 22, 2016 2:42 AM
To: releas...@qt-project.org
Cc: development@qt-project.org
Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 
packages

On quinta-feira, 16 de junho de 2016 10:38:02 PDT Jani Heikkinen wrote:
> Unfortunately we noticed https://bugreports.qt.io/browse/QTBUG-53761 is
> actually a brown paper bag issue for Qt 5.6.1 release. That's why we need
> to update release packages with change
> https://codereview.qt-project.org/#/c/162677/ . We will "release" new
> packages (Qt 5.6.1-1) as soon as fix is in qt5.git & we have created and
> tested the packages from new content. It is much easier and safer to select
> that option instead of releasing Qt 5.6.2 before summer vacations.

I've just noticed this email.

QTBUG-53761 is not P0, so it did not warrant new packages.

The naming for the new tag is totally unacceptable. It should have been
v5.6.2. We own up to our errors. If 5.6.1 wasn't good enough for anyone, then
we release v5.6.2 immediately after.

And if for some reason it was too difficult to bump everything that was
scheduled for 5.6.2 to 5.6.3, then at the very least we should have used
v5.6.1.1, which is probably what everyone making Qt packages will need to use
since a dash is completely unacceptable in release versions.

I propose that we delete the bad tag, retag and rerelease with a better name.

Let's not make rash decisions again.

--
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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

[Thiago Macieira]

On quinta-feira, 16 de junho de 2016 10:38:02 PDT Jani Heikkinen wrote:
> Unfortunately we noticed https://bugreports.qt.io/browse/QTBUG-53761 is
> actually a brown paper bag issue for Qt 5.6.1 release. That's why we need
> to update release packages with change
> https://codereview.qt-project.org/#/c/162677/ . We will "release" new
> packages (Qt 5.6.1-1) as soon as fix is in qt5.git & we have created and
> tested the packages from new content. It is much easier and safer to select
> that option instead of releasing Qt 5.6.2 before summer vacations.

I've just noticed this email.

QTBUG-53761 is not P0, so it did not warrant new packages.

The naming for the new tag is totally unacceptable. It should have been 
v5.6.2. We own up to our errors. If 5.6.1 wasn't good enough for anyone, then 
we release v5.6.2 immediately after.

And if for some reason it was too difficult to bump everything that was 
scheduled for 5.6.2 to 5.6.3, then at the very least we should have used 
v5.6.1.1, which is probably what everyone making Qt packages will need to use 
since a dash is completely unacceptable in release versions.

I propose that we delete the bad tag, retag and rerelease with a better name.

Let's not make rash decisions again.

-- 
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

[Development] v5.6.1-1 tag should have been v5.6.2

[Thiago Macieira]

There's no reason to invent new naming schemes.

-- 
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] Revisiting high-DPI configuration options

[Thiago Macieira]

On terça-feira, 21 de junho de 2016 18:02:05 PDT Morten Sorvig wrote:
> I think using screen names can be a good match for cases where you are
> sometimes connecting to external screens, provided that the string returned
> by name() is unique for each screen.

It's not. It's always "DP-1" (it reports the connection, not the monitor).

-- 
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] Revisiting high-DPI configuration options

[Morten Sorvig]

> On 17 Jun 2016, at 22:49, Thiago Macieira  wrote:
> 
> 
> Creator is also a bad citizen (worst of all Qt 5 applications I've tested), 
> but I did not test it again in the scenarios above. When I tested before, I 
> had to find the right combination that would make both the QML and non-QML 
> parts of the UI look reasonable. Under some configurations, the text editor 
> was 
> the right size but the Welcome screen, the left and bottom panels would look 
> too big, etc.

Creator’s lot in life - taking the fall for bugs in Qt :)

Anyway, inconsistencies like these is something I’m seeking to avoid with the
new patches: we want to have uniform scaling for all app content where 
everything
comes out either correct or not. This should make it easier to judge what 
effects
setting options has.

If you’re still seeing things like this even with the most recent patches
(see update below) that’s something I think we should take a closer look at.

> But you apparently removed the ability to set the scaling per-monitor. So 
> this 
> brings Qt back on par with other X11 HiDPI-aware applications. Hence the 
> reply 
> I get from everyone: use Wayland.

Yes. I left that one out in my description, the code was still there.
I made a couple of the changes to the implementaton (see commit de827565)
and included it in the --metrics output.

The configuration workflow is now:

1) Set Qt::AA_EnableHighDpiScaling or QT_AUTO_SCREEN_SCALE_FACTOR=1

   This will use the per-screen logical DPI as reported by the
   platform plugin.

2) If not happy then

2a) Override the global logical DPI: QT_FONT_DPI=N

2b) Use physical DPI: QT_USE_PHYSICAL_DPI=1

2c) Set scale factors manually: 
QT_SCREEN_SCALE_FACTORS=2;1;
QT_SCREEN_SCALE_FACTORS="externalMonitor=2”

This will disregard the DPI values the platform plugin reports for
the screens in question. The screen name in the second form is
QScreen::name(). (Using the screen name is possible already in 5.6).

2d) Perhaps tweak the rounding policy. (factors directly specified in env.
variables are not rounded).


I think using screen names can be a good match for cases where you are
sometimes connecting to external screens, provided that the string returned
by name() is unique for each screen.


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

Re: [Development] Revisiting high-DPI configuration options

[Samuel Stirtzel via Development]

2016-06-21 14:15 GMT+02:00 Shawn Rutledge :
>
>> On 20 Jun 2016, at 18:09, Thiago Macieira  wrote:
>> 160x90 mm is a valid screen size, correspoding to a 7.2" monitor.
>
> Of course, it’s just suspicious (being a fallback value, apparently), but not 
> impossible.

Unfortunately it's not a fallback value, instead TV manufacturers
commonly only set the aspect ratio (in cm) because one EDID for all
devices is cheaper.
See bullet point d of Adam Jacksons mail about the EDID -> DPI topic:
https://lists.fedoraproject.org/pipermail/devel/2011-October/157671.html


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

[Development] Binary compatibility report for Qt 5.7.0

[Ponomarenko Andrey]

Hello,

The binary compatibility report for the Qt 5.7.0 is ready: 
http://abi-laboratory.pro/tracker/timeline/qt/

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

Re: [Development] Revisiting high-DPI configuration options

[Maurice Kalinowski]

> 2) Handling fractional scale factors
> 
> This is relevant for e.g. a Windows setting of 250%, corresponding to a scale
> factor of 2.5. Presenting a fractional scale factor to the app may cause
> graphics glitches, so we round it to the nearest integer, using qRound.
> 
> However, mathematically correct rounding may not be the best kind of
> correct in this case. In particular we should consider rounding factors of .5
> down instead of up. The effect would be presenting an UI that is visually
> slightly smaller than it should be, over the current behavior of presenting an
> UI that is slightly larger.
> 
> In addition we have the option of tweaking the DPI reported to the
> application to account for the remainder from the rounding.
> So for the 250% case we can report a devicePixelRatio of 2 and a DPI of 144.
> This relies on the existing DPI handling support (fonts scale automatically,
> rest of UI may not), but since the offset from the base DPI is small it might 
> be
> OK.
> 
> Finally, we should consider adding an option to simply let the fractional 
> scale
> factor through. We have user reports of applications that work fine with such
> factors, save for one or two bugs in Qt. These are typically custom-styled
> applications that do not rely on the Qt platform styles.
> Allowing this as an option would not mean that fractional factors are
> supported in Qt (for the formal meaning of “supported"), nor that we
> necessarily spend time on fixing related issues.
> 
[Kalinowski Maurice] 
+1 from my side. On WinRT / Windows Phone / UWP, you will hardly see an integer 
scale factor. That causes troubles when developers want to have native scaling 
and we forbid this internally.

As you mentioned, we have users who patches this part and they seem to be happy 
with what works then already. If painting glitches appear, we need to be sure 
to document why that is and what potential workarounds one could apply.

BR,
Maurice

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

Re: [Development] Revisiting high-DPI configuration options

[Shawn Rutledge]

> On 20 Jun 2016, at 18:09, Thiago Macieira  wrote:
> 
> On segunda-feira, 20 de junho de 2016 14:30:19 PDT Shawn Rutledge wrote:
>> Don’t you think there should be a quirks database somewhere (outside of Qt)
>> which corrects these cases?  The TV model can be identified, right?
> 
>> X does it, but that’s not a broad enough scope to cover Wayland.
>> 
>> https://wiki.ubuntu.com/X/Quirks#Monitor_Quirks 
>> 
>> Maybe it could be done with udev rules or something.  If there is really not
>> yet a proper solution on Linux, there should be, IMO.
> 
> We would need a correction database, not just a quirks one.

I thought that in common usage in the context of device drivers and their 
configuration, “quirks” are certain characteristics that are 
overridden/corrected for certain identifiable devices.

> 160x90 mm is a valid screen size, correspoding to a 7.2" monitor.

Of course, it’s just suspicious (being a fallback value, apparently), but not 
impossible.

But assuming the model of your TV is unique and can also be read over EDID 
(like most monitors), the size could be corrected.  I have the same issue with 
a Samsung SyncMaster 2494HM at the office, and have been wondering why X 
doesn’t “quirk” it by default.  From the xorg log on Arch Linux:

[   266.313] (II) RADEON(0): EDID for output HDMI-0
[   266.313] (II) RADEON(0): Manufacturer: SAM  Model: 4d5  Serial#: 1263088180
[   266.313] (II) RADEON(0): Year: 2010  Week: 38
…
[   266.313] (II) RADEON(0): Supported detailed timing:
[   266.313] (II) RADEON(0): clock: 148.5 MHz   Image Size:  160 x 90 mm
[   266.313] (II) RADEON(0): h_active: 1920  h_sync: 2008  h_sync_end 2052 
h_blank_end 2200 h_border: 0
[   266.313] (II) RADEON(0): v_active: 1080  v_sync: 1084  v_sync_end 1089 
v_blanking: 1125 v_border: 0
…

I’m guessing that "Manufacturer: SAM  Model: 4d5” is probably enough to 
identify it.  Or use the year and week if necessary.  There would need to be a 
web site to give feedback to add to the quirks database (similar to the way you 
can register unidentified USB devices on linux-usb.org): if various people with 
the same monitor, with different production dates, report the same problem, a 
pattern would emerge: for what period of time was this company making this 
mistake.  Then it could go into the quirks.  Or some distros could auto-report 
the EDIDs that are discovered - then it would be a matter of auditing them to 
see how many are uniquely identifiable and which of those are likely to contain 
wrong values for physical size.

I do also see several cases like this in the log:

[   266.313] (II) Quirked EDID physical size to 0x0 cm

which is not very useful…

But quirks should IMO belong to the kernel, or to udev (depending whether udev 
can see when any kind of monitor is hotplugged), or to some library that 
corrects monitor EDIDs, not just to X.  Qt could do it, cross-platform even, 
but we shouldn’t have to.

Ah (googles it again) here we go:

https://wiki.ubuntu.com/X/MonitorsDatabaseOnline

Sounds good.  But somehow it hasn’t resulted in corrected EDIDs being available 
everywhere.  But Ubuntu 16.04 does correct the EDID for my monitor!  I hadn’t 
noticed before.  (Maybe it knows about your TV too?)  And the qscreen manual 
test reports correct dimensions.  So, the other distros ought to be reusing 
Ubuntu's quirks database, I guess.  But maybe it’s only an online database so 
far.  On KDE though, http://www.simonzone.com/software/guidance/ was supposed 
to be using it (although I don’t see evidence of that in the code).  But I 
suppose there’s a political problem with having the latest (e.g.) KDE control 
panel depend on some Ubuntu online service to look up monitor EDID corrections. 
 (So far I’m having trouble finding the URL for that service.)  So ideally 
Canonical ought to give permission to package up their database and allow 
shipping it with other distros too; or maybe it can start to be hosted on a 
wider-community website.  The downside is that the updates to the quirks that 
ship with distros would tend to be slow (like adding USB IDs so that lsusb 
knows about them - it takes at least a few months, typically).

http://forums.fedoraforum.org/showpost.php?s=4dd2d2dbdc3131f2ad45a3f23b82d2d6=1695752
 has some different info.  I found that this works as a way of reading the EDID 
at any time:

parse-edid < 
/sys/devices/pci:00/:00:07.0/:05:00.0/drm/card0/card0-HDMI-A-1/edid

It seems that nVidia X drivers have a config option for overriding EDID, but 
the others apparently don’t.  If they all did, the quirks could go in 
/usr/share/X11/xorg.conf.d/10-quirks.conf.  But anyway, we want a solution that 
goes beyond X.

Microsoft also has inf files for correcting EDID:

https://msdn.microsoft.com/en-us/library/windows/hardware/jj133967(v=vs.85).aspx

so if manufacturers (sometimes) already provide the inf files, maybe Linux 
ought to be able to use those somehow.  

Re: [Development] Coin will be down on Tuesday 21st of June (6am-8am UTC+3)

[Jędrzej Nowacki]

On Tuesday 21 of June 2016 10:47:29 Jędrzej Nowacki wrote:
> On Thursday 16 of June 2016 16:22:15 Jędrzej Nowacki wrote:
> > There is datacenter hardware maintenance break on Tuesday 21st of June
> > (6am-8am UTC+3), Coin will be shutdown a bit earlier and hopefully restart
> > after.
> > Cheers,
> > 
> >  Jędrek
> 
> Seems that something got completely broken, Coin is down. Sorry.
> 
> Cheers,
>  Jędrek

Seems to work Ok for last 50 min :-)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Coin will be down on Tuesday 21st of June (6am-8am UTC+3)

[Jędrzej Nowacki]

On Thursday 16 of June 2016 16:22:15 Jędrzej Nowacki wrote:
> There is datacenter hardware maintenance break on Tuesday 21st of June
> (6am-8am UTC+3), Coin will be shutdown a bit earlier and hopefully restart
> after.
> Cheers,
>  Jędrek

Seems that something got completely broken, Coin is down. Sorry.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposing David Schulz as maintainer for QtC text editors and CDB integration

[Erik Verbruggen]

cdb integration: +1

text editors: +2 (he should have taken over maintainership from me ages ago...)


-- Erik.


From: Development  on 
behalf of Eike Ziller 
Sent: 17 June 2016 13:52:49
To: 
Cc: qt-creator
Subject: [Development] Proposing David Schulz as maintainer for QtC text 
editors and CDB integration

I propose David Schulz for Maintainer status for Qt Creator text editors and 
CDB integration.

He has a long history in Qt Creator and factually maintained these areas for a 
long time now.

https://codereview.qt-project.org/#/q/owner:%22David+Schulz+%253Cdavid.schulz%2540theqtcompany.com%253E%22,n,z

Br, Eike

--
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
+123 45 6789012
http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
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