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
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 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 the tools must
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.
Indeed, but
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 very
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, supposing a
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 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
case)
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 who are not
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 only
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 source
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 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
ruoghly
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
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 the
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
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 say
that
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
Qt
in
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 or
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 libexec dir
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 in a
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.
Therefore,
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 disk.
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 even
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
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
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 QChar
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 that
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
I can confirm there is a problem with Jira. We'll investigate.
--
Alex
From: development-bounces+alexander.blasche=theqtcompany@qt-project.org
development-bounces+alexander.blasche=theqtcompany@qt-project.org on
behalf of Guido Seifert
Everything is back to normal.
--
Alex
From: development-bounces+alexander.blasche=theqtcompany@qt-project.org
development-bounces+alexander.blasche=theqtcompany@qt-project.org on
behalf of Blasche Alexander alexander.blas...@theqtcompany.com
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,
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 beginning. All
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 completely
On Sat, Jan 17, 2015 at 4:49 PM, Fanda Vacek fanda.va...@gmail.com 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
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 and
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
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 louai.al-kha...@theqtcompany.com
wrote:
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
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
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,
On Jan 18, 2015, at 10:24 PM, Kevin Kofler kevin.kof...@chello.at 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
On Jan 18, 2015, at 6:34 AM, Kevin Kofler kevin.kof...@chello.at 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
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:
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 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 somehow?
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
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 the tools must
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 rena...@gmail.com:
Hey guys,
I started to implement the class
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
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
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 the EFL
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).
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/
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
57 matches
Mail list logo