Re: [Development] QtContacts - New class QContactCollection

2015-01-19 Thread Milian Wolff
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

Re: [Development] QtContacts - New class QContactCollection

2015-01-19 Thread Matthew Vogt
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

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

2015-01-19 Thread Lisandro Damián Nicanor Pérez Meyer
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

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

2015-01-19 Thread Thiago Macieira
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

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

2015-01-19 Thread Thiago Macieira
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

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

2015-01-19 Thread Thiago Macieira
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

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

2015-01-19 Thread Thiago Macieira
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*

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

2015-01-19 Thread Lisandro Damián Nicanor Pérez Meyer
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)

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

2015-01-19 Thread Thiago Macieira
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

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

2015-01-19 Thread Thiago Macieira
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

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

2015-01-19 Thread Thiago Macieira
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

Re: [Development] forkfd help on OS X 10.7

2015-01-19 Thread Thiago Macieira
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 --

Re: [Development] optimizing QComposeInputContext / TableGenerator?

2015-01-19 Thread Milian Wolff
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

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

2015-01-19 Thread Kevin Kofler
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

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

2015-01-19 Thread Lisandro Damián Nicanor Pérez Meyer
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

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

2015-01-19 Thread Thiago Macieira
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

Re: [Development] QtContacts - New class QContactCollection

2015-01-19 Thread Chris Adams
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

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

2015-01-19 Thread Lisandro Damián Nicanor Pérez Meyer
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

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

2015-01-19 Thread Lisandro Damián Nicanor Pérez Meyer
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

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

2015-01-19 Thread Thiago Macieira
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

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

2015-01-19 Thread Thiago Macieira
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

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

2015-01-19 Thread Thiago Macieira
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

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

2015-01-19 Thread Thiago Macieira
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,

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

2015-01-19 Thread Thiago Macieira
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.

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

2015-01-19 Thread Lisandro Damián Nicanor Pérez Meyer
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

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

2015-01-19 Thread Kevin Kofler
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

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

2015-01-19 Thread Thiago Macieira
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

Re: [Development] optimizing QComposeInputContext / TableGenerator?

2015-01-19 Thread Kevin Kofler
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

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

2015-01-19 Thread Kevin Kofler
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

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

2015-01-19 Thread Lisandro Damián Nicanor Pérez Meyer
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

Re: [Development] JIRA broken

2015-01-19 Thread Blasche Alexander
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

Re: [Development] JIRA broken

2015-01-19 Thread Blasche Alexander
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

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

2015-01-19 Thread Al-Khanji Louai
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,

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

2015-01-19 Thread Harri Porten
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

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

2015-01-19 Thread Oswald Buddenhagen
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

Re: [Development] QTBUG-39477 - Enable QWidget based classes to be used in QML files

2015-01-19 Thread Mark Gaiser
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

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

2015-01-19 Thread Kevin Kofler
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

Re: [Development] Building Qt3D

2015-01-19 Thread Giuseppe D'Angelo
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

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

2015-01-19 Thread Keränen Pasi
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:

[Development] Building Qt3D

2015-01-19 Thread Ben Beckwith
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

Re: [Development] Android Serial Port USB device

2015-01-19 Thread Mike Goza
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

[Development] Under Windows QWindow receiving QExposeEvent on window drag.

2015-01-19 Thread Trent Reed
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,

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

2015-01-19 Thread Ziller Eike
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

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

2015-01-19 Thread Ziller Eike
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

Re: [Development] Under Windows QWindow receiving QExposeEvent on window drag.

2015-01-19 Thread Agocs Laszlo
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:

Re: [Development] optimizing QComposeInputContext / TableGenerator?

2015-01-19 Thread Thiago Macieira
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

[Development] optimizing QComposeInputContext / TableGenerator?

2015-01-19 Thread Milian Wolff
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

Re: [Development] optimizing QComposeInputContext / TableGenerator?

2015-01-19 Thread Olivier Goffart
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?

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

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

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

2015-01-19 Thread Lisandro Damián Nicanor Pérez Meyer
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

Re: [Development] QtContacts - New class QContactCollection

2015-01-19 Thread Konstantin Ritt
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

Re: [Development] QtContacts - New class QContactCollection

2015-01-19 Thread Renato Araujo
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

Re: [Development] optimizing QComposeInputContext / TableGenerator?

2015-01-19 Thread Paeglis Gatis
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

Re: [Development] optimizing QComposeInputContext / TableGenerator?

2015-01-19 Thread Thiago Macieira
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

Re: [Development] Android Serial Port USB device

2015-01-19 Thread Denis Shienkov
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).

Re: [Development] optimizing QComposeInputContext / TableGenerator?

2015-01-19 Thread Giuseppe D'Angelo
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/

[Development] QtContacts - New class QContactCollection

2015-01-19 Thread Renato Araujo
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