On Tuesday 13 January 2015 10:45:07 Thiago Macieira wrote:
> On Friday 02 January 2015 15:39:31 Thiago Macieira wrote:
> > I need a little help with forkfd for OS X 10.7. The builds with forkfd
> > have
> > failed on the CI on 10.7 only for no reason I can determine. If you have
> > access to 10.7
On Tuesday 20 January 2015 01:49:01 Lisandro Damián Nicanor Pérez Meyer wrote:
> > > For the sake of completeness, we are not allowed to do so in the same
> > > strength that the Qt project doesn't allows binary incompatibility
> > > between
> > > minor versions, and for which us downstreamers are
On Monday 19 January 2015 20:25:55 Thiago Macieira wrote:
> On Tuesday 20 January 2015 01:11:55 Lisandro Damián Nicanor Pérez Meyer
wrote:
> > On Monday 19 January 2015 19:30:46 Thiago Macieira wrote:
> > [snip]
> >
> > > > So, as Sune Vuorela also explained, having multiple major versions of
> >
Thiago Macieira wrote:
> And like I said, Fedora's and RHEL's refusal to follow the recommendation
> is their own problem. You get to pick the pieces from what you broke.
As an additional data point, openSUSE is also shipping qmake as qmake-qt5,
and as far as I can tell, they do not even have qtc
On Tuesday 20 January 2015 01:11:55 Lisandro Damián Nicanor Pérez Meyer wrote:
> On Monday 19 January 2015 19:30:46 Thiago Macieira wrote:
> [snip]
>
> > > So, as Sune Vuorela also explained, having multiple major versions of Qt
> > > in
> > > parallel is always going to be a fact of life.
> >
>
On Monday 19 January 2015 20:23:30 Thiago Macieira wrote:
> On Tuesday 20 January 2015 00:47:50 Lisandro Damián Nicanor Pérez Meyer
wrote:
> > I think there is a point which we might be missing in this long thread.
> > For
> > Qt5 we are not asking for a simple rename because that *would* break st
On Tuesday 20 January 2015 05:04:05 Kevin Kofler wrote:
> > Remember: you (implicitly) agreed with the solution in 2012.
>
> I did not agree with anything at all.
>
> You brought up a discussion on a Qt Project mailing list, to which most
> distribution packagers are not even subscribed. You got
On Tuesday 20 January 2015 05:06:10 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > I'm not sure I see the distinction between users and customers here.
> >
> > When you say "users", are you thinking of a person who builds a Qt-using
> > software from a 3rdparty?
>
> There are also developers wh
On Tuesday 20 January 2015 05:04:05 Kevin Kofler wrote:
> Software on GNU/Linux often gets developed against distribution -devel
> packages. I definitely do that whenever possible. Do you really think that
> all developers of Qt-using software download your upstream binaries or
> build your sour
On Tuesday 20 January 2015 00:47:50 Lisandro Damián Nicanor Pérez Meyer wrote:
> I think there is a point which we might be missing in this long thread. For
> Qt5 we are not asking for a simple rename because that *would* break stuff
> for other people, and that's not fair. What we ask is *adding*
On Monday 19 January 2015 20:14:33 Thiago Macieira wrote:
> On Tuesday 20 January 2015 00:57:55 Lisandro Damián Nicanor Pérez Meyer
wrote:
> > > qdbus should be the same in all versions. I don't plan on making
> > > breaking
> > > changes in the future -- I can't see what I could do to create such
On Tuesday 20 January 2015 01:01:57 Lisandro Damián Nicanor Pérez Meyer wrote:
> On Monday 19 January 2015 18:46:18 Thiago Macieira wrote:
> [snip]
>
> > As for Designer, the discussion in 2012 was that its output is compatible
> > with Qt 4 and will remain so, but distributions need to upgrade th
Lisandro Damián Nicanor Pérez Meyer wrote:
> So if a distro ships both Qt4 and Qt5 in the special case of designer we
> can call Qt5's version in all cases? I'm pretty sure I'm missing something
> wrt plugins here (ie, I'm not correctly getting the right thing to do,
> sorry).
I really wouldn't tr
On Tuesday 20 January 2015 00:57:55 Lisandro Damián Nicanor Pérez Meyer wrote:
> > qdbus should be the same in all versions. I don't plan on making breaking
> > changes in the future -- I can't see what I could do to create such
> > problems...
>
> I just wrote an example in another mail, supposin
On Monday 19 January 2015 19:30:46 Thiago Macieira wrote:
[snip]
> > So, as Sune Vuorela also explained, having multiple major versions of Qt
> > in
> > parallel is always going to be a fact of life.
>
> Indeed, but the Qt devs' original proposal was to simply put it outside
> /usr/bin, possibly e
Thiago Macieira wrote:
> I'm not sure I see the distinction between users and customers here.
>
> When you say "users", are you thinking of a person who builds a Qt-using
> software from a 3rdparty?
There are also developers who are not paying customers of Qt Commercial.
Those developers using Q
Thiago Macieira wrote:
> That logic is inverted. It needs to try qmake first because it might be a
> more recent version, installed by a binary from the Qt Project, since we
> don't rename. Any qmake-qt4 tool, if present, is an older version from the
> distribution.
The only thing I promised is th
On Monday 19 January 2015 18:46:18 Thiago Macieira wrote:
[snip]
> As for Designer, the discussion in 2012 was that its output is compatible
> with Qt 4 and will remain so, but distributions need to upgrade the plugins
> to use Qt 5 instead and we can't be blamed if the plugins break their
> behav
On Monday 19 January 2015 18:44:14 Thiago Macieira wrote:
> On Sunday 18 January 2015 18:06:45 Lisandro Damián Nicanor Pérez Meyer
wrote:
> > If I'm wrong then simply unmasking qdbus with qtchooser should be enough.
> > /usr/bin/qdbus should be provided by the default version (qt4's one in our
> >
On Monday 19 January 2015 19:07:29 Thiago Macieira wrote:
> On Monday 19 January 2015 15:18:41 Lisandro Damián Nicanor Pérez Meyer
wrote:
> > > Distributors are going a great job creating Qt packages. But not
> > > everyone
> > > is using their distro's Qt. In fact, looking at our customers I'd sa
On Monday 19 January 2015 15:01:20 Harri Porten wrote:
> On Sun, 18 Jan 2015, Kevin Kofler wrote:
> > Thiago Macieira wrote:
> >> The one requirement that came from the Qt Project was that the tools
> >> would
> >> not be renamed.
> >
> > And the one requirement that came from the distros was that
Milian Wolff wrote:
> It can, indeed. But funnily enough it's not going to be much faster, at
> least in the tests I did. Still, one should probably be doing this
> anyways. I'll try to dig up my patch for that and sent it to Gerrit. It's
> a pity that one cannot just convert a const char* to a QCh
On Sunday 18 January 2015 18:06:45 Lisandro Damián Nicanor Pérez Meyer wrote:
> If I'm wrong then simply unmasking qdbus with qtchooser should be enough.
> /usr/bin/qdbus should be provided by the default version (qt4's one in our
> case) and we might even let qt5-qdbus depend upon it's qt4 versi
On Sunday 18 January 2015 22:24:40 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > That said, back in 2012 when we were discussing the renaming, I made the
> > argument that some of our binary executables are not "build tools" but are
> > instead "user applications". Those should not be installed
On Sunday 18 January 2015 22:24:15 Kevin Kofler wrote:
> Konstantin Ritt wrote:
> > There is no need for moc/rcc/uic to be suffixed. In fact, they are an
> > internal build tools invoked by qmake and thus they should normally reside
> > in libexec dir (or you may query qmake for its specific libexe
On Monday 19 January 2015 00:16:48 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > Because we're in 2014. Qt 4.0 was released in 2005 and the binary wasn't
> > renamed. Software is supposed to work with the official version too and
> > there are 9 years of history of us releasing "qmake".
> >
> >
On Monday 19 January 2015 15:18:41 Lisandro Damián Nicanor Pérez Meyer wrote:
> > Distributors are going a great job creating Qt packages. But not everyone
> > is using their distro's Qt. In fact, looking at our customers I'd say that
> > most of them have their own Qt install somewhere on their di
On Tuesday 20 January 2015 04:05:20 Kevin Kofler wrote:
> Oswald Buddenhagen wrote:
> > correct. as far as i'm concerned, the purpose of qtchooser is to be a
> > frontend tool which targets developers working with multiple qt
> > versions, regardless whether these versions come from distro packages
Oswald Buddenhagen wrote:
> correct. as far as i'm concerned, the purpose of qtchooser is to be a
> frontend tool which targets developers working with multiple qt
> versions, regardless whether these versions come from distro packages or
> own builds.
The thing is, we asked for something that ful
That type was in fact added, as QContactType::TypeFacet in commit 03be9e28b.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Monday 19 January 2015 17:27:40 Renato Araujo wrote:
> Hey guys,
>
> I started to implement the class QContactCollection based on
> QOrganizeCollection[1]. Until now I just copy the code from QOrganizer
> module and renamed some classes.
>
> The idea of QContactCollection is to represent an "a
QContactType::TypeGroup is meant to represent a group of entities with
shared contact details (eg, a local football club might have a mailing-list
email address, a clubhouse phone number, etc). Individual contacts can
have membership in groups (so various friends can be members of the
football clu
On Monday 19 January 2015 20:48:54 Olivier Goffart wrote:
> On Monday 19 January 2015 20:15:22 Milian Wolff wrote:
> > Hello all,
> >
> > when I run my heaptrack [1] tool on Qt 5 applications, I often stumble
> > upon
> > the compose TableGenerator. It initializes many QStrings and also consumes
>
Hi,
The idea is to move the compose file reading code out of Qt. libxkbcommon 5.0
(released on 2014-10-18 [1]) added support
for the compose keys. I did look at the new API already in October [2]. It
should be simple enough to remove the table generation code and use xkbcommon's
API instead. I
For what I understand every detail already have such functionality
[QContact.detailUri] with this field you can specify from which contact
this detail belongs, based on QContact.Guid;
Is correct to say that a contact which the type is "TypeGroup" is a meta
contact with information from different c
IMO, such a merged contact should belong to a special "address book" - one
that aggregates contacts and knows which field/detail came from this or
that real contact.
Regards,
Konstantin
2015-01-20 0:27 GMT+04:00 Renato Araujo :
> Hey guys,
>
> I started to implement the class QContactCollection
On Monday 19 January 2015 21:17:00 Giuseppe D'Angelo wrote:
> > The best approach of course would be to have a OpenDesktop standard that
> > allows mmapping the compose table in and using it from there. Probably not
> > feasible.
>
> Why not?
x...@freedesktop.org. I think I can easily convince th
Hey guys,
I started to implement the class QContactCollection based on
QOrganizeCollection[1]. Until now I just copy the code from QOrganizer
module and renamed some classes.
The idea of QContactCollection is to represent an "address-book". And with
this we can create/remove/modify collection and
Il 19/01/2015 20:15, Milian Wolff ha scritto:
The best approach of course would be to have a OpenDesktop standard that
allows mmapping the compose table in and using it from there. Probably not
feasible.
Why not?
Also cf.
https://codereview.qt-project.org/#/c/74524/
https://codereview.qt-proje
Hi all,
Yes, thanks to Mike! He started it implementation, but does not complete
it. ;)
For example, some people (e.g. on our russians forums) ask me about
"non-rooted" Android support. In this case I always forward/point these
people to Mike's patches (to looks and to try those patches). B
On Monday 19 January 2015 20:15:22 Milian Wolff wrote:
> Hello all,
>
> when I run my heaptrack [1] tool on Qt 5 applications, I often stumble upon
> the compose TableGenerator. It initializes many QStrings and also consumes
> ruoghly 400KB of memory. I wonder whether we could optimize this someho
On Monday 19 January 2015 20:15:22 Milian Wolff wrote:
> I usually don't use the compose key, so my
> naive assumption would be that lazy-loading this table would help the
> common case of startup quite a bit already. Or is this required for other
> things that I don't expect?
It applies to dead
Hello all,
when I run my heaptrack [1] tool on Qt 5 applications, I often stumble upon
the compose TableGenerator. It initializes many QStrings and also consumes
ruoghly 400KB of memory. I wonder whether we could optimize this somehow?
The best approach of course would be to have a OpenDesktop
On Monday 19 January 2015 15:01:20 Harri Porten wrote:
> On Sun, 18 Jan 2015, Kevin Kofler wrote:
> > Thiago Macieira wrote:
> >> The one requirement that came from the Qt Project was that the tools
> >> would
> >> not be renamed.
> >
> > And the one requirement that came from the distros was that
On 2015-01-19, Oswald Buddenhagen 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
Thiago Macieira wrote:
> On Saturday 17 January 2015 23:46:58 Kevin Kofler wrote:
>> Therefore, we are NOT shipping qtchooser in Fedora by default, and our
>> qtchooser package in the online repository (package which we only ship at
>> all due to the insistence of one individual packager – both I
On Sun, 18 Jan 2015, Kevin Kofler wrote:
> Thiago Macieira wrote:
>> The one requirement that came from the Qt Project was that the tools would
>> not be renamed.
>
> And the one requirement that came from the distros was that the tools must
> be renamed. This was made very clear from the beginnin
On Sat, Jan 17, 2015 at 4:49 PM, Fanda Vacek wrote:
> Hi,
>
> please, is there anybody with +2 who can make review for patch on this
> bug (https://bugreports.qt.io/browse/QTBUG-39477)?
>
> It is marked as CRITICAL since 5.2 and patch is prepared for review. We
> have 5.4.1 now and the bug is sti
consider this a meta-reply to the entire thread.
On Sat, Jan 17, 2015 at 11:46:58PM +0100, Kevin Kofler wrote:
> Thiago Macieira wrote:
> > packagers, like we did in the past for qtchooser (a solution
> > designed for distro's needs).
>
> Hahaha, that's a good one!
>
> Qtchooser is designed comp
Because some unfortunate code in the Windows platform plugin generates expose
events even when the size has not changed. This is of course wrong. It will be
corrected by https://codereview.qt-project.org/#/c/103932
Cheers,
Laszlo
From: development-bounces+las
Hi Louai,
Thank you for returning this thread back to the original topic.
I think what you propose there is very good idea indeed! Why make
JavaScript libraries more complex to handle than any other library?
-
Pasi
On 19/01/15 13:19, "Al-Khanji Louai"
wrote:
>The thread seems to have derail
The thread seems to have derailed quite badly, so let's reboot it and return to
the original topic of how to bundle the javascript code.
If I understand correctly, there is a desire to be able to provide the modified
three.js code as a separate package.
We have an existing solution for this, th
Hi,
Il 16/01/2015 21:28, Ben Beckwith ha scritto:
I'm building on Ubuntu 14.04. I git the Qt 5.4.1 source and then git
the Qt3D source (dev branch). Here's my config line:
Unfortunately 5.4.1 is not enough, you need qtbase and qtdeclarative
from dev branch as well. See
http://qt-project.o
Hi,
please, is there anybody with +2 who can make review for patch on this
bug (https://bugreports.qt.io/browse/QTBUG-39477)?
It is marked as CRITICAL since 5.2 and patch is prepared for review. We
have 5.4.1 now and the bug is still here.
The bug is really blocker for my project
(https://git
I don’t know if it is on a patch somewhere, but I did upload it. I did have a
working version that used the usb-serial-for-android library. In fact I used
that version on a project. There was talk of changing that to a library that I
would write, but I was pulled off onto other projects at wo
I am attempting to animate a QOpenGLWindow, so I'm connecting
SIGNAL(frameSwapped()) with SLOT(update()) to force update on vsync as
recommended in the documentation. So far so good, under *nix OSes this
works fine. (Tested on x64 Ubuntu and OS X)
But on Windows, when dragging a window around, the
Howdy!
I'm trying to build the latest Qt3D and I'm runing into following issue:
g++ -c -pipe -g -fvisibility=hidden -fvisibility-inlines-hidden -std=c++0x
-fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV
-DQT3DRENDERER_LIBRARY -DQT_BUILD_3DRENDERER_LIB -DQT_BUILDING_QT
-DQT_NO_CAST_TO_AS
> On Jan 18, 2015, at 6:34 AM, Kevin Kofler wrote:
>
> Thiago Macieira wrote:
>> Now we have a legacy to keep, so we can't accept a radical change. Only
>> incremental improvements.
>
> You will find that very few deployments out there in the real world use
> qtchooser. The widely-used RHEL mo
> On Jan 18, 2015, at 10:24 PM, Kevin Kofler wrote:
>
> Konstantin Ritt wrote:
>> There is no need for moc/rcc/uic to be suffixed. In fact, they are an
>> internal build tools invoked by qmake and thus they should normally reside
>> in libexec dir (or you may query qmake for its specific libexec
Everything is back to normal.
--
Alex
From: development-bounces+alexander.blasche=theqtcompany@qt-project.org
on
behalf of Blasche Alexander
Sent: Monday, January 19, 2015 09:25
To: development@qt-project.org
Subject: Re: [Development] JIRA broken
I can confirm there is a problem with Jira. We'll investigate.
--
Alex
From: development-bounces+alexander.blasche=theqtcompany@qt-project.org
on
behalf of Guido Seifert
Sent: Sunday, January 18, 2015 13:22
To: development@qt-project.org
Subject: [
61 matches
Mail list logo
