Re: [Development] Using '#pragma once' instead of include guards?

[Alejandro Exojo]

On Mon, Oct 10, 2022, at 12:11 PM, Hasselmann Mathias wrote:
> I am surprised by the question: "It's non-standard and it's behavior is 
> undefined" actually should be enough to avoid such feature.

I suggest that you don't look at the implementation of things like Q_OFFSETOF, 
then. ;-)

// This macro can be used to calculate member offsets for types with a non 
standard layout.
// It uses the fact that offsetof() is allowed to support those types since 
C++17 as an optional
// feature. All our compilers do support this, but some issue a warning, so we 
wrap the offsetof()
// call in a macro that disables the compiler warning.

Well, it's just one example that I could quickly think of, but I think it's not 
uncalled for that a project just relies on the implementation of the set of 
supported compilers doing the same, or something equivalent enough. It's hard 
to tell how widespread is the use of #pragma once, but note that in a simple 
Reddit poll done a few months ago, the pragma got 65% of the votes, almost 
twice as include guards:

https://www.reddit.com/r/cpp/comments/rxb6r2/include_guards_or_pragma_once/

> Actually if a reliable implementation of "#pragma once" would be 
> possible, that feature would have been included in the C++ standard for 
> a long time already, wouldn't it?

Same example. The comment on Q_OFFSETOF hints that C++17 seems to allow for 
optional implementations to go beyond what the standard specifies. Why is not 
standardized then? I think the same could be said about this pragma. What it 
does is conceptually very simple, and if it only can hurt on very corner cases, 
then it's a matter of weighting the tradeoffs.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing to move deploy tools to qtbase

[Alejandro Exojo]

On Thu, Nov 25, 2021, at 7:43 PM, Thiago Macieira wrote:
> On Thursday, 25 November 2021 09:21:58 MST Marius Kittler wrote:
> > > I don't need deployment from Linux in order to develop and it looks like
> > > people who have been using cross-compilation have worked around this
> > > issue.
> > 
> > Yes, like mxedeployqt or using static linking.
> 
> macdeployqt is less of an issue because there's no good toolchain for cross-
> compiling to a Mac. Apple does not provide the sources for their ld64 linker, 
> for example. I don't know if lld is a good replacement. Besides, they fork 
> LLVM at an arbitrary point in the branch and may patch it.

I think Marius meant mxedeployqt:

https://github.com/saidinesh5/mxedeployqt

Which is related to MXE, which is another project I'm glad I've learnt today 
about:

https://mxe.cc/

On Fri, Nov 26, 2021, at 9:58 AM, Joerg Bornemann wrote:
> If there are a lot of people doing this we should consider raising 
> cross-compiling from Linux to Windows from "unsupported" to "community 
> supported" at the very least.  I don't expect much work, because it's 
> working quite well.  But it's not tested in the CI at all.

That would be pretty great. I do have access to Windows myself, but it's much
better to just do everything without having to reboot the OS, specially to an OS
that I rarely touch at all.

I will definitely look forward to write about this in a blog post, because this
kind of things are very convenient. I know some people who are very pleased of
WSL for the same reason (reversing the host/target OSs, of course).

Greetings.

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

Re: [Development] Changes to Freenode's IRC

[Alejandro Exojo]

On Wed, May 19, 2021, at 8:16 PM, Giuseppe D'Angelo via Development wrote:
> * there's no registration required;
> * the $newthing has proven stability, staff, resources, etc., and won't 
>   disappear in a few months/years;
> * ...
> 
> then anything is fine.
> 
> All other things being equal, the simplest measure would be to simply 
> move over to Libera. (...)

Can Libera already be considered so quickly? A fork of a software is not so easy
as the "fork" of a service, isn't it? We don't know if they will disappear in a
month, or if Freenode will be fixed by then. Or if another "fork" appears.

Also, I don't understand how not having to register can be a requirement at all,
given that one needs to register, sometimes multiple times, to use some of the
other official channels. E.g. to participate in the mailing list I of course
need to subscribe to it, and to get an email account at all I would either need
to register with some provider or use a work email address (or self-host or...).
If at all, not requiring registration makes me more concerned about spam,
trolling, harassment, etc.

I have my own biases after going through many pains to have a modern-ish IRC
experience (self hosting Quassel, using IRC bouncers, etc.). I hope that the
current active community of people on IRC doesn't get alienated if something
else is chosen, but I also hope that something with proper features is chosen so
I can be back online on those communities, because my paste experience with IRC
makes me not want to go there again unless really needed.

FWIW, I'm now on other IM platforms, and all of Matrix, Telegram, Mattermost and
even Discord seem to have acceptable IRC integration, and some open source
projects treat both sides of the integration as official channels. People seem
to be aware of it, and the friction between the two feature sets and "idioms" of
the platform are more or less respected. So a middle ground is possible as well.

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

Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January

[Alejandro Exojo]

On Mon, Jan 4, 2021, at 2:13 PM, Oswald Buddenhagen wrote:
> https://bugreports.qt.io/browse/QTQAINFRA-4121 for anyone interested in 
> the inevitable community fork.

FWIW, I created https://github.com/qt-lts-community a while ago in preparation 
for this (though I did not think much of this, TBH, I think Gitlab is maybe 
more liked by other parties). Let me know if someone is interested in using 
that Github Organization.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtCS 2018 - Serialisation session notes

[Alejandro Exojo via Development]

On Tuesday 12 June 2018 00:41:38 Thiago Macieira wrote:
> On Monday, 11 June 2018 22:50:09 CEST Rafael Roquetto wrote:
> > Would it also make sense to explore msgpack?  https://msgpack.org/
> 
> No. Msgpack is the older version of CBOR, which we already have.

CBOR is IMHO better than Message Pack, but I don't see it as "the older 
version of CBOR". Rather, a different community (which in my experience has a 
larger adoption rate because it came first). I don't think we need support for 
it on Qt, but people who need to interoperate with it, will need one of the 
existing libraries.

-- 
Viking Software, Qt and C++ developers for hire
http://www.vikingsoftware.com

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

Re: [Development] QtCoap: QNAM-like API or not

[Alejandro Exojo via Development]

On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote:
> In that case, the QCoapReply life is managed with a
> QSharedPointer in the request.
> 
> QCoapRequest does not inherit from QObject. Anyone sees a problem with this
> approach?

The API sounds interesting, but it's a departure of what we are used in QNAM. 
What happened to the idea of using a setter on the manager, for making the 
replies self-delete if wanted? (it was mentioned on the QtCS) That had the 
advantage that can be added to QNAM as well, so both can end up having a 
similar API.

-- 
Viking Software, Qt and C++ developers for hire
http://www.vikingsoftware.com

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

Re: [Development] QtCS 2017 QtCore sessions

[Alejandro Exojo via Development]

On Saturday 02 December 2017 19:11:23 Boudewijn Rempt wrote:
> > > And, c'mon, std::optional's API is just not going to be topped by
> > > QOptional. What should they do? snake_case vs. camelCase? That's what
> > > we need to invest several man-days of development work in, to rename
> > > the functions and stick a Q in front of the class name?
> >
> > There's one thing that a QOptional could do that std::optional can't:
> > be available for all Qt users
> > in a time span of a couple of months.

True. And that, in my very humble opinion, highlights a common problem that 
people face in projects in all languages: wanting to use a standard 
functionality that is not yet available in the platforms that you have to 
support. Many other languages are able to "polyfill"/shim not-yet-standardized 
classes or functions (even members) in a clean way, by adding a 3rd party 
library and done. I would be fine having the same developer experience in C++ 
even if I had to change name spaces and includes, but doesn't seem usual 
practice in C++.

> And another thing: be properly documented in a way that people who
> are not CS phd's can understand. std completely and utterly fails
> in that. Parts of Qt's docs are bad enough, but there's nothing in
> cppreference.com that would pass muster for my gsoc students.

I wholeheartedly agree. I understand the argument of the lambda in find_if in a 
somewhat intuitive way, but the explanations that one finds there about it are 
hugely discouraging to me (full of standardese), even if it's been some years 
using C++. It's not rare to see pages documenting a class or function, that, 
instead of giving examples of its usage, show instead three possible 
implementations. When you are trying to understand how it's used, or why it's 
useful. :-(

And a 3rd point, that not necessarily applies to QOptional if everything is 
templated and inline, but I think still the main blocker for using more 
standard API is the lack of ABI stability. Yes, that's misfeature for some, 
but it's the current rule, so ignoring it is not helping the conversation, 
IMHO.

-- 
Viking Software, Qt and C++ developers for hire
http://www.vikingsoftware.com

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

Re: [Development] [BB++] Now is 3.5x faster than Node.JS

[Alejandro Exojo]

On Saturday 22 July 2017 18:51:28 Phil Bouchard wrote:
> You're probably making a living off memory leaks so it's obvious you get 
> offended but I don't think being a counterproductive manager is good for 
> the Qt company. In fact it's the first time ever I hear about a manager 
> complaining about new technologies that is better and... free.

* You still did not provide evidence that the problems in your QML application 
where due to the garbage collection.

* You did not realize it was impossible to avoid garbage collection in 
JavaScript, and you had to change your plan from improving the engine 
performance, to add a just invented new language to the design to replace a 
(like it or not) well stablished, popular language.

* You claimed about Objective C's ARC "This means the Apple OS leaks", again 
without proof, and when the technology is very very similar to the state of 
the art in C++ with weak and shared pointers.

* You only have brought to the table an implementation that gives nothing that 
QObject already has.

So, sorry, but if you feel rejected by the members of this list is because of 
dubious technical quality, not because one is "making a living off memory 
leaks".

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net

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

Re: [Development] QList

[Alejandro Exojo]

On Wednesday 26 April 2017 07:02:49 Marc Mutz wrote:
> FWIW: I'm against adding even more pessimising goodies to QVector. An 
> area for push_front is such a goodie. The addition this causes is 
> probably the reason why a QList, even for optimal payloads, is 
> outperformed by QVector in my well-known benchmark from -Wmarc. Users 
> that need a queue can use std::deque. If you don't iterate over it, it's 
> a more than acceptable container.

I'm afraid is not so well-known. The benchmark I know is found in:

https://marcmutz.wordpress.com/effective-qt/containers/

There you say:

"I didn’t check prepending, because the results should be comparable to 
appending, at least for those containers which efficiently support them. I 
also didn’t test insertions in the middle, since they’re rather rare."

The closest I know is the one that Stroustrup has shown in his talks (thanks 
Ville for the link; I mentioned this in other thread, but I did not know which 
conference was):

https://isocpp.org/blog/2014/06/stroustrup-lists

But that's a comparison of std::list vs std::vector, and the benchmark is just 
with the container holding integers.

-- 
Viking Software, Qt and C++ developers for hire
http://www.vikingsoft.eu

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

Re: [Development] QList

[Alejandro Exojo]

On Tuesday 25 April 2017 16:35:01 Thiago Macieira wrote:
> QVector and QList don't have the same API. They're slightly different.
> What'sm  ore, QList has a beginning-of-list optimisation, whereas QVector
> doesn't (not even my copy, I stopped development shortly before I got to
> that part, even if I did add a QArrayData::GrowsBackward flag to support
> the case).
>  (...)
> So, no, we can't implement that in Qt 5. In Qt 6, we've already agreed we 
> don't want this mess, so QList as it is simply goes away.

By the way, which is the exit strategy for QQueue? Specially given the first 
paragraph that I quoted. It's been a while since the whole thread, but I don't 
think it's been mentioned, and given that Ville will be making a summary, it's 
worth refreshing, I think.

It's hard to measure how common the usage of a class is, but I think that 
QList is quite a common use case for when you have something 
that is similar enough to a queue, but not necessarily strict. Like when you 
add pointers to requests to the pending ones list. Most likely the ones added 
before will be removed before. So what's the suggested alternative here? 
std::deque?

-- 
Viking Software, Qt and C++ developers for hire
http://www.vikingsoft.eu

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

Re: [Development] Lack of base classes/interfaces? Q*, Q*F

[Alejandro Exojo]

On Monday 17 April 2017 03:25:49 Jason H wrote:
> I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point,
> etc]) don't use an interface? I recently moved some code from ints to
> floats, and I had to change far more code than I should have had to.
> 
> My proposal is to change QRect to QRectI, and make QRect an interface.

Have you thought this through? What would that interface or base class return 
for x()/y()/width(), etc?

Classes like this are normally named "value classes" because you should 
consider them like like regular values that the language provides. That is, 
like int or float, for example, which is very appropriate for the case that 
you bring. Do you really think that there should be a base class for int and 
float? Some languages have that, but follow very different design principles.

You should really explain which kind of code did you change, because just 
recently I adjusted code from using a key press event to a touch event, and 
the point had to change from QPoint to QPointF, and the changes were minimal. 
This wasn't explained to me, but I just found it natural. Also:

https://wiki.qt.io/API_Design_Principles#Static_Polymorphism
 
> In the past, I think I remember some pain points between QList and QVector,
> (or was it QMap, QHash?) which should be QIterable (QIndexable)? Similarly
> all the string types. 

Again I don't see which your problem was. All the containers have a very 
similar API, and the string types too. The algorithms in the standard library 
go to the extent that work with any container (including Qt containers) that 
provides some features and don't need a base class.

And you don't need to be a low-level C++ developer that crafts algorithms and 
writes containers to end up writing code like this, or to see it valuable. 
Some time ago I did a simple proof of concept that used the same code to draw 
with QPainter on a QWidget, QQuickPaintedItem and QRasterWindow. I did it when 
I found the existence of QRasterWindow, saw the similarity of API, and though 
"this could be interesting".

So sorry, you will have to explain more details of what your problem was, 
because it's not clear at all (at least to me) what is so problematic. You can 
use the same kind of container in a foreach or range for loop. You can use the 
same kind of iterator. QList has a lot of convenience API that QVector gained 
as well for easing the porting. So what's left?

-- 
Viking Software, Qt and C++ developers for hire
http://www.vikingsoft.eu

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

Re: [Development] As Qt contemplates its future..

[Alejandro Exojo]

On Thursday 13 April 2017 21:02:59 Randall O'Reilly wrote:
> This also means that there is an endless potential for language wars, which
> I’m sure nobody wants to rehash on this list.

Are you sure? Because in the next sentences seem like you exactly started to 
fight for one side. You said that C++ "is now massively bloated and unwieldy 
in some people’s estimation". And you send that to the mailing list of 
developers of a C++ framework, without wanting to start a war? Really? :-)

-- 
Viking Software, Qt and C++ developers for hire
http://www.vikingsoft.eu

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

Re: [Development] QList

[Alejandro Exojo]

On Wednesday 29 March 2017 20:11:58 Marc Mutz wrote:
> I would really, really 
> like to know why QVector is easier to use? Because it has indexOf()? 
> Seriously, now?

Because it has _lots_ of easy to use member functions, and another kind of 
iterator that is also easier to use for some, and good documentation. I'm not 
making this stuff up:

http://stackoverflow.com/questions/571394/

Hundreds of votes for something immensely simple, that with Qt containers is 
also immensely more readable. Ease of use has a lot more value than 
performance to many people. A thought: how many comments did get the blog post 
that you did on making QRegion iterable? And how many the one about the 
removal of the foreach macro?

-- 
Viking Software, Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Policy for examples with large resources?

[Alejandro Exojo]

On Friday 27 January 2017 15:48:54 Sean Harmer wrote:
> Obviously putting these directly in the qt3d repo is not ideal yet we need 
> examples to demonstrate this stuff (and more in the future). Is there a way
> we  can get a git-lfs repo set up as a submodule to be referenced by the
> qt3d repo?
> 
> Or is there some other solution that would be preferred?

I wholeheartedly recommend that you diverge as little as possible from Git 
LFS. The experience on the client side is really good, and with git v2.11 
(easy to compile locally if your vendor doesn't ship it) the speed has been 
increased 70 times with a new filter system, so it is close to the speed that 
native support would give you.

The problem for the Qt project is server side. Github, Gitlab and Bitbucket 
have support for LFS, but there is no production ready open source standalone 
LFS server (https://github.com/git-lfs/git-lfs/wiki/Implementations) that 
could live side by side with gerrit. Using those 3rd parties would be an 
option, but I don't see how, given that contribution to gerrit is different 
than the pull-request model of those.

The LFS blobs are uploaded as a pre-push hook, so that could be replaced by a 
script that runs rsync to upload your .git/lfs/objects that are not yet on the 
server. That way you ensure all versions are kept.

Then, the download of files happens in the "smudge" filter. You could replace 
that by a script that checks if the blob is there, downloads it, then calls 
git-lfs-smudge. I think you bypass all Git LFS usage of the network, but then 
your history would still be compatible, and the workflow good.

Oh, and there is also a custom transfer support, but I haven't tried myself: 
https://github.com/git-lfs/git-lfs/blob/master/docs/custom-transfers.md

-- 
Viking Software, Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Alejandro Exojo]

On Saturday 19 November 2016 21:08:00 Kevin Kofler wrote:
> I am glad that I am not alone with that feeling.
> 
> And by the way, with my distribution packager hat on, I have to frown upon
> the idea of dragging in yet another dependency just to enforce the C++
> language inventor's personal, not uncontroversial stylistic preferences.

Have you seen the size of the GSL? I think I skimmed in one go through all the 
source code when it was published, and I did it while commuting, on a mobile 
phone. Maybe it's a tad larger now, but according to Mark's comment, stuff 
like owner could even be bundled/reimplemented.

I'm almost always on the side that would not like Qt to change at all if it's 
to make it similar to the standard library API, but I've always had in the 
mental to-do list some patch to Qt that would annotate when ownership of 
QObjects is transferred ("I guess the QNetworkReply returned by QNAM::post has 
a parent, because the docs don't say it should be deleted... Or should be?").

I though that qdoc would be the tool for this (like we have \threadsafe) but 
stuff like owner<> and not_null<> are IMHO vastly superior. And at least they 
chose reasonable names for these. :)

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net

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

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

[Alejandro Exojo]

On Sunday 26 June 2016 23:20:41 Alejandro Exojo wrote:
> This just makes me wonder a bunch of things:

Sorry, I wanted to trash this email that I started to write last Friday, and 
instead I sent it. This reads harsher that what I wanted to send, and I did 
not want to add more noise.

My point is just that it's probably worth considering reviewing a bit the 
process to make a release if making a really quick 5.6.2 is not a reasonable 
path for cases like this. A security-related release would be even more 
important. I think Lars mentioned discussing it at QtCon, so I'll just leave 
the topic to then.

Greetings, and sorry for the noise.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net

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

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

[Alejandro Exojo]

On Wednesday 22 June 2016 05:29:35 Simon Hausmann wrote:
> Approach 3: Include the one declarative fix in 5.6.1, create a new tag and
> rebuild declarative and all the modules that depend on it. That is the
> quickest way of getting the release into the hands of the users (qtbase was
> not rebuilt nor any other module not depending in declarative). We had
> binaries ready for testing in under 24 hours. Note: When I wrote "rebuilt"
> I mean re-compile and also re-run the auto-tests. With a big module like
> qtbase you this can take a few iterations. And once qtbase changes all
> depending modules undergo the same.

This just makes me wonder a bunch of things:

1. Why would it take several iterations to get qtbase working if it's the same 
code already released, and just the version number is bumped? If it's because 
the auto tests can fail from time to time, then I don't get it. The tests fail 
surprisingly often in my humble experience. Running them over and over till 
they succeed will not give you any assurance that the packages are good.

2. Why all this effort in keeping binary compatibility, and splitting sources 
and binaries if you can't release just qtdeclarative with a different version 
than the rest?

3. Why would the qtdeclarative-dependent packages even need to be recompiled? 
Isn't the binary compatibility enough?

4. Why if some of your tools can't cope with 5.6.1.1, assume that 5.6.1-1 will 
be fine for all the downstreams? The dash is used as the separator for the 
packager version it at least one important packaging format.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net

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

Re: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

[Alejandro Exojo]

El Tuesday 26 April 2016, Shawn Rutledge escribió:
> Personally I think event compression should be a cross-platform feature if
> we’re going to have it.  The event-pileup problem can happen also on
> Windows for example, but it seems that we never implemented event
> compression on any platform other than X11.  I’m not sure why.  But we
> don’t plan to do that in the 5.6 series, anyway.

Are you thinking in a generic event compression feature, not only for input 
events? For example, I emit a signal with a "last value" parameter with a 
queued connection (or I just post the event manually), and the receiver can 
discard previous values that it did not have time to process because it was 
slower than the sender. That's not an input event, but it happens through the 
event system anyway.

Now I would think of reimplementing QCoreApplication::notify, but there is the 
warning about Qt6 change, and there is no way to access the already posted 
events (that I know of). There are some reports asking for the feature, BTW:

https://bugreports.qt.io/browse/QTBUG-2688
https://bugreports.qt.io/browse/QTBUG-44293

I suppose if notify() was "soft deprecated" there is not that much 
time/interest in doing this?

> I was told to request this exception on the mailing list, because we
> usually try to maintain source compatibility between releases.

This change being added doesn't worry me much (I don't think it will set my 
computer on fire), so I'm not opposing to it (honestly!) but I don't think the 
issue is source compatibility. It's adding features on already released 
branches. There is a process to ensure that code released has gone through a 
testing procedure. Adding this is bypassing it, while other much innocent 
changes have to wait.

Let me point at some examples, for illustration purposes:

A one line change that fixes QPalette::resolve. It's an obvious fix, but it 
wasn't unit tested, and it changes behaviour, so who knows what might break:

https://codereview.qt-project.org/148552

A microoptimization that looks entirely safe to everyone, but it's not 
critical, so it wasn't committed to the stable branch:

https://codereview.qt-project.org/138746

A simple setter/getter/member addition to QIcon and one line addition to the 
OS X platform plugin to make the system tray icons look properly on Yosemite 
and newer. It's trivial, but it was new API, so it could not go in the stable 
branch:

https://codereview.qt-project.org/115120

Again, honestly, I don't have an axe to grind. Two of this issues affected me, 
but not a lot, and it's already solved, so no big deal now. I'm just a bit 
confused when I see this differences in interpretation of the rules, because I 
don't know what to expect and what not.

Thanks.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt WebKit dependency in Qt Assistant

[Alejandro Exojo]

El Saturday 02 January 2016, Aleix Pol escribió:
> Hi,
> One of the big news lately is the deprecation of Qt WebKit module.
> 
> One of the Qt dependencies on it is assistant (which is a tool I use
> quite often, really) and AFAIK it's using it quite thoroughly. It used
> to be powered by QTextBrowser though, as far as I remember.
> 
> What's the plan there?

It can be compiled to use QTextBrowser instead of WebKit, and it received some 
commits a year ago to improve that abstraction:

http://code.qt.io/cgit/qt/qttools.git/commit/?id=dd45163e883d9db55ce0361db81b96a0c0f97bd7
http://code.qt.io/cgit/qt/qttools.git/commit/?id=008926f193ceb29da6ca94fae6a7efb3ca0e0f09

No WebEngine support for now, though.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: more liberal 'auto' rules?

[Alejandro Exojo]

El Sunday 27 December 2015, Kevin Kofler escribió:
> I consider the C declarator syntax just fine, it is very intuitive and has 
> served us well for 26 years, so I don't see a need to change it.

That some things have served up well for some time, that doesn't mean we can't 
find better things (either to complement, or completely replace the old ones). 
That doesn't mean the AAA style is better just because it's new, of course. I 
just state no opinion. But your justification is wrong.
 
> Implicit narrowing conversions are a feature.

const qlonglong pi = 3.141592653589793238462643383;

That compiles and runs without warnings or errors. A line exactly like this 
ended up in a real application for some alpha version. I don't like this 
feature at all, and I'm glad there is a way to guard you against it (I might 
not like how it has to be done yet, but there are good reasons for wanting to 
avoid this feature).

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Please do not remove QtWebkit from 5.6 official binaries

[Alejandro Exojo]

El Thursday 03 December 2015, Mark De Wit escribió:
> Building from source would be an option, I guess.  We have done it in the
> past, but the build process / flags (for distribution) is not sufficiently
> well documented, and starting with 5.5.1 we were excited to be able to use
> official binaries.

When reproducing a build, I always start with the flags in this repository:

http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QFutureInterface

[Alejandro Exojo]

El Friday 27 November 2015, Bauer, Christian escribió:
> Our (simplified) problem is: this function does not return a value but
> feeds an asynchronous pipeline. When the pipeline processing is done it
> will call promise.SetResult(); promise.reportResult();
> and only then the future should be notified of the result.

I would not mind see your patch in code review, and read what others have to 
say for or against. Having a QPromise or some other public API for QFuture 
would be nice, as you could attach a QFutureWatcher to it.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Where is QtQuick TreeView in QT 5.5.0?

[Alejandro Exojo]

El Saturday 10 October 2015, anton escribió:
> Hi,
> 
> only a small question.

Hello. Please note that this mailing list is for development of Qt itself, not 
for asking questions about Qt. Use the "interest" mailing list next time, 
please.
 
> I wanted to give QT 5.5.0 a try,
> and started a new QTQuick Project in QTCreator.
> 
> I Open the MainForm.ui.qml in the Designer,
> and would like to play with the TreeView but its not available.

http://doc.qt.io/qt-5/qml-qtquick-controls-treeview.html

Look closely at the beginning. Did you import the right module?

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Alejandro Exojo]

El Sunday 12 July 2015, Marc Mutz escribió:
 On Sunday 12 July 2015 13:11:54 Smith Martin wrote:
  And yet you wrote a blog about it instead of submitting the info to us to
  update the QList documentation. Currently, the QList page says this:
  
  QListT, QLinkedListT, and QVectorT provide similar functionality.
  Here's an overview: For most purposes, QList is the right class to use.
  Its index-based API is more convenient than QLinkedList's iterator-based
  API, and it is usually faster than QVector because of the way it stores
  its items in memory. It also expands to less code in your executable.
 
  If your argument is correct, then all three of those sentences are false,
  yes?
 
 Correct.

With respect to less code in your executable, note that in your blog post 
you said:

 On the positive side, QList is a real memory saver when we talk about the
 amount of code generated. That is because QList is but a thin wrapper
 around an internal class that maintains the memory for void*s. This leads
 to more compact code, because all the memory management code is shared
 between QLists of different types.

Does this mean that it changed in Qt5, or am I missing something? Because I 
still see QVector being a pure header class, while some part of QList is in 
the cpp file.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
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

[Alejandro Exojo]

El Sunday 12 July 2015, Thiago Macieira escribió:
 On Sunday 12 July 2015 16:16:07 Smith Martin wrote:
  I can see by your explanation that QVector is almost always more
  efficient than QList. But sometimes the difference doesn't matter.
 
 If it doesn't, then why not choose QVector?

I've carefully read the thread, and I think the issue Martin or others might 
have is:

* Documentation and the common know how about Qt containers tells that QList 
is a reasonable middle ground choice (sometimes is like a vector, sometimes 
like a linked list/vector hybrid). Is what the docs say, what the Qt Quarterly 
article says (which is old, but Olivier gave a recent explanation on 
containers on 2012's devdays), what is being used in the API as return type, 
etc.

* Marc has been criticizing what the docs says, but even being a significant 
contributor to Qt, did not propose to change that.

* According to Martin's explanations, he did send a patch for qdoc that 
replaced a wrong choice of container, but the change did not have any apparent 
effect.

* We are having a large thread with a heated discussion, and Marc said things 
like and the resulting code will be highly fragile and/or extremely 
inefficient. People might felt a bit offended by that. Is something being 
said about their work, after all.


To summarize:

I not sure whether you (plural) think that no container should be advised as 
the preferred one, or if it should be QVector, though.

I think that you, and others who have voiced their opinions agree with Marc on 
vectors being better that what first intuition will tell you (use of a list 
if you have changes in the middle or the beginning is not as right as it might 
seem due to caches). That's something that Stroustrup explained very well, 
e.g.:

https://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-
Stroustrup-Cpp11-Style  (from minute 45 more or less)

In that talk, he shows that std::vector is better than std::list for _all_ N, 
and is an exercise where insertions and deletions happen in the middle. He 
does explain that what dominates is the search for the insertion/removal 
point. That should be quite different with QList.

But Stroustrup _does_ insertion and removals in the middle. Marc's benchmarks 
only do appends, and the says:

 I also didn’t test insertions in the middle, since they’re rather rare.
 That said, there are of course lots of other tests one could run (e.g.
 sorting), and I invite you, dear reader, to implement some of them in the
 test harness and contribute them back.


Well, I certainly don't understand why that's irrelevant. And I think we would 
not be having this conversation if it were that clear.

I *do* really find this discussion interesting, but what I really, *really* 
want is to have the best documentation possible, and if we can't agree on 
which container should be preferred as a first choice, let's remove that and 
move on.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans (CopperSpice)

[Alejandro Exojo]

El Tuesday 30 June 2015, Ansel Sermersheim escribió:
 Our September release of CopperSpice will include changes to the
 contain library, reimplementation of atomic types, our new changes to
 the MetaObject System registration, full API documentation, ??
 
 We would like to encourage developers to attend CPPCon to learn about
 modern C++ and where it is going. For more information please check
 out the following video.
 
  http://cppcon.org/2015promo/

Can you explain which are your long term plans? Given that you renamed all the 
classes and modules (or so I understood), this is full source incompatible, 
and it doesn't seem like you want to sync again with the original Qt 
(applications might include a large file full of typedefs, but applying to 
CopperSpice any bugfix patch found in Qt seems completely manual). Some 
developers experiment with their own branches to research or have fun, which 
is great, but seems like you are aiming to be a full new project.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Fwd: QTextStream::readLine(0) is an ambiguous overload in 5.5

[Alejandro Exojo]

El Monday 18 May 2015, Smith Martin escribió:
 You omitted that toInt(ok) is required to test ok for null, which is not
 required if ok is a reference.

That's extra work in the implementation in order support a nicer API to the 
users, e.g. to support toInt() with the null value as default argument, in 
addition to the passing a pointer makes clear that the value could be 
modified.

And if you don't agree with argument, note that it's what Qt users might 
expect since Qt 4 at least:

http://doc.qt.digia.com/qq/qq13-apis.html#pointersorreferences

(...) I want to share some of our findings and present the principles we've 
been using when designing Qt 4 (...)

And it's common in more projects and code conventions, e.g.:

https://google-
styleguide.googlecode.com/svn/trunk/cppguide.html#Reference_Arguments

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: QtQuick. Custom keys support proposal.

[Alejandro Exojo]

El Friday 01 May 2015, Dmitry Volosnykh escribió:
 Diff of the patch and example of CustomKeys QML attached type may be viewed
 here: https://gist.github.com/dvolosnykh/65819bca1693b0e82058

You should follow the formal procedure, which is submitting it through Gerrit:

http://wiki.qt.io/Qt_Contribution_Guidelines

Submissions through other means can't be merged, since you need to accept the 
CLA (contributors license agreement).

The process isn't difficult, but Git familiarity is assumed. Join #qt-labs if 
you need help.

 In case this change is welcomed, what branch should I target?

It's a new feature, so the dev branch.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Alejandro Exojo]

El Friday 20 February 2015, André Somers escribió:
 Olivier Goffart schreef op 20-2-2015 om 11:38:
  On Friday 20 February 2015 11:26:31 Daniel Teske wrote:
  [...]
  
  That's one area. The others are too replace trivial interfaces with a
  low amount of virtual functions by a std::function properties. This can
  simplify code if e.g. the different implementations don't fit into a
  nice hierarchy.
  
  Note that the Qt ABI (in practice, the Qt public API) cannot use
  std::function because we don't use stl types in our ABI.
  
  So we must roll our own (QFunction).
  (or change the policy)
 
 We already have, don't we? After all, QObject::connect takes a lambda or
 a function-like object...

But that class is QtPrivate::FunctionPointer (aka PointerToMemberFunction in 
the docs) which obviously is not public. There was this discussion on qt-
interest on wether one could use that type for ones own classes:

http://lists.qt-project.org/pipermail/interest/2014-December/014465.html

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Alejandro Exojo]

El Friday 20 February 2015, Tomasz Siekierda escribió:
 On 20 February 2015 at 12:52, Alejandro Exojo s...@badopi.org wrote:
  El Thursday 19 February 2015, Tomasz Siekierda escribió:
  So those companies/ users of QNX are not willing to upgrade their OS,
  compiler, but they are willing to upgrade Qt?
  
  I think the main problem with requiring a very up to date Qt is that
  sometimes only newer versions of Qt have bugfixes.
 
 Same is true for the OSes and compilers...

Only in some platforms, because the release pace of an OS tends to be much 
slower. The example of QNX is 6.5 version published on 2010, with 6.6 released 
on 2014. Qt releases are a lot faster.

Now Microsoft and Apple are releasing faster as well, but remember how long XP 
was supported and it had a non negligible market share that app developers had 
to target.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Alejandro Exojo]

El Sunday 15 February 2015, Sune Vuorela escribió:
 On 2015-02-15, Alejandro Exojo s...@badopi.org wrote:
  People might rely on the function in proprietary applications in ways
  that are impossible to predict.
 
 Every time we fix a bug, we might introduce regressions for people
 relying on the bugs. That's not a reason for not fixing a bug.

I fail to see how changing QLibraryInfo::buildDate to return a hardcoded 
string instead of the intended build date is fixing a bug. Is obvious that you 
are breaking a feature in order to gain a different one that you think is more 
valuable.

I could agree with you on this, but not at the cost of breaking a previous 
feature in a minor release of Qt. It worries me a lot to see this kind of 
changes in minor releases. It sets a precedent.

Not only that. I still think that you could have the reproducible builds 
feature without introducing breakage: just fake the date. Hardcode the date 
where you care about the issue, and not for everybody else. I see there is 
something already available on Debian:

https://packages.debian.org/sid/sdate

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Deprecating modules with 5.5

[Alejandro Exojo]

El Friday 06 February 2015, André Somers escribió:
 All the while Qt is spending effort to catch up, deprecating compilers 
 and platforms because they can't take the latest Javascript engine to 
 it, users are hapily using browers like Firefox and Chrome.
 
 Perhaps it is time to conclude that Qt just can't compete in this race 
 if it doesn't want to be crushed between the giants playing this field. 
 Perhaps it is just time to settle for indeed a simpler goal: don't try 
 to provide a fully integrated full-fledged web engine, but instead 
 settle once again for a simpler alternative that we can support and 
 that can be used for things like showing embedded help or showing simple 
 sites, and perhaps an API to wrap and embed the native web view provided 
 by the platform but with limited integration.

This is a thought that I had several times when reading about the QtWebEngine. 
I understand, though, that the customers that The Qt Company is trying to 
appeal might not have a problem with bundling lots of libraries. Deploying to 
Windows, Mac (or mobile, even though here WebEngine not applies there) already 
means bundling lots of libraries with your application.

We all know how web browsers have changed. From reasonable applications 
capable of fetching a file through a simple one way protocol, and displaying a 
mostly static multimedia content, to huge beasts that require lots of complex 
network (websockets, WebRTC), multimedia, graphics, devices, storage, etc.

Kevin said Relying on Chromium is a horrible idea, but non-horrible 
solutions probably won't exist anymore if you add a web browser into the mix. 
You probably will have to surrender to what the upstream team that developed 
the browser left you. And there aren't that many upstreams.

Speaking of that...

What about Gecko? Is the license a problem? Or is still a technical reason?

Because a long term possibility would be to team up with people in GNOME or 
KDE who might need a web browser engine, and speak with Mozilla to help. After 
all they are supposed to be a non-profit, so collaborating with other open 
source projects should be in their DNA. It's not like their XUL has much use 
outside their projects, so having some Qt and GTK+ integration and more users 
of their technologies should be good for their mindshare.

Here are some notes on the patches that Sailfish Browser needs to embed Gecko:

http://blog.idempotent.info/posts/whats-behind-sailfish-browser.html

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Do QtQuick.Layouts depend on QtQuick.Controls?

[Alejandro Exojo]

El Tuesday 09 December 2014, Dmitry Volosnykh escribió:
 Hi!
 
 What's New in Qt 5 documentation article
 (http://qt-project.org/doc/qt-5/qt5-intro.html) under
 Designing UI Made Simpler section introduces Qt Quick Controls and
 Qt Quick Layouts modules at once. As far as I can see there is no
 clear evidence that Layouts may be used separately from Controls. The
 only pros I am aware of are Qt Quick Layouts Overview article
 (http://qt-project.org/doc/qt-5/qtquicklayouts-overview.html) and my
 personal similar experience with desktop Qt 5.

Those are independent.
 
 The question arised from the situation when I faced the absence of
 Layouts on embedded Linux box with custom build of Qt 5 by my collegue
 who states that it was default build for that platform. We don't need
 Controls there sicne all the UI is handcrafted by our team, but we
 would really like to have Layouts available because it really
 simplifies UI composition!

The plugins are different, but the git repository where the source is present 
is the same. You have to build the qtquickcontrols repository, or you will 
miss the layouts.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.4.0 header diff: QtSql.diff

[Alejandro Exojo]

El Wednesday 19 November 2014, Thiago Macieira escribió:
 On Tuesday 18 November 2014 16:24:05 Thiago Macieira wrote:
  On Tuesday 18 November 2014 16:38:55 Frederik Gladhorn wrote:
 Attached the wrong file.

Probably irrelevant, but, on which branch was the script run? On both 5.4.0 
and 5.4 (as of this morning), I see the enum DBMSType declared on 
src/sql/kernel/qsqldriver.h. That's where appears on Frederik's mail (the one 
with the license differences). In the last diff is in qsql.h instead.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.4.0 header diff: QtSql.diff

[Alejandro Exojo]

El Thursday 20 November 2014, Alejandro Exojo escribió:
 El Wednesday 19 November 2014, Thiago Macieira escribió:
  On Tuesday 18 November 2014 16:24:05 Thiago Macieira wrote:
   On Tuesday 18 November 2014 16:38:55 Frederik Gladhorn wrote:
  Attached the wrong file.
 
 Probably irrelevant, but, on which branch was the script run? On both 5.4.0
 and 5.4 (as of this morning), I see the enum DBMSType declared on
 src/sql/kernel/qsqldriver.h. That's where appears on Frederik's mail (the
 one with the license differences). In the last diff is in qsql.h instead.

Ok, I see what happened. The header of the diff doesn't match the content. At 
the top it says is diffing src/sql/kernel/qsql.h, but is showing the contents 
of QSqlDriver.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Is QMap Broken

[Alejandro Exojo]

El Monday 10 November 2014, Robert Steckroth escribió:
 [SOLVED]: After perusing the qmap.h libraiy I found the reason why QMap was
 keeping a sorted node list.

Please, instead of opening bug reports, digging in the sources, and wasting 
everybody's time, you should read one of the very first lines of QMap 
documentation:

With QMap, the items are always sorted by key

If you missed that, and got confused by the description of the function you 
wanted to use (because maybe the description wasn't 100% clear that the 
position was NOT where you wanted the element inserted), then yes, you can ask 
the mailing list (the correct one is inter...@qt-project.org instead of this 
one, though).

And if you ask the mailing list, read the replies you got, because people 
already told you that QMap works as expected, and which other classes you can 
use if you need insertion order instead.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt-4.8.6 support SylixOS, a RTOS from china

[Alejandro Exojo]

El Friday 24 October 2014, jiaojinxing1...@gmail.com escribió:
 Now the latest qt 4.8 6 run on sylixos is very stable,
 
 And supports advanced features such qws and webkit. 
 We are willing to contribute our code to qt organization.

That's great, but note that Qt 4 is feature frozen. I don't know if adding a 
mkspec would count as a feature, but other changes might be impossible to 
merge at this point, unless you found bugs and you submit those individually.

The process for sending contributions is documented in this page, and the ones 
linked:

http://qt-project.org/wiki/Qt-Contribution-Guidelines

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

[Alejandro Exojo]

El Tuesday 07 October 2014, Tomasz Siekierda escribió:
 For file paths, I feel QString is really enough.
 Changing it to something else because of a few corner cases seems like
 an overkill to me.

Just for the sake of documenting the issue and pointing to this thread if 
future questions arise: Is there some solution for those corner cases?

Say one writes a file manager with Qt, and has to support that one file name 
with a wrong encoding could be renamed to the right one. Should that person 
skip the Qt classes?

BTW, subject says non-Windows systems, but IIRC Mac OS X doesn't allow two 
files with equivalent names (e.g. composed vs the precomposed characters that 
are equivalent). Does it apply as well?

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Linux release binaries too old

[Alejandro Exojo]

El Monday 25 August 2014, Blasche Alexander escribió:
 Hi,
 
 It is my understanding that the current Linux release binary packages are
 built on Ubuntu 11.10 machines. This is very ancient. In fact for
 Bluetooth Low Energy (new feature in 5.4) this is too ancient.
 
The reason to use an old distro was to support a broad set. If you use a newer 
one, the symbol versioning of libc gets in the way, and the binaries no longer 
work on other distros.

 What's needed is a machine that has Bluez 4.101 or newer. This means even
 the fairly old 12.04 is too old unless we retrofit those newer headers. If
 we don't want to retrofit and assuming we want to stay with Ubuntu we'd
 require 14.04.

How feasable is to backport a newer BlueZ to that old distro, on the machines 
that build the binaries? I managed to do a quick and dirty BlueZ 5 backport to 
Debian stable quite easily (where easy means I got the backported kernel 
already on the distro, so that's done). I can give it a try if needed, since 
BlueZ 4 should be easier. I don't remember any kernel requirements.

 Bluetooth requires the newer headers only at build time. I tested binaries
 on 12.04 by faking the new symbols and it still seemed to work.
 
 The question is how many old distros do we leave behind? Bluez 4.101 was
 released in June 2012. If distros update Qt they are likely to recompile
 anyway.

Release dates are a bit misleading here. ;-)

Compare the popularity of Qt4 vs Qt5 applications on distributions. With BlueZ 
is worse, since is a complete rewrite of the API. Even the most recent Ubuntu 
is still on BlueZ 4.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Alejandro Exojo]

El Wednesday 09 July 2014, Thiago Macieira escribió:
 === Log to both ===
 Aside from the extra overhead, this causes systems that capture both stderr
 and the system log to record and display the same message twice. That's the
 source of task [3].
 
 This is not an option.

Why not? Task [3] is an issue in Qt Creator, isn't it? Why it needs to read 
the system log on Windows?

Logging to the console _and_ journald has proven very useful to us. We did it 
specifically for an application using Qt's API, and developers can code, press 
Run (in Creator), and see the output in the same window with all the 
QT_MESSAGE_PATTERN goodness. Afterwards, if it's too noisy, or if you disabled 
some category, you can check the logs on journald (we logged all categories, 
even the disabled ones, to the journal, since we had or own message handler).

It's not hard at all to do it on your application if you want to fine tune it. 
Actually, I never expected to see the journald logging in Qt, but having it 
IMHO it's a boon, since you can use the feature for 3rd party applications.

Only downside is that you might need to collect what your application outputs 
to stderr from a non-Qt library. Then yes, you might get duplicated messages.

 === Heuristically determine at runtime where to send the log ===
 On Unix, I have implemented the same checks.
 
 We can also use the fact of whether the main application is in debug mode
 or not.

I see this as two orthogonal things. Why would one prefer the console on a 
debug build? You might need to put the program in debug mode on the target 
hardware (only device where you have the peripherals), and need the enriched 
system logging and the debug symbols.

This is the most inconvenient change, since you might need to change the 
systemd unit file to set the QT_LOGGING_TO_CONSOLE environment variable to have 
the built in journald logging.

 == Summary of systems ==
 System services on Linux with journald:
  - default stderr: captured into system log
  - system logging: available
  - is stderr useful: yes, for launching from terminal

Note that you can teach systemd to ignore stderr/stdout if wanted. If the app 
is written with Qt, that can be a sane default.
 
 And then some desktop Linux distributions decided to enable journald. The
 effect of that is task [6]: Qt Creator shows no output because it goes to
 journald.

But this comment is/was in the code:

We use isatty to catch the obvious case of someone running something 
interactively. We also support environment variables for Qt Creator use (...)

I thought that it was agreed/known to Qt Creator developers that 
QT_LOGGING_TO_CONSOLE might be gently defaulted to true for applications run 
by Creator.

That environment variable seems like API to me, and a useful one that 
Creator could use. Of course they couldn't predict some distributions would 
pass -journald to configure.


From the other messages:

 * Support for journald in the pre-built Qt binaries:
 Disabled.

Probably will be that way for a long time. If Qt binaries are built with and 
old Ubuntu, they just don't have libsystemd-journal.

 Note: if journald is writing to volatile storage, regular users can't read
 the log. Therefore, system logging is not available.
 
 Linux distributions should not enable journald logging unless regular users
 can read the output.

I think users can read their user journal, independently of the storage. This 
is as user nobody:

$ systemd-journalctl
Showing user generated messages only. Users in the group 'adm' can see all 
messages. Pass -q to turn this message off.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Alejandro Exojo]

El Thursday 10 July 2014, Koehne Kai escribió:
 Provide a define QT_LOG_TO_CONSOLE  that let QCoreApplication.h record
 whether it should log to console (QT_LOG_TO_CONSOLE=1), to the system
 (QT_LOG_TO_CONSOLE=0), or both (QT_LOG_TO_CONSOLE=2). 

Would it be too problematic to make the environment variable 
(QT_LOGGING_TO_CONSOLE, which already is in use) accept also a 2 for logging 
to both sources?

To me, the really interesting feature of providing such code inside of Qt is 
to enable it without having to touch legacy/third party code. Having it for 
your application is also nice, but you'll likely need to override it somehow 
to integrate it with your configuration or UI.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Alejandro Exojo]

El Friday 11 July 2014, Lisandro Damián Nicanor Pérez Meyer escribió:
 AFAIU from this thread, journald support should not be enabled except
 regular  users can read the output. Now what I'm missing here is: if Qt
 is built with journald support, can it be still be used if journald is not
 present?

No. Quote from: 
http://www.freedesktop.org/software/systemd/man/sd_journal_send.html

If systemd-journald(8) is not running (the socket is not present), those 
functions do nothing, and also return 0.
 
 Yes, I happen to be maintaining Qt for a distro in which users can still 
 choose the init system.

And unfortunately, there is no clean way to test for it. There is the 
sd_booted() function, but:

Internally, this function checks whether the directory /run/systemd/system/ 
exists. A simple check like this can also be implemented trivially in shell or 
any other language.

Which wasn't enough in my tests. Since I used systemd to boot the (developer) 
system, but I ran the app on Creator, it would return true all the time, and I 
got no output on Creator.

It might be even worse if systemd-shim provides that directory. Is it worth to 
try sd_journal_open() and see if it fails? Or check some other way if systemd 
actually launched the application?

Also, the way is done now (more after the patch on review) is to check for the 
console first, and then the decision is done. If the heuristics to find a 
console are good enough for you, having journald support is irrelevant, since 
if you are in a console you'll get the stderr printing.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] My contribution : Extension to Qt

[Alejandro Exojo]

El Wednesday 04 June 2014, Olivier Goffart escribió:
 Where is it?  Do you have any URL?

He replied to my privately (by mistake I suppose) saying it was on github, so 
after a search:

https://github.com/u19809/DynamicQObject

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] My contribution : Extension to Qt

[Alejandro Exojo]

El Monday 02 June 2014, wim delvaux escribió:
 I tried using gerrit but this is very tedious (setting up GIT, getting
 access to Qt code, downloading lost of 'git' code which is not needed, etc)
 I find this unnecessary as my extension compiles just like a simple Qt
 Project
(...) 
 I would like to offer this code to the community.
 
 which would be the best location for me to offer this code ?

If you want to offer the code to the community, just publish it online (in a 
repository, if possible... I hope your version control are not ZIP files).

If you want to make it part of the Qt project, there is no way around it: if 
you wrote the code and have the copyright, you have to publish it accepting 
the contributors agreement, and that's done through Gerrit.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Alejandro Exojo]

El Martes, 22 de octubre de 2013, Knoll Lars escribió:
 So much for Linux distributions keeping binary compatibility.

Isn't exactly the same situation as with Qt? When the next version of Qt 4.8 
breaks binary compatibility, libqt5 is introduced. You link against either one 
or the other, and generally, both could be available for you to choose.

I'm surprised that libudev0 is not there, though. I suppose all applications 
that used libudev0 are ported to the new one.

 Not
 providing the package means you break every 3rd party app that needs
 libudev and doesn't come as part of the package management.

Which is the point of the package system of all distributions, isn't it? And I 
might add that is such a good idea that Microsoft and Apple also introduced 
similar concepts in their (desktop) systems.

Let me add a bit of constructive criticism:

I've been a fan of the installer framework and the Qt SDK. I understand that 
is not going away for a variety of reasons, and that in some use cases is the 
best approach to having a binary installer of Qt, Creator, etc. But after 
using it a lot, I've found the several issues:

- Recommended it to coworkers, and they installed it under the suggested 
directory ($HOME/Qt, if I recall correctly). Is the preferred place anyway 
since you don't have permissions to install in the root of the FS. Then 
another person wants to use the SDK in the same computer as well (but with a 
different account), so uninstall it, create some world-writable directory, and 
run the installer, this time pointing it to /opt/Qt. Now the other users are 
able to see the binaries and run them, but they don't have the shortcuts! 
Let's copy the files under ~/.config and ~/.local from one user to the other. 
Done (finally).

- After the nice experience of having the latest Qt available for development, 
I realize is not going to be so easy to put it in the target machine, since it 
is headless (yes, the app is QtCore/Network only), and I can't run the 
installer there. I ended copying the files from my PC, but I had to tweak 
LD_LIBRARY_PATH since the RPATH pointing to the developer's HOME is not very 
useful. :)


After this, my opinion is that the preferred way to go should be to think more 
in native package system for Linux. For example, Clang is shipping nightly 
builds through the package system: http://llvm.org/apt/ (ok, this are deb 
packages only, but the OBS provides several types of binaries for many 
distributions)

I don't know if it should be done downstream, or as additional binaries to 
what distributions offer. All I can say is that in the next months I'm going to 
need binaries of Qt 5.2 that work on Debian stable. Since that's not going to 
be provided by official repositories, I would prefer if the work is not wasted 
just for my own use case, so I will knock doors to see if somebody else is 
interested, or I can share the work with Debian packagers.

Thank you.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Names of classes in Android Extras

[Alejandro Exojo]

Hi.

I've stumbled upon the names of the classes in Qt Android Extras:
- QJNIEnvironment
- QJNIObject

The all capital part due to the acronym is inconsistent with other Qt classes, 
where the acronym is written as if it were a word: e.g. QHttp* instead of 
QHTTP*, QUrl instead of QURL, etc.

I've mentioned on IRC, and Rich Moore told me it wasn't too late to mention 
the issue. He said it might be possible that the naming was chosen to be 
consistent with JNIEnv.

What do you think?

Cheers.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development