Re: [Development] Request for early MOC support for C++20 Modules

[Sune Vuorela]

On 2023-12-15, Elias Steurer via Development  wrote:
> No, I still need all the get/set/notify functions to change/get the 
> variables from the outside. There is currently no way to do that, or am 
> I missing something? Something like this 
> https://gitlab.com/kelteseth/ScreenPlay/-/blob/master/ScreenPlayUtil/inc/public/ScreenPlayUtil/PropertyHelpers.h?ref_type=heads#L52
>  
> but as a standardized Qt macro.

My experience, after having written a few macros like that out of
projects, is that it is a bad idea, unless it is really thought thru.

What I have seen is that it encourages all properties to be
read/write/notify where at least many of them was only supposed to be
read/notify or read/constant.

/Sune

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] API style guide: scoped enum or not?

[Sune Vuorela]

On 2023-05-04, Marc Mutz via Development  wrote:
> So, enum-backed APIs taking int will have to be ported to take the enum 
> instead. On the plus side, you get type-richer and safer APIs.

How would you do the extensions (e.g. user roles or user events) 
if you convert to enums ?

/Sune

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] API style guide: scoped enum or not?

[Sune Vuorela]

On 2023-05-04, Marc Mutz via Development  wrote:
> that keeps unported code running. The main issue isn't the scoping, the 
> main issue will be the missing implicit conversion to underlying_type.

In few cases the implicit conversion to underlying_type is kind of important.

Especially in the cases where the api has int and is mostly used with
enums or is somehow user extendable.

Qt::ItemDataRole is one of them that comes to mind.

switch(role) {
   case Qt::UserRole+1:
   

QEvent::Type is another one where one registerEventType, recieves an int
and then force-cast it to QEvent::Type and still compares back to that
int in other places.


There are definitely more.

/Sune

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Raising the minimum to C++20

[Sune Vuorela]

On 2023-05-03, Thiago Macieira  wrote:
> 13, while Ubuntu 22.04 and Debian 11 (current stable) have GCC 11. Debian 
> will 
> probably release its next stable before Qt 6.7, though whether it'll still 
> upgrade from GCC 12 to 13 I don't know. When we released Qt 6.0, our minimum 

Debian 12 "Bookworm" is planned for june 10th, and will be with gcc 12.

/Sune

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Sune Vuorela]

On 2020-11-17, Kai Köhne  wrote:
> Why should the packages in the online installer change? They are hardly ever 
> installed into some general directory.

To have documentation be "Run this command `foo`". not "If you are
running linux or mac and have gotten your Qt the normal way thru your
packagemanager, run `foo-qt6`, if you are on windows or have done the qt
installer, run `foo`"

/Sune

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

Re: [Development] Qt 6 co-installability with Qt 5

[Sune Vuorela]

On 2020-11-02, Lars Knoll  wrote:
> I honestly don't think renaming all our binaries is an option, certainly not 
> that late in the process. We’ve had Qt 4 and Qt 5 co-installed for a long 
> time as well and while that might not be perfect it was working.
>
> And qtchooser has been working nicely for me (Ubuntu at least uses it).

I pushed quite hard to use it Debian (and ubuntu inherited it), but it
is also a tool that from a packaging perspective gets in the way. Gives
surprises. and weird systems for people.

I also think it is sane to 1) EOL Qt Chooser. 2) Add version numbers to
all public facing executables. (See also e.g. python2 vs python3). and
3) and do it in Qt so that distros are constistent with eachother, with
windows, with mac, and with the Qt documentation.

Oh. And I'm surprised by the Qt-people sudden love of QtChooser - I had
a quite hard battle getting just rudimentary support into Creator to
support the Qt's setup there.

/Sune

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

Re: [Development] QList for Qt 6

[Sune Vuorela]

On 2019-05-23, Lars Knoll  wrote:

I'm a bit late to this game, but ...
> I don’t see why you’d want to remove the switch for Qt 6. 
> It would be a porting help for application developers.

Application developers will not build their own Qt, but rely on the
QList with the switch their Qt and Qt-using 3rd party libraries are
built with.

And how does it work if different 3rdparty qt libraries requires the
switch differently?

/Sune
 - Qt, KDE and Debian guy at night. Qt & c++ freelancer by day.

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

Re: [Development] Proposal: New branch model

[Sune Vuorela]

On 2019-01-25, Lars Knoll  wrote:
> * I think it makes the life of casual/new contributors easier. Simply always
>   develop and push against the development branch. The more experienced
>   reviewer can then easily decide that the fix should be cherry-picked into a 
> stable branch.

I'm mostly a casual contributor, mostly dealing with fixes to bugs found
in specific releases. I'm doing my fixes in those releases. Because
that's where I need them. If I could just then push it and more or less
forget about it, that's the thing that would make it easier.

This seems to me that I need to move the fix forward to dev, then push
it, then backport it. I might not even have a dev build handy. Because
I'm basing my work on top of something released.

/Sune
 - independent contractor, KDE Developer and Debian Developer

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

Re: [Development] QUIP 12: Code of Conduct

[Sune Vuorela]

On 2018-10-28, Thiago Macieira  wrote:
> But if it isn't spam, what gives the list moderator the right to intervene in 
> something that he/she believes is abusive behaviour? Same thing about IRC: we 
> do have one annoying person who does come along every now and then, but most 
> of his messages are just that: annoyance. It's only when he uses profanity 
> that I feel justified in kicking him out of the channel.
>
> Am I the one abusing my position as channel op to kick him? Am I being 
> arbitrary?

I feel you are using your position as chan op to kick him far too rare.
But I'm not sure where to bring that up.

/Sune
 - also these days in favour of a CoC, but has also protested against
   such things in the past.

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

Re: [Development] Orphan modules

[Sune Vuorela]

On 2018-09-12, Gatis Paeglis  wrote:
> +1 for deprecating qtx11extras as well and moving the code closer to actual 
> plugin. It is frustrating to have all that boilerplate code for 1 header file 
> - qx11info_x11.h

I think it makes sense to have qtx11extras. A stable api and abi that
X11 users can rely on.

I see the only alternative is to provide stable apis in QPA and friends
instead. But that has so far been refused.

/Sune

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

Re: [Development] Stepping down as maintainer

[Sune Vuorela]

On 2018-03-19, Denis Shienkov  wrote:
> As I can see recently, is is not a good tendence in Qt... Many peoples 
> leaves from Qt.. What happens? Or I'm mistake? :)

Let's do some math.

There is around 160 maintainer positions in Qt (a quick count of  on 
the maintainers wiki page)

Many maintainers are a maintainer as part of their job duties. Not many
people these days have the same job for more than 5-6 years. If it takes
1-2 years to get to a state to become maintainer, that leaves around 4
years as a maintainer.

If we assume that the maintainer is around for 4 years and there is
effective 10 months per year, then we should have 4 replacement
maintainers each month.

I'm not sure I see something worrying in numbers alone.

/Sune


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

Re: [Development] syncqt.pl in C++

[Sune Vuorela]

On 2017-03-08, Jake Petroules  wrote:
> I'm working on the qbs bootstrapping. The requirements will be: a C++11 com=
> piler. End of requirements. Seriously. Not even bash, if you don't mind typ=
> ing a couple commands manually.

I don't mind a bat script, a bash script or whatever is needed, but
that sounds great.
>
> Qt could then include a tiny bootstrap script which downloads and bootstrap=
> s qbs, then builds Qt (but the normal use case would be that you already ha=
> ve qbs installed).

I really think that building Qt  in the normal usecase would not involve
using Qt libraries. And a normal build setup should not touch the
network at all.

/Sune

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

Re: [Development] syncqt.pl in C++

[Sune Vuorela]

On 2017-03-07, Lars Knoll  wrote:
> This also makes qbs a natural choice to also use for Qt itself, and I belie=
> ve all the people that have worked and maintained Qt's build system over th=
> e last few years are supporting this. Of course this requires that we can s=
> how that qbs can be used to build Qt.

I expect this also includes "Can be bootstrapped" and "Does not require
a qbs executable obtained from elsewhere with all dependencies". And
maybe even "Can be built on platforms where v4 isn't yet
ported."

/Sune


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

Re: [Development] Calendar Systems proposal

[Sune Vuorela]

On 2016-12-17, Soroush Rabiei  wrote:
> it's wrong to add such implementation to QDate. My view of QDate is this:
> QDate represents a day in time. So it only needs to know what day it is
> (how many days are to the day 0).

And it is exactly things like that that would prevent partial date
support in QDate (which is why I brought it up)

/Sune

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

Re: [Development] Calendar Systems proposal

[Sune Vuorela]

On 2016-12-15, Soroush Rabiei  wrote:
> 2.History
>

Hi

I would welcome more calendar systems.  Personally I hope for french
revolutionary calendar. Because it is funny.

I think you need to touch quite some of the 'inner bits' of date / time,
and while you are there, I'd love if the design could make it easier to
implement my two missing pet features:
 - Partial dates
 - Date/time intervals/delta's.

You might need the latter part for the implementation.

(By partial dates, I mean e.g. my friend has birthday on november 1st.
every year. or unknown year.)

(by date/time deltas, I e.g. I started working somewhere on november 1st
2014. and stopped january 3rd 2015. How long did I work there)

/Sune

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

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Sune Vuorela]

On 2016-09-23, André Pönitz  wrote:
> That gives already "surprising" behaviour if fed with QChar('a') and
> QString("a") in a row.
>
> And it is "surprising" to a degree that I'd call it buggy.

Then try feeding it boolean's and strings.

QQmlPropertyMap map;
map.insert(QLatin1String("key1"),true);
map.insert(QLatin1String("key1"),QLatin1String("p"));
QCOMPARE(map.value(QLatin1String("key1")).toString(),QLatin1String("p"));
QCOMPARE((int)map.value(QLatin1String("key1")).type(),(int)QMetaType::QString);
map.insert(QLatin1String("key1"),false);
map.insert(QLatin1String("key1"),QLatin1String(""));
QCOMPARE((int)map.value(QLatin1String("key1")).type(),(int)QMetaType::QString);

(Taken from https://codereview.qt-project.org/#/c/121715/1//ALL when I
was trying to fix things but ... kind of moved on)

/Sune

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

Re: [Development] Qt 5.8 API review (vs 5.7.0)

[Sune Vuorela]

On 2016-09-09, Edward Welbourne  wrote:
> https://codereview.qt-project.org/170634 -- qtbase

Added some comments. Though didn't detailed read all template magic.
One enum have reordered some members. This is likely an issue.

> https://codereview.qt-project.org/170635 -- qtdeclarative

Kind of looks ok to me from a BC standpoint. 

> https://codereview.qt-project.org/170637 -- qtmultimedia

OK. Single added enum and single added function.

> https://codereview.qt-project.org/170638 -- qttools

How much of this is actually changes in installed headers, and how much
is just internal stuff ?


> https://codereview.qt-project.org/170647 -- qtwebengine

How much of this is external api, and how much is internal ?
Comment on one set of the api provided.

/Sune

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

Re: [Development] Notes on QtCore session @ QCS2016

[Sune Vuorela]

On 2016-09-05, Giuseppe D'Angelo  wrote:
>> * C++ ABI
>> * libstdc++ still breaking compatibility in std::function
>> * not now, revisit in a year or two
>
> There hasn't been time to discuss this at QtCon, but I'd say we should
> not spend another year before revisiting this at the next QtCS: do we
> really care about C++ ABI compatibility? What other C++ libraries are
> doing this? Do users really expect to swap out standard library

one of the problems is that libstdc++ broke the abi between 4.9 and 5.0
for std::function without any compatibility things like for the other
ones, because c++11 was only "experimental" until then.

And I think that std::function is maybe the primary candidate for a
thing we want to use.

/Sune

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Sune Vuorela]

On 2016-09-05, Andrew Knight  wrote:
> tl;dr: Lots of discussion on the merits of which build system (CMake, 
> Qbs) should replace qmake in building Qt; lots of supporters of CMake 
> but no volunteers to do the work, many reasons to use Qbs as well. Some 

I do think that there is volunteers to get Qt building with cmake if
there is a likly chance of getting it accepted. I think I also
commmunicated that at the session.

/Sune

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

Re: [Development] Would it make sense to make QObject moveable in Qt 6?

[Sune Vuorela]

On 2016-08-24, Thiago Macieira  wrote:
> And its address is copyable, so if we replaced the pointer with something, 
> we'd have to use something copyable and non-owning.

class QObjectHandle {
public:
   QObjectHandle(QObject* obj) : m_obj(obj) { }
   operator QObject* () const ( return m_obj.data() }
   bool operator==(const QObjectHandle& other) const { return m_obj ==
   other.m_obj;}
   // default created rest of it is fine
private:
   QPointer m_obj;
}

There. made it. Unsure what it gains us.

/Sune

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

Re: [Development] New repository for QtOAuth

[Sune Vuorela]

On 2016-08-12, Fredrik de Vibe  wrote:
> We have recently been working on an implementation of OAuth (1+2), and 
> this is now approaching a state in which it can be distributed as a tech 
> preview. For this we'll need a new public repository.

there is a handful of external projects doing oauth with qt. Have
anything been done to ensure applications don't blow up if several
libraries gets loaded into the same process?

The ones I've found seems to have some of the following distinguishing
marks

One puts everything in namespace QOAuth and has a QtOAuth header

One seems to put everything with O0foo O1foo and O2foo

another one seems to name everything like KQOAuthfoo (and despite the
name, I don't think it has any ties to the KDE project)

and one just with a class OAuth2, and this one looks a bit like example
code.


So, depending on how the qt project qtoauth is done, it might conflict
to some degree with the first of them.  The first of them is also
available in Debian and other linux distributions as qoauth (libqoauth1
and libqoauth-dev)

> The main reason for OAuth to reside in its own module (and not as a part 
> of qtnetwork) is that it is specialized, and most qtnetwork users won't 
> need it. This avoids increasing the footprint of, and unnecessary 
> complexity in, qtnetwork. Another reason is that OAuth, while depending 
> on and using networking mechanisms, isn't in itself really a networking 
> mechanism.

Agreed.

/Sune

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

Re: [Development] leak in QMetaObject?

[Sune Vuorela]

On 2016-07-14, Thomas Senyk  wrote:
 I see neither one nor the other. I see continues 100% consume with no
 memory consumption drop what so ever.
> should "fix" it? .. but I still see 100% cpu and same memory consumption?

I debugged some time ago a case of a unresponsive application (for 30
seconds on a fairly beefy windows machine with sufficient ram)

There was a memory leak that involved leaking connections to lambdas of
the pattern:

m_foo = std::make_shared();
(void)connect(m_foo.get(), ::someSignal, [m_foo]() {
  });

But a interesting point here was that after leaking some thousand
objects, the application became crawling when recreating most of the
UI's quickitems. There was still plenty of memory free on the system.

Plugging this leak didn't do much for the memory consumption of the
application, but the speed of the 'recreate ui' didn't slow down over
time any longer, at least within the testing done with that.

(This was qt5.4.1)

I haven't gotten around investigating it any further. But it kind of
feels relevant here.

/Sune
(I wrote a bit more of that code on http://pusling.com/blog/?p=446
should anyone be curious)

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

Re: [Development] QImage::transformed returns shallow copy for QTransform::TxNone matrix type.

[Sune Vuorela]

On 2016-07-11, Allan Sandfeld Jensen  wrote:
> On Monday 11 July 2016, Benjamin TERRIER wrote:
>> QImage::detach() is not public API.
>> However QPixmap::detach() is, so why QImage::detach() couldn't be made
>> public too?
>> 
> It probably should be. It is a lot more sensible to use than copy(rect()).

https://codereview.qt-project.org/#/c/164886/

/Sune

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

Re: [Development] Use of Standard Library containers in Qt source code

[Sune Vuorela]

On 2016-07-01, Thiago Macieira  wrote:
> confusing because the next line has "isEmpty". When I read this code, I had 
> to 
> wonder if that "empty" was a verb in the imperative, meaning the author was 
> trying to remove all elements from the container. 

Hah. I found some code in a large project the other day. The code is a
monstrosity of stl, mfc and qt code.
There was an empty() function. It returned void. and was not const.

Yes. it was clearing its internal collections and states.

/Sune

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

Re: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ?

[Sune Vuorela]

On 2016-06-14, Konstantin Tokarev  wrote:
> QScopedPointer lacks custom deleters which make it unusable for the purpose 
> of managing Windows HANDLEs (see original post).

You can pass your own classes as handlers, provided that they have a
public static function void cleanup(T *pointer).

 - from the documentation.

/Sune

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

Re: [Development] QTBUG-52360: is ARMv5 still supported?

[Sune Vuorela]

On 2016-04-05, Thiago Macieira  wrote:
> If it is, can someone try a regular toolchain for that platform with Qt 5.6 
> and report whether QtCore links? I'd like a second opinion with a different 
> toolchain than the reporter.

looks like 5.6 is built in debian/experimental on armel (v4t/v5)

build log:

https://buildd.debian.org/status/fetch.php?pkg=qtbase-opensource-src=armel=5.6.0%2Bdfsg-2=1458264198

Toolchain package versions: binutils_2.26-6 dpkg-dev_1.18.4
g++-5_5.3.1-11 gcc-5_5.3.1-11 libc6-dev_2.22-3 libstdc++-5-dev_5.3.1-11
libstdc++6_5.3.1-11 linux-libc-dev_4.4.4-2

The current patch series is in debian is:
http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/tree/debian/patches?h=experimental

and mostly look like backports to me or otherwise irrelevant to this

The configure line is a bit .. convoluted .. but can be somehow seen here:

http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/tree/debian/rules?h=experimental

Doesn't look like it has anything special.

/Sune

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

Re: [Development] gerrit : pointers to use it cleverly/efficiently?

[Sune Vuorela]

On 2016-03-29, René J.V  Bertin  wrote:
> Can someone point me in the right direction, maybe to a tutorial of sorts 
> that outlines how to do several code reviews from a single working copy?
>
> I'm not exactly familiar with using branches; I just tried to create one, 
> apply a patch, commit it and then push to gerrit.
> That was a bit of a failure; the commit to my local branch was also applied 
> to the branch I thought I'd branched off, and the push to gerrit was refused:

Yesterday, I created a review for a bug fix. This is more or less my
shell history:

git checkout 3.6 #start from 3.6 branch. qtcreator fix
git checkout -b readonly-reformat # create a branch, reformatting of qml

vim/kate/qtcreator/whatever your sources
make, make test, 

git add 
git commit
git push origin HEAD:refs/for/3.6
#oops missing change id
git commit --amend #add changeid
git push origin HEAD:refs/for/3.6
#read sanitybot comments
vim/kate/...
git commit --amend 
git push origin HEAD:refs/for/3.6

Add reviewers.

For next change, go to start.
When reviews come in, go back to this branch 

git checkout readonly-reformat
#hack hack hack
git add
git commit --amend
git push origin HEAD:refs/for/3.6

/Sune

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

Re: [Development] debug symbols for official Qt releases

[Sune Vuorela]

On 2016-03-01, Milian Wolff  wrote:
> b) Apparently there are never any debug symbols shipped for the release build 
> fo Qt. Having debug symbols even for a release build is crucial for a good 
> profiling experience. Could we maybe get release builds in the future with -
> force-debug-info to improve this situation? I'm aware that one can get some 
> sense out of a profiler when only the end-level application is build in that 
> way, but one can often get much more insight when the stack below (or even in-
> between for the eventloop and signal/slot magic) also gets annotated stack 
> frames. Right now, I have to suggest people to build Qt themselves for the 
> sole purpose of profiling... A pity!

This would be amazing. Also for getting better backtraces from crashes
at users systems.

/Sune

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

Re: [Development] API/ABI changes report

[Sune Vuorela]

On 2016-02-11, Thiago Macieira  wrote:
>> There are several remaining issues in the report. So I have some questions:
>> 
>> - Is class QPlatformScreen private and all related changes should be removed
>> from the report?
>> (http://abi-laboratory.pro/tracker/compat_report/qt/5.5.1/5.6.0-beta/8f965/
>> abi_compat_report.html) 
>
> Yes, that's a private class (QPlatform* is QPA, like QWindowSystem*).

It is a public private class. I'm not sure it is fully correct to hide
it. I'm also not sure it is fully correct to keep it.

Many parts of the QPA bits are unfortunately widely used. We should
really work towards making it public ...

/Sune

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

Re: [Development] A simple analysis of apps using qtbase's private headers

[Sune Vuorela]

On 2016-02-02, Liang Qi  wrote:
> Above three are not applications, they must be input context plugin of Qt,
> just like ibus in
> https://github.com/qtproject/qtbase/tree/5.5/src/plugins/platforminputconte=
> xts/ibus
> . Normally every input method software could/should have one of this kind
> of plugin for Qt 5, so there is no question when they use private headers.

There is two ways to fix the usage of private headers in external
things.

1) is to stop using them
2) is to promote more private api to public api.

I do think that one should consider it for the bits needed to make input
methods.

Really. Public private api is bad. It should really not exist. It harms
our "We promise source and binary compatibility" promises, because it is
full of 'except ...' .

We should head towards not have any public private api.

/Sune

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

Re: [Development] Fwd: A simple analysis of apps using qtbase's private headers

[Sune Vuorela]

On 2016-01-22, Lisandro Damián Nicanor Pérez Meyer  wrote:
> On Friday 22 January 2016 18:09:55 NIkolai Marchenko wrote:
>> Speaking of workarounds :
>> I have to use this ugly hack that depends on otherwise inaccessible c=
> ode to
>> update QPrintPreviewDialog
>>=20
>> //dia is a QPrintPreviewDialog
>> QPrintPreviewWidget* w =3D dia->findChild();
>> QMetaObject::invokeMethod(w, "updatePreview", Qt::QueuedConnection);
>>=20
>> can you please add "updatePreview" to the dialog's interface?
>
> Is there a bug for that?

Or even better. A gerrit submission.

/Sune

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

Re: [Development] Qt 5.6.0 header diff: QtCore.diff

[Sune Vuorela]

On 2015-09-17, Frederik Gladhorn  wrote:
> --- a/src/corelib/tools/qbytearray.h
> +++ b/src/corelib/tools/qbytearray.h
> @@ -43,6 +43,7 @@
>  #include 
>=20
>  #include 
> +#include 
>=20
>  #ifdef truncate
>  #error qbytearray.h must be included before any header file that defin=
> es truncate
> @@ -162,9 +163,6 @@ private:
>  typedef QTypedArrayData Data;
>=20
>  public:
> -// undocumented:
> -static const quint64 MaxSize =3D (1 << 30) - sizeof(Data);
> -
>  enum Base64Option {
>  Base64Encoding =3D 0,
>  Base64UrlEncoding =3D 1,
> @@ -338,16 +336,16 @@ public:

Even though it is marked as undocumented, it does look slightly fishy to
me.

/Sune

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

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

[Sune Vuorela]

On 2015-07-17, Takao Fujiwara tfuji...@redhat.com wrote:
 Right. ibus-qt already has the ibus module for qt4 so this request is for qt5.
 I'd think it's easy to move libibusplatforminputcontextplugin.so from qtbase 
 to ibus-qt.

Part of me would like to have as many things that uses QPA headers to
stay inside Qt because unstable api's.

And then I'm not sure if there might be licensing issues for various
users with moving it from lgpl Qt to GPL ibus-qt, or if enough of ibus
is GPL that you can't take advantage of the l in lgpl anyways.

/Sune

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

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Sune Vuorela]

On 2015-07-12, Andre Somers an...@familiesomers.nl wrote:
 become easier to make the transition in user code? Then, if Qt itself 
 changes its API in Qt 6 to use QVector instead of QList, the users' code 
 will just work :-)

In Qt6, QList can be fixed. The issue is what to do until then.

/Sune

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

Re: [Development] The dark side of QtMultimedia - strikes back

[Sune Vuorela]

On 2015-07-05, Massimo Callegari massimocalleg...@yahoo.it wrote:
 Update #2 (sorry for spamming)

 I patched qgstreamervideowindow.cpp and qgstreamervideowidget.cpp to support 
 the linuxfb platform.
 It kinda works !!

 Screenshot here: http://pasteboard.co/1JlYRT9l.jpg

 Videos can be played hardware decoded with audio and video until the end.
 It's definitely using the OMX plugin.

Nice. Did you submit your work to gerrit ?

/Sune

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

Re: [Development] Qt LTS C++11 plans

[Sune Vuorela]

On 2015-06-26, Olivier Goffart oliv...@woboq.com wrote:
 Can we have function that takes or return std::function, std::tuple, 
 std::unique_ptr, std::vector?

While I can see the advantage of std::function, I'm not sure why we
would use the remaining ones in API ?

Thiago already mentioned that he didn't like std::vector.
I think we mostly avoid QPair in api's (because it is generally not very
documenting in API). I don't see why std::tuple is any different.

/Sune

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

Re: [Development] Item View Maintainer

[Sune Vuorela]

On 2015-03-01, Samuel Gaist samuel.ga...@edeltech.ch wrote:
 Hi,

 Since Stephen Kelly ended his work at KDAB, he also got out of gerrit/jira so 
 it seems that there's no official maintainer for the Item View module, unless 
 he's there with a new account I missed ? 

I spotted him some time ago in gerrit as 'ske'

/Sune

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

Re: [Development] license question, bds 4 clause license text in qtbase\src\corelib\tools\qdatetime.cpp qt5.4.1 found

[Sune Vuorela]

On 2015-02-28, Gunnar Roth gunnar.r...@gmx.de wrote:

  UC writes  BSD Unix files not about general source code.
I don't think that UC has published anything else but BSD Unix.

 And why does gnu,org not update their website,but till insists on  
 incompatibility with the GNU GPL?

In the general case, the incompatibility still exists. The special case
where it doesn't is if the organization is University of California.

/Sune

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

Re: [Development] qt-4.8.x gcc5 version/detection issues

[Sune Vuorela]

On 2015-02-16, Rex Dieter rdie...@math.unl.edu wrote:
 * QT_BUILD_KEY handling

 Similar to webkit above, the configure bits about QT_BUILD_KEY only handles 
 up to gcc-4.x.

 For fedora 22, our gcc5 builds are done in a way that is (supposedly) ABI 
 compatible to gcc4, so I'm currently using:
 http://pkgs.fedoraproject.org/cgit/qt.git/tree/qt-gcc5_compat_qt_build_key.patch
 to ensure QT_BUILD_KEY matches (ie, it includes the same g++-4 string as 
 before).

 As far as upstream is concerned, I assume you'd prefer the default here to 
 be g++-5 ?

The build key is used for ABI checks, so I think the 4 should still be
used. e.g. you can build a qt plugin with g++-5 and it should still be
loadable by the qt you buil with g++-4.x

So I think your current patch is right.

/Sune

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

Re: [Development] qt-4.8.x gcc5 version/detection issues

[Sune Vuorela]

On 2015-02-16, Rex Dieter rdie...@math.unl.edu wrote:
From my reading of
 http://developerblog.redhat.com/2015/02/10/gcc-5-in-fedora/

 It may depend on the value of _GLIBCXX_USE_CXX11_ABI macro, but I admittedly 
 don't yet fully grasp the implications of it being set either way.

Yes. it does depend on lots of things, but in general[tm], a qt plugin
should be usable in a combination.
And from my knowledge of RPM and dependency calculations, you already
have sufficient data there to deal with whatever happening, and doesn't
need the extra bits from BUILD_KEY. they are just going to get in your
way.
(if you change the build key, you need to have your qt4 core library
package conflict with all the existing plugins ...)

/Sune

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

[Development] Reproducible Qt ; the purpose of QLibraryInfo::buildDate

[Sune Vuorela]

Hi

After a couple of patches [1], most submitted to gerrit, my current qtbase dev
build on linux is bitwise reproducible. This is the first step to let
end users check that the binaries they recieve actually matches the
sources they recieve.

The first simple steps is 1) ensure __DATE__, __TIME__ and __TIMESTAMP__
aren't used. (-Werror=date-time can help with that)
2) do some builds and compare the results. 
3) fix fix fix. 

I have one local patch pending[2] that I'm unsure what to do with. As
mentioned in subject, QLibraryInfo::buildDate().  First of all, I'm a
bit puzzled by the purpose of it. THe documentation is quite unclear. It
might give build time, configure time or installation time:

Returns the installation date for this build of Qt. The install date
will usually be the last time that Qt sources were configured.

The easiest would be to just fix it to some chosen date and mark it as
deprecated. It doesn't seem to be really used in 'real life code' on the
internet, and it has unclear documentation, and I can't really imagine
what it actually should be used for.

So, can someone enlighten me on the purpose of this function?

Thanks in advance

/Sune

[1]
https://codereview.qt-project.org/#/c/105210/
https://codereview.qt-project.org/#/c/105209/
https://codereview.qt-project.org/#/c/105196/

[2]
-static const char qt_configure_installation  [12+11]=
qt_instdate=`date +%Y-%m-%d`;
+static const char qt_configure_installation  [12+11]=
qt_instdate=1982-02-15; [3]

[3]
any date seems to be usable

[4]
first patch for creator:
https://codereview.qt-project.org/#/c/105211/

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

Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Sune Vuorela]

On 2015-01-19, Oswald Buddenhagen oswald.buddenha...@theqtcompany.com wrote:
 your problem is a self-made one: the attempt to co-install major
 versions of everything. this is a linux distro specific problem, and
 demanding x-platform upstreams to accept trade-offs to adjust to it is
 *unreasonable*.

I do wonder about one thing here. Are you suggesting that linux
distributions doesn't ship Qt5 until everything is ready to use it ?

/Sune

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

Re: [Development] changing Q_GADGET

[Sune Vuorela]

On 2014-11-28, Simon Hausmann simon.hausm...@theqtcompany.com wrote:
 I feel that Q_GADGET has its primary use with structures and the default 
 access level for those is public. I find it awkward that you currently have 
 to 
 write:

I have a lot of code in the wild using classes and Q_GADGET. 

Having Q_GADGET not change stuff at the end is likely ok, if Q_GADGET
doesn't change accesslevel in the beginning.

But doesn't Q_GADGET start with changing accesslevel to public?

The only safe way is to then switch to private.

class MyClass 
{
Q_GADGET
class MyPrivate;
int m_myCounter;
public: 
MyClass);
}

 The proposed change would have two effects:

 1) It makes any existing code that _relies_ on Q_GADGET turning to private 
 suddenly expose members in structures.

 2) On paper it breaks binary compatibility with MSVC, in the unlikely event 
 that somebody 
 a) produces a DLL and cares about binary compatibility
 b) exposes bare structures
 c) relies on Q_GADGET turning access permission levels to private

3) Making accesslevel public for private class members.

/Sune

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

Re: [Development] Contribution proposal: Dispatcher class

[Sune Vuorela]

On 2014-09-24, Yam Marcovic ymar...@gmail.com wrote:
 However, I will say I don't want to force people to give their sources away
 if they use it.

 So a license along the lines of 'this license is here for formal purposes;
 but feel free to do anything you want with this,' is good enough as far as
 I'm concerned.

I think the formal way of expressing this is either the MIT, 2 or
3-clause BSD licenses. 

http://opensource.org/licenses/BSD-3-Clause
http://opensource.org/licenses/BSD-2-Clause
http://opensource.org/licenses/mit-license.html

/Sune

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

Re: [Development] QtMultimedia and Musepack

[Sune Vuorela]

On 2014-08-26, Allan Sandfeld Jensen k...@carewolf.com wrote:
 Well. That would the safe way, and we should keep that in mind for Qt6, but I 
 believe with symbol versioning it can be done without breaking ABI, assuming 
 it works as advertised. The libraries would export all symbols as both their 
 normal form and with @Qt_5 or @Qt_4 added. The libraries would at link time 
 remember which the version suffix they linked against, and prefer that symbol 
 at runtime linking. This means the duplicate non versioned symbol shouldn't 
 cause any issues.
 I haven't tried, and some information I found about it, seems to suggest it 
 can run into bugs in ld.so.

I think you can even add the symbols (and remove the unversioned ones)
without other than ld.so yelling a bit at you occasionally.

if your thing needs a versioned symbol, then the version must match.
If your thing doesn't need a versioned symbol, then any symbol,
versioned or not, can be used.

(I'm only talking about glibc's ld.so)

/Sune

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

Re: [Development] Multimedia support.

[Sune Vuorela]

On 2014-08-20, Thorvaldur Jochumsson jochums...@gmail.com wrote:
 Hi I am currently designing multimedia support for my application. I am
 wondering which approach to take. Should I make use of the phonon library
 or make use of the multimedia support provided in the Qt multimedia
 library? We are currently making use of Qt 4.8, where phonon is supported.
 However, I am not sure whether it is the official plan (if there is an
 official plan) to support phonon in future releases. I don=E2=80=99t want t=
 o be in
 the situation in half a year that I cannot make use of the newest Qt
 release since they no longer support phonon. Anyone who can give me
 feedback on this?

Phonon is fully supported by the KDE project, where Phonon originated,
and I recommend you to get that version of phonon. 

/Sune

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

Re: [Development] Private Qt helper libraries?

[Sune Vuorela]

On 2014-07-03, Milian Wolff milian.wo...@kdab.com wrote:
 I imagine, it could work by create just a normal library but not install and 
 public headers, only private ones. That should be OK then, or what do you 
 think?

We have too many private headers already. We should work on getting rid
of them, not to create new ways to increase our collective headaches.

So, a proper documented and stable api and abi would be much preferred.

/Sune

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

Re: [Development] Proposal: All Qt modules must use the same version number

[Sune Vuorela]

On 2014-06-30, Olivier Goffart oliv...@woboq.com wrote:
 Totally off topic: I think using private header should be tried to be 
 avoided. 
 In the past, we used private header inside Qt because Qt was not split that 
 much.  But one of the goal of modularisation was to allow independent release 
 of different component of Qt.  The problem is that we could not get rid of 
 the 
 private header dependencies at the time (too much work).
 But still now, every module, even new, are using the private headers. Nothing 
 is done to try to prevent it.

 I think there should be some kind of long term goal to avoid using private 
 headers. 

 We need to find a solution so that one need not to inherit from 
 QObjectPrivate. (There is already QObject::setUserData, but it could be done 
 better i guess)

 We need also to identify private APIs that could be polished and made public.
 For some modules such as QtQuick this is probably too hard.
 But for new modules such as WebEngine or such, it may be possible to avoid 
 dependency on private API.

*applause*

/Sune

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

Re: [Development] Proposal: All Qt modules must use the same version number

[Sune Vuorela]

On 2014-06-30, Olivier Goffart oliv...@woboq.com wrote:
 We need also to identify private APIs that could be polished and made public.

The first step here is, from your friendly packagers POV, the QPA
API's.

One thing is that we need to be very careful with combining the
components released by the Qt project, and that tooling
tools (from creator to gammaray) needs internal uses.

A completely different thing is the QPA bits. Having them real public
api would be great.

/Sune

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

Re: [Development] Adding support for version number comparisons

[Sune Vuorela]

On 2014-05-09, Keith Gardner kreios4...@gmail.com wrote:
2. What semantics should be used for version comparisons?  Numerical
segments are more clearly defined but when introducing a non-null suffix,
many different methods are being proposed.
   3. Are there any other versioning semantics that should be supported?

Please look at the version comparison rules that for example dpkg uses.
Especially tilde. [1]

And special strings (alpha, rc, ..) should not be treated special.

/Sune
[1]
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

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

Re: [Development] Adding support for version number comparisons

[Sune Vuorela]

On 2014-05-10, Thiago Macieira thiago.macie...@intel.com wrote:
 How do you make 5.3.0-rc1 compare less than 5.3.0?

we call them 5.3.0~rc1.

/Sune

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

Re: [Development] Qt 5.3 header diff

[Sune Vuorela]

On 2014-04-23, Andrey Ponomarenko aponomare...@rosalab.ru wrote:
 I've created the ABI compatibility report between 5.2.1 and 5.3.0-beta 
 versions: 
 http://upstream-tracker.org/compat_reports/qt/5.2.1_to_5.3.0-beta/abi_compat_report.html

 Hope it may be helpful to analyse changes in headers.

that abi tool is btw amazing.

Is it the constant changes in bluetooth and pagesize and the changes to 
qopenglfunctionsprivate that gives the verdict:

| Incompatible

/Sune

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

Re: [Development] Qt 5.3 header diff: QtLocation

[Sune Vuorela]

On 2014-04-22, Thiago Macieira thiago.macie...@intel.com wrote:
 -QGeoCodingManagerEngine(const QMapQString, QVariant parameters, 
 QObject *parent = 0);
 +QGeoCodingManagerEngine(const QVariantMap parameters, QObject *parent = 
 0);

Given it is just changes to typedefs, it should be okay. There are quite
many of those across this diff.

 diff --git a/src/location/places/qplacecontentrequest.h 
 b/src/location/places/qplacecontentrequest.h
 index b535a13..164c4df 100644
 --- a/src/location/places/qplacecontentrequest.h
 +++ b/src/location/places/qplacecontentrequest.h
 @@ -65,8 +65,12 @@ public:
  QPlaceContent::Type contentType() const;
  void setContentType(QPlaceContent::Type type);
  
 -int offset() const;
 -void setOffset(int offset);

This looks wrong


 --- a/src/location/places/qplacemanager.h
 +++ b/src/location/places/qplacemanager.h
 @@ -76,7 +76,7 @@ public:
  
  QPlaceDetailsReply *getPlaceDetails(const QString placeId) const;
  
 -QPlaceContentReply *getPlaceContent(const QString placeId, const 
 QPlaceContentRequest request) const;
 +QPlaceContentReply *getPlaceContent(const QPlaceContentRequest request) 
 const;
  
  QPlaceSearchReply *search(const QPlaceSearchRequest query) const;
  

This also looks wrong


 diff --git a/src/location/places/qplacemanagerengine.h 
 b/src/location/places/qplacemanagerengine.h
 index ee01963..0eefa7c 100644
 --- a/src/location/places/qplacemanagerengine.h
 +++ b/src/location/places/qplacemanagerengine.h
 @@ -66,8 +66,7 @@ public:
  
  virtual QPlaceDetailsReply *getPlaceDetails(const QString placeId);
  
 -virtual QPlaceContentReply *getPlaceContent(const QString placeId,
 -const QPlaceContentRequest 
 request);
 +virtual QPlaceContentReply *getPlaceContent(const QPlaceContentRequest 
 request);
  
  virtual QPlaceSearchReply *search(const QPlaceSearchRequest request);
  

And this one as well

 diff --git a/src/location/places/qplacesearchrequest.h 
 b/src/location/places/qplacesearchrequest.h
 index 65ca3fe..34a6a1d 100644
 --- a/src/location/places/qplacesearchrequest.h
 +++ b/src/location/places/qplacesearchrequest.h
 @@ -94,8 +94,6 @@ public:
  RelevanceHint relevanceHint() const;
  void setRelevanceHint(RelevanceHint hint);
  
 -int offset() const;
 -void setOffset(int offset);
  int limit() const;
  void setLimit(int limit);

This one too.

/Sune

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

Re: [Development] Qt 5.3 header diff: QtNetwork

[Sune Vuorela]

On 2014-04-22, Thiago Macieira thiago.macie...@intel.com wrote:
 --- a/src/network/ssl/qsslconfiguration.h
 +++ b/src/network/ssl/qsslconfiguration.h
 @@ -131,6 +132,21 @@ public:
 +static const char NextProtocolSpdy3_0[];
 +static const char NextProtocolHttp1_1[];

These static const char[] kind of triggers my 'something looks wrong and
not like Qt is supposed to look like'-feeling. I haven't investigated
what they are for or how they are set and used. It just looks wrong to
me.

/Sune

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

Re: [Development] Qt 5.3 header diff: QtSerialPort

[Sune Vuorela]

On 2014-04-22, Thiago Macieira thiago.macie...@intel.com wrote:
 --- a/src/serialport/qserialport.h
 +++ b/src/serialport/qserialport.h
 @@ -64,11 +64,11 @@ class Q_SERIALPORT_EXPORT QSerialPort : public QIODevice
  Q_PROPERTY(FlowControl flowControl READ flowControl WRITE setFlowControl 
 NOTIFY flowControlChanged)
  #if QT_DEPRECATED_SINCE(5, 2)
  Q_PROPERTY(DataErrorPolicy dataErrorPolicy READ dataErrorPolicy WRITE 
 setDataErrorPolicy NOTIFY dataErrorPolicyChanged)
 +Q_PROPERTY(bool settingsRestoredOnClose READ settingsRestoredOnClose 
 WRITE setSettingsRestoredOnClose NOTIFY settingsRestoredOnCloseChanged)

Isn't it 5.3 we are releasing?

  #endif
  Q_PROPERTY(bool dataTerminalReady READ isDataTerminalReady WRITE 
 setDataTerminalReady NOTIFY dataTerminalReadyChanged)
  Q_PROPERTY(bool requestToSend READ isRequestToSend WRITE 
 setRequestToSend NOTIFY requestToSendChanged)
  Q_PROPERTY(SerialPortError error READ error RESET clearError NOTIFY 
 error)
 -Q_PROPERTY(bool settingsRestoredOnClose READ settingsRestoredOnClose 
 WRITE setSettingsRestoredOnClose NOTIFY settingsRestoredOnCloseChanged)
  
  Q_ENUMS(BaudRate DataBits Parity StopBits FlowControl DataErrorPolicy 
 SerialPortError)
  Q_FLAGS(Directions PinoutSignals)
 @@ -131,16 +131,6 @@ public:
  UnknownFlowControl = -1
  };
  

 +#if QT_DEPRECATED_SINCE(5, 2)
same.
  enum DataErrorPolicy {
  SkipPolicy,
  PassZeroPolicy,
 @@ -196,9 +198,6 @@ public:
  bool open(OpenMode mode) Q_DECL_OVERRIDE;
  void close() Q_DECL_OVERRIDE;
  
 -void setSettingsRestoredOnClose(bool restore);
 -bool settingsRestoredOnClose() const;
 -
  bool setBaudRate(qint32 baudRate, Directions directions = AllDirections);
  qint32 baudRate(Directions directions = AllDirections) const;
  
 @@ -229,6 +228,8 @@ public:
  #if QT_DEPRECATED_SINCE(5, 2)
and here again
  QT_DEPRECATED bool setDataErrorPolicy(DataErrorPolicy policy = 
 IgnorePolicy);
  QT_DEPRECATED DataErrorPolicy dataErrorPolicy() const;
 +void setSettingsRestoredOnClose(bool restore);
 +bool settingsRestoredOnClose() const;
  #endif
  
  SerialPortError error() const;

/Sune

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

Re: [Development] Qt 5.3 header diff: QtWidgets

[Sune Vuorela]

On 2014-04-22, Thiago Macieira thiago.macie...@intel.com wrote:
 --- a/src/widgets/widgets/qlcdnumber.h
 +++ b/src/widgets/widgets/qlcdnumber.h
 @@ -43,7 +43,6 @@
  #define QLCDNUMBER_H
  
  #include QtWidgets/qframe.h
 -#include QtCore/qbitarray.h
  
  QT_BEGIN_NAMESPACE
  

I guess this is theoretically a SiC change, but one that could also be
ignored.

/Sune

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

Re: [Development] How to write a ChangeLog entry

[Sune Vuorela]

On 2014-01-20, Thiago Macieira thiago.macie...@intel.com wrote:
 Windows
 ---
[QTBUG-35500] Fix printing on Windows. QPrinter now reports proper page
sizes for system printers.


(I would like another sentence about the actual implications. For me, it
was that my custom printing code went from 'completely broken' to
'actually working')

/Sune

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

Re: [Development] How to write a ChangeLog entry

[Sune Vuorela]

On 2014-01-20, Thiago Macieira thiago.macie...@intel.com wrote:
 On segunda-feira, 20 de janeiro de 2014 21:30:37, Sune Vuorela wrote:
 On 2014-01-20, Thiago Macieira thiago.macie...@intel.com wrote:
  Windows
  ---
 
 [QTBUG-35500] Fix printing on Windows. QPrinter now reports proper page
 sizes for system printers.

 Sounds like I should merge with the OS X fix:

  - [QTBUG-34700] QtPrintSupport will now respect the custom paper size
settings when printing.

It is kind of the opposite than that one.  But it could be grouped into
a PrintSUpport group rather than in platform groups.

I don't feel that strongly for it, but I just spent half a day today
trying to figure out what was up and down and ended up finding this fix.

/Sune

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

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Sune Vuorela]

On 2014-01-13, David Faure david.fa...@kdab.com wrote:
 Mounting can still be done with `mount`, no?

Only in rare cases. Normally on linux from a user app you would call out
to udisks, who would connect to polkit and have polkit maybe query you
and other magic.

 Notifications mean listening to dbus signals though, indeed. Tricky.
 Maybe by using libdbus directly, but this contradicts the long term plan of 
 not using libdbus in QtDBus (AFAIK).

In order to not do it half-assed and in a way that only works for your
app run as root, you do need dbus on linux. I don't know how it is done
on windows and mac.

Though mounting/unmounting drives is in general not something I would
expect an application to do, but rather something that happens in the
workspace, be it Windows, Gnome or OSX.

For the specific case of mounting stuff from the file dialog, maybe it
should be even easier to call out to a system file dialog, like the
QFileDialog::getSomething function does. If that can be done somehow,
then I only think we have the 'dedicated system information / system
manipulation apps' left, and I'm not sure that I think that it is a
usecase that Qt should try to solve in qtbase, but rather keep it around
as an extra addon.

/Sune

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

Re: [Development] The Software shall be used for Good, not Evil statement in Qt sources

[Sune Vuorela]

On 2013-12-18, Ziller Eike eike.zil...@digia.com wrote:

 On Dec 18, 2013, at 5:35 PM, Lisandro Damián Nicanor Pérez Meyer 
 perezme...@gmail.com wrote:

 Hi! I would like to now if it's acceptable for the project to have 3rd party 
 code with the following statement in 3rd party sources:
 
 The Software shall be used for Good, not Evil”

 Does it come with definitions of “good” and “evil” ?

Of course not. See also: Douglas Crockford.

Most linux distributions, as well as google code hosting and others are
treating it as a non-free license.

Oh. and Crockford thinks that eval() in javascript code is evil.

/Sune

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

Re: [Development] Removing libudev dependency from binary packages?

[Sune Vuorela]

On 2013-10-21, Thiago Macieira thiago.macie...@intel.com wrote:
 Anyway, my suggestion thus:
  - QtSerialPort: statically link to libudev

btw, does anyone know how close the libudev version should match the
udev-daemon version?  are there any library/daemon protocol stability
guarantees? 
What happens if there is a mismatch?

/Sune

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

Re: [Development] Removing libudev dependency from binary packages?

[Sune Vuorela]

On 2013-10-21, Thiago Macieira thiago.macie...@intel.com wrote:
 But what distributions are those that don't have libudev.so.0?

Most modern ones I think.


 http://git.kernel.org/cgit/linux/hotplug/udev.git/tree/Makefile.am

Note that udev in general is built from systemd source tree, even for
distributions that don't default to systemd.

 LIBUDEV_CURRENT=13
 LIBUDEV_REVISION=2
 LIBUDEV_AGE=13

 That's libtool speak for 0.13.2. The soname has not changed.

http://cgit.freedesktop.org/systemd/systemd/tree/Makefile.am
LIBUDEV_CURRENT=5
LIBUDEV_REVISION=0
LIBUDEV_AGE=4

that's like .1.4.0 or soething in libtool speak (which I don't do
fluently. it could also be .1.5.0)

/Sune


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

Re: [Development] A QtCore class for event-driven jobs

[Sune Vuorela]

On 2013-09-09, Giuseppe D'Angelo dange...@gmail.com wrote:
 Indeed, but how about starting with an addon and then moving the
 classes inside QtCore? We can freely break API/ABI in addons -- when
 things get stabilized, we start including them in QTCore/QtNetwork...

I'm not sure what a addon containing 1 small class doing a multiple-year
long concept is going to be any good for. 

The api has been stabilized and well tested since like forever.

Let's get a QAbstractJob heavily inspired by KJob in now.

A nice side effect of getting it in now is that the myriad of nice
frameworks KDE is preparing for ship could be built on QAbstractJob and
KDE could skip shipping KJob and move everything over to QAbstractJob
now and not after we in KDE has made our first release where we promise
to keep ABI and API stability.

/Sune

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

Re: [Development] Cleaner code base patches

[Sune Vuorela]

On 2013-01-28, Knoll Lars lars.kn...@digia.com wrote:
 1) always with -developer-build
 2) on by default on -developer-build, but the CI disables it
 3) completely optional, CI enables it
 4) completely optional, not enabled by the CI

 I'd favor (2) for now, and move over to (1) once we gained a little 
 experience with it for the compilation of the whole module.
 The header compilation test should probably move to (1) immediately.

Can something in the 'middle' be done where CI somehow yells at 
people who introduces new warnings?

/Sune

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

Re: [Development] Cleaner code base patches

[Sune Vuorela]

On 2013-01-28, Thiago Macieira thiago.macie...@intel.com wrote:
 I'd rather skip that step and simply go to -Werror. Lars proposed that we 
 experiment with it a little and see how far it goes before turning it on.

 The good thing about -Werror is that the failure comes fast.

The bad thing about -Werror is that it triggers different issues with
different optimization levels, different compilers and different
compiler versions.

/Sune

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

Re: [Development] QtMultimedia BIC / header cleanliness issue

[Sune Vuorela]

On 2013-01-22, Thiago Macieira thiago.macie...@intel.com wrote:
 Sune, especially for you: will you try and patch Qt to change the sonam=
 e if we=20
 don't do it?

Sorry for answering a bit late.

Given that we haven't yet formally published Qt5, no. 

if we had, then it would be a definately maybe depending on a insane
amount of factors.

/Sune

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

Re: [Development] RFC: What constitutes a non-destabilising bug-fix?

[Sune Vuorela]

On 2012-12-09, Sune Vuorela nos...@vuorela.dk wrote:
 On 2012-12-09, Marc Mutz marc.m...@kdab.com wrote:
 3.  new features and bug-fixes that require new strings or BiC changes should
be submitted to 'dev' directly.

 binary incompatible changes should not be submitted anywhere except for
 Qt6.

I've asked to clarify the above.

There is a special thing from now until 5.0 is out where under certain
circumstances, BiC changes can happen, and should under those certain
circumstances happen in all branches targetting 5.y.z. Until 5.0 is out.
Find those certain circumstances and a howto in a relevant mail from the
chief maintainer.

Once 5.0 is out, my above sentence should apply.

/Sune

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

Re: [Development] Qt5/Qt Quick 2 with C#

[Sune Vuorela]

On 2012-11-28, Labs, Torsten torsten.l...@siemens.com wrote:
 Hello,

 does anybody know something about a possiblity to use C# for programming Qt=
 5 and Qt Quick?
 I know this sounds funny :-)

I would expect the people behind Qyoto (Qt4 mono bindings) will move on
to Qt 5 sometime in the future.

iirc Qyoto (and the tools smokegen and assemblygen) lives on git.kde.org

/Sune

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

Re: [Development] Is QtConcurrent's code generator still in use?

[Sune Vuorela]

On 2012-11-14, Christian Kandeler christian.kande...@digia.com wrote:
 On 11/14/2012 12:17 PM, Sorvig Morten wrote:
 QtConcurrent is done. The implementation is not good enough to be used as a 
 base for further development.

 Can you be a bit more specific? What are the general problems and why 
 can't they be easily solved?

I think it is quite limited and hard to use. I recently tried and after
giving up on that, I switched a project to the ThreadWeaver library by
KDE which not only made my code simpler, it also made it much easier to
understand and having threading cote separated out.

The ThreadWeaver library is a quite simple, but yet powerful thing built
on qtcore. 

/Sune

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

Re: [Development] Pending decisions on co-installation

[Sune Vuorela]

On 2012-10-30, Thiago Macieira thiago.macie...@intel.com wrote:
 1) QML environment variables
 The variable for import paths has been versioned from QML_IMPORT_PATH to 
 QML2_IMPORT_PATH. But I have not changed any of the other variables. We need 
 a 
 decision from the team familiar with the engines and the meanings of those 
 variables to know which ones should be versioned too.

 They need to be versioned if having a value set in it applies to one QML 
 engine but has ill-effects for the other.

isn't 'not versioning this' a recipe for disaster for both end users of
applications and for developers of applications if we don't do something


 2) QML tool names
 Kai raised the point that many of the QML 2 tools work for QML 1 too and 
 maybe 
 even for Qt 4's QML 1. We need confirmation on that as well as the 
 willingness 
 to keep them that way for one or two years at least. For the tools that work 
 on both QML engines, we can drop the version number from their names.

ack.

 3) library versioning (i.e., adding 5 to the library name)
 I'd like to see a decision here, one way or the other. I've posted my 
 arguments in favour more than once and I know there are people who disagree. 
 So let's hear from them why they disagree so we can see if there's a 
 consensus[*]. I'll similarly post the arguments in favour and I'd appreciate 
 if other people who agree did the same.

I would really like to see a '5' added. that way, people can use distro
packages and develop for qt4 on the same installation as they develop
for qt5. And this is very much going to be a issue.
the /usr/lib/libQtCore.so symlink can only point to one place at a time.

Alternatively, distributions will do something like that, and maybe even
do it differently and if we ar ereal lucky even break the much-valued
binary compatibility between installations - assuming that one distro
does libQt5Core, another does libQtCore5 and some just does a libQtCore.
The only way to prevent this is that we as Qt project (as oppsode to we
as packagers) actually does it. Having distro-qt's binary compatible
with upstream qt and other qt's (modulo fuckups) is a advantage.

 4) new installation paths (besides the bin directory)
 The latest patch I've provided creates a grouping of all arch-dependent files 
 in ARCHDATADIR, with arch-independent files in DATADIR. That change, by 
 itself, 
 is innocuous since it doesn't produce any difference in installation.

 The decision we need is on the defaults for those two directories. My 
 proposal 
 is to have ARCHDATADIR=LIBDIR/qt5 and DATADIR=PREFIX/share/qt5 on Unix build 
 that require make install *only*. Again, there are arguments for and against, 
 so let's hear them.

For me, ensuring a 100% correct split between arch-dep and arch-indep
files isn't the most important issue, given that we, at a bit of a disk
space cost can put files where we are in doubt

 5) executable split between end-user applications and indirect tooling
 The most controversial proposal so far is to split the binaries into two 
 groups: one that gets installed to PREFIX/bin, containing the executables for 
 applications run directly by the user and which retain backwards 
 compatibility 
 of purpose, and one that gets installed to ARCHDATADIR/bin that contains the 
 tools that users generally do not run directly and which are specific to a 
 particular build of Qt. Please note that, in the current implementation, like 
 in #4 above, most people on this list will not see a change, as it applies to 
 Unix builds that require make install *only*.

 This proposal has met with vehement opposition and I'd like to hear why.

This is something that will happen to be done. and for the sake of
documentation and support, please let it be consistant not only across
distributions, but also across platforms so that documentations don't
have to be 
if mac | upstream-provided-linux-builds {
  run qmake
} else if windows {
  run qmake.exe
} else if debian {
  run qmake-qt5
} elese if fedora {
  run qmake5
}

Yes. we need to do something. and if the 'something' is to ask Lars as 
chief maintainer to override Ossi, then we must do that.

/Sune

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

Re: [Development] Pending decisions on co-installation

[Sune Vuorela]

On 2012-10-31, Poenitz Andre andre.poen...@digia.com wrote:
 This is not about overriding someone. This is about ranking the user 
 experience of the majority of users higher than the convenience of a 
 handful of Linux distribution packagers - half which will do their own 
 renaming anyway, no matter what the official solution will look like.

I really think that if we (qt project) has to rely on us (packagers) to
do and get the renaming right then we (qt project) has failed.

And I still think that the majority of our (qt project *and*
distribution packagers) use Qt from distribution packages.

/Sune

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

Re: [Development] Summary of renaming changes

[Sune Vuorela]

On 2012-10-19, Alberto Mardegan ma...@users.sourceforge.net wrote:
 3) Provide a script to switch, per user and maybe even per $PWD, what
 version of Qt /usr/bin/qmake should generate the makefiles for.

I have, as a distributor, frequently gotten 'hate' in #qt for providing
switchable qmakes.


And from a 'user support' PoV, having to write depending on what you
have set as your default you can maybe write qmake, maybe you need to
oither switch the default to qt5 or alternatively write qmake5 to 
build things is a much longer sentence than 

write qmake5 to build things.

The advantage of doing it upstream, rather than having me to do it,
kevin to do it, will to do it, jonathan to do it, ... is that 
 - the implementation is the same
 - the result is the same
 - you do not have to consider what distribution teh user is on when
   trying to help in #qt, on interest@ or in forums. just write 'use
   qmake5

/Sune

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

Re: [Development] Summary of renaming changes

[Sune Vuorela]

On 2012-10-19, Poenitz Andre andre.poen...@digia.com wrote:
 User support could then be:

   write qmake5 to build Qt 5 things

no. it would be if you compiled Qt yourself or if you downloaded the 
built editions from digia, write qmake to build things. if you gotten 
from your linux distribution write probably
qmake5, but maybe the distro chose some other naming scheme so it could
also be qmake-qt5 or /usr/lib/ia64-linux-gnu/qt5/bin/qmake

/Sune


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

Re: [Development] Summary of renaming changes

[Sune Vuorela]

On 2012-10-19, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote:
 Really. I really want, both as a Qt contributor and a Qt packager to
 ship a pristine Qt. Please help me make it happen.

 Demanding to be relieved from that burden is one thing. Demanding to
 use an approach that will break thousands of other projects is a
 different one. It is unreasonable.

I am a bit saddened by this paragraph. I'm not demanding anything. I'm
*explaining* my situation *hoping* that we can do something.

I could also be *begging* if *you* would prefer that, but I wouldn't
expet that.

I do know that I can't *demand* anything.

I do know, though, that the only way Qt can ensure the same is done on
all distributions is to solve it in Qt.

I will try hard, if the distributions need to solve it, to ensure that
most distros implement it the same way. but I also can't demand anything
there. And I have already heard people saying that qmake-qt5 is a much
better name.

Oh. btw, whattabout a solution with all tools having a 5 suffixed in
/usr/bin and then creating a symlink farm somewhere with unversioned
tools for people who has special needs?

/Sune


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

Re: [Development] Summary of renaming changes

[Sune Vuorela]

On 2012-10-18, Giuseppe D'Angelo dange...@gmail.com wrote:
 The following are user applications and they have not and will not be 
 renamed:
 qdbus
 qdbusviewer
 assistant
 designer
 linguist
 creator
 pixeltool

 I would remove creator from this list as it's a different product

I would also remove designer from this list. Designer loads plugins and
you need the plugins matching the thing you are desiging for.

But beside that, I really applaud this effort.

/Sune
 - one of those pesky distributors

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