On 10/20/2012 01:06 AM, Thiago Macieira wrote:
> Here's we might do then:
>
> QT_INSTALL_BINS - remains as it is, points to (on distros) /usr/lib/qt5/bin,
> contains unrenamed executables.
>
> QT_INSTALL_SYSTEM_BINS - points to /usr/bin and contains qmake5 (at least).
> As
> I said, I don't ca
On Fri, Oct 19, 2012 at 3:37 PM, Knoll Lars wrote:
> This is just wrong, and I'm getting tired of your ramblings on this mailing
> list. Just because you send something to the ML and people get tired of
> answering you doesn't mean your proposal is accepted.
>
I was writing that tongue in cheek
/me puts his fingers in his ears in advance of the deafening roar of
volunteers to get dirty with this task.
I personally love seeing the death of this kind of cruft, but you
probably have better things to do with your time and it would be nice
to see Qt 5 out and frolicking in the fields, replete
On sexta-feira, 19 de outubro de 2012 16.16.14, Thiago Macieira wrote:
> 1) we introduce a $libexecdir configuration option to qmake and
> QLibraryInfo. For backwards compatibility, this $libexecdir will receive
> the legacy names of QT_INSTALL_BINS and QLibraryInfo::BinariesPath. It will
> defaul
On sábado, 20 de outubro de 2012 01.31.18, Pau Garcia i Quiles wrote:
> What's "-qt5" ? Latest Qt 5.x.y available? A shorthand for "qmake
> -qt=5.0.0"? Something else?
The latest available or some pre-configured alias. I was hoping to leave that
part for later, until I implement this tool.
My cur
On Sat, Oct 20, 2012 at 1:16 AM, Thiago Macieira
wrote:
> b) additionally, it accepts an extra argument (-select), which causes it
> to
> select a different Qt version. For example:
> qmake -qt=5 -project
> qmake -qt=4.8.4 CONFIG+=debug
> etc.
> As a shorthand, the optio
On sábado, 20 de outubro de 2012 08.38.20, Lorn Potter wrote:
> > The distros *will* apply renaming. And without our help, they may
> > introduce
> > bugs and they will be definitely deviating from the documented way.
>
> Then that's their problem, not qt-projects.
I don't see it that way and I do
Starting a new thread with some ideas based on the outcomes of the discussion.
Many thanks to rittk, Simon, Lars and André who helped come up with this.
Note: this applies to the *tools* only. The library naming and installation
paths for plugins and QML files has remained uncontested so far, so w
On 20/10/12 7:37 AM, Thiago Macieira wrote:
> On sábado, 20 de outubro de 2012 05.00.53, Lorn Potter wrote:
>> I won't add anything but my support for leaving it alone. Let the Linux
>> distributions solve their own problems, which they already have.
>
> Once again: the problem may have originated
On Oct 19, 2012, at 4:59 PM, d3fault wrote:
> I proposed it, therefore if nobody disagrees, I get consensus and the
> decision goes into effect. I'll quote myself in an earlier post to
> actually give this thread some substance:
This is just wrong, and I'm getting tired of your ramblings on thi
On sexta-feira, 19 de outubro de 2012 21.55.59, Knoll Lars wrote:
> > My only argument is that this directory of "old names" is not very useful.
> > Since we can't guarantee it will be on $PATH, we need to change all of our
> > documentation. So it serves only for us "old timers" who have lots of
>
On Oct 19, 2012, at 11:31 PM, Thiago Macieira
wrote:
> On sexta-feira, 19 de outubro de 2012 21.34.11, André Pönitz wrote:
>> The proposal to put all unrenamed binaries in a directory and set up
>> *5 links in /usr/bin to those unmodified binaries was on the table.
>>
>> I haven't seen any rea
On sexta-feira, 19 de outubro de 2012 22.18.25, Shawn Rutledge wrote:
> So pos is bad because it's abbreviated. And I suspect we may have
> problems with renaming windowState to state, because in QML that
> usually refers to the state-machine state (driving animated
> transitions etc.) Should we
On sábado, 20 de outubro de 2012 05.00.53, Lorn Potter wrote:
> I won't add anything but my support for leaving it alone. Let the Linux
> distributions solve their own problems, which they already have.
Once again: the problem may have originated with the distros and their rules,
but that affects
On sexta-feira, 19 de outubro de 2012 19.32.05, Laszlo Papp wrote:
> I have not personally been much fan of that schema... Thiago, I hope
> your next proposal will not be qmake5.0, qmake5.1 and the like based
> upon some "python precedence".
Even though python does install python3.2 and python3.3,
On sexta-feira, 19 de outubro de 2012 21.34.11, André Pönitz wrote:
> The proposal to put all unrenamed binaries in a directory and set up
> *5 links in /usr/bin to those unmodified binaries was on the table.
>
> I haven't seen any reasoning that this is unusable as "proper solution".
It is a solu
On Fri, Oct 19, 2012 at 08:02:46PM +, Sune Vuorela wrote:
> On 2012-10-19, André Pönitz wrote:
> >> Really. I really want, both as a Qt contributor and a Qt packager to
> >> ship a pristine Qt. Please help me make it happen.
>
> > Demanding to be relieved from that burden is one thing. Demand
> Distros would configure Qt with -prefix /usr -bindir /usr/lib/qt5/libexec etc.
Let's make it more flexible for those who will configure:
I'd rather -prefix /usr -bindir /usr/bin -libexecdir /usr/lib/qt5/libexec
since /usr/bin is still an important path where one would expect to
find some scripts
On 19 October 2012 21:56, Oswald Buddenhagen
wrote:
> On Fri, Oct 19, 2012 at 04:46:01PM +, Rutledge Shawn wrote:
>> QWindow has properties like windowTitle, windowIcon, windowModality,
>> windowState and so on, which are named that way to be familiar to users of
>> QWidget.
>>
> correct. ht
On 2012-10-19, André Pönitz wrote:
>> Really. I really want, both as a Qt contributor and a Qt packager to
>> ship a pristine Qt. Please help me make it happen.
> Demanding to be relieved from that burden is one thing. Demanding to
> use an approach that will break thousands of other projects is
On Fri, Oct 19, 2012 at 04:46:01PM +, Rutledge Shawn wrote:
> QWindow has properties like windowTitle, windowIcon, windowModality,
> windowState and so on, which are named that way to be familiar to users of
> QWidget.
>
correct. http://doc.qt.digia.com/qq/qq13-apis.html#theartofnaming ,
"gen
On Fri, Oct 19, 2012 at 05:32:43PM +, Sune Vuorela wrote:
> On 2012-10-19, Oswald Buddenhagen wrote:
> >> I have, as a distributor, frequently gotten 'hate' in #qt for providing
> >> switchable qmakes.
> >>
> > using (debian style) altenatives for that is pretty stupid.
>
> I guess that prov
On 19/10/12 19:27, Poenitz Andre wrote:
> I started -2'ing the changes, based on the outcome of a cost/benefit
> "analysis":
thank you.
--
Lorn Potter
Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo
___
Development mailing list
Dev
On 19/10/12 21:24, Simon Hausmann wrote:
> (3) This leaves us with the command line tools such as qmake, moc and uic
> where we have a conflict_only_ on Linux when they're installed by
> distributions in /usr/bin.
>
> In short: We find that there is no_need_ to rename the tools and that we can
>
On Fri, Oct 19, 2012 at 7:13 PM, Thiago Macieira
wrote:
> On sexta-feira, 19 de outubro de 2012 13.24.37, Simon Hausmann wrote:
>> Regardless of the solution we find for Qt distro packages, it seems
>> sensible that the Qt users can continue to find a /usr/bin/qmake program
>> that corresponds to
Mathematical Truth:
It is better:
To be vulnerable and know it (so you can shut down your machine or
unplug dat ethernet cable).
Than:
To be vulnerable and not know it (especially when there's a growing
number of others that do).
d3fault
___
Developmen
On sexta-feira, 19 de outubro de 2012 13.24.37, Simon Hausmann wrote:
> Regardless of the solution we find for Qt distro packages, it seems
> sensible that the Qt users can continue to find a /usr/bin/qmake program
> that corresponds to the most recent release of Qt. This provides
> consistency wi
my +1 to renaming (didn't review the patches, though)
Konstantin
2012/10/19 Samuel Rødal :
> On 10/19/2012 06:46 PM, Rutledge Shawn wrote:
>> QWindow has properties like windowTitle, windowIcon, windowModality,
>> windowState and so on, which are named that way to be familiar to users of
>> QW
On 10/19/2012 06:46 PM, Rutledge Shawn wrote:
> QWindow has properties like windowTitle, windowIcon, windowModality,
> windowState and so on, which are named that way to be familiar to users of
> QWidget. However it causes some silliness in Qt Quick: QQuickWindow inherits
> QWindow, and that me
On 2012-10-19, Oswald Buddenhagen wrote:
>> I have, as a distributor, frequently gotten 'hate' in #qt for providing
>> switchable qmakes.
>>
> using (debian style) altenatives for that is pretty stupid.
I guess that proves my point quite good...
> as i've already written about three times, this
On sexta-feira, 19 de outubro de 2012 07.31.21, Knoll Lars wrote:
> > qdbusxml2cpp -> qdbusxml2cpp5
> > qdbuscpp2xml -> qdbuscpp2xml5
>
> Do we need to rename the dbus tools? They are compatible afaik.
Slightly... There's one change, which is the change on the annotations from
"com.t
On 2012-10-19, Poenitz Andre wrote:
> User support could then be:
>
> "write qmake5 to build Qt 5 things"
no. it would be "if you compiled Qt yourself or if you downloaded the
built editions from digia, write qmake to build things. if you gotten
from your linux distribution write probably
qma
On sexta-feira, 19 de outubro de 2012 08.52.47, Ziller Eike wrote:
> > External tooling will need to deal with the new names.
>
> I don't see why.
> It's possible to ask qmake for the path where the other binaries, headers,
> examples, and a lot of other stuff are supposed to be: "qmake -query". I
On sexta-feira, 19 de outubro de 2012 09.27.42, Poenitz Andre wrote:
> - The "problem" only exists on Linux
>* There are existing, working solutions to the "problem" there
>* There are skilled people (distro packagers) there perfectly
> capable of handling the "problem"
>* The
On sexta-feira, 19 de outubro de 2012 08.47.08, Ziller Eike wrote:
> Another thing that comes to my mind, that will break when renaming tools,
> instead of installing links in paths like "/usr/bin" and keeping the the
> tools unrenamed in specific version directories:
>
> At the moment one can def
On sexta-feira, 19 de outubro de 2012 07.45.15, Koehne Kai wrote:
> I guess the reason is that there's already a qmlviewer - the Qt 4 one. If we
> also go with qmlscene ->qml2viewer, we'd have
>
> qmlviewer -> qt4
> qml1viewer -> Qt 5, Qt Quick 1
> qml2viewer -> Qt 5, Qt Quick 2
>
> Not exactly
On Fri, Oct 19, 2012 at 9:48 AM, Alexis Menard wrote:
> First you should let more than a day for people to answer.
>
Waited 11 days in the other thread...
> Secondly I disagree with your statement and using the same link
> (Debian) you sent let me quote something else :
>
> "A: Once the security
On 19 October 2012 17:48, Alexis Menard wrote:
>
> Hi,
>
> First you should let more than a day for people to answer.
>
> Secondly I disagree with your statement and using the same link
> (Debian) you sent let me quote something else :
And to add a proper reference other than the FAQ, the Debian
On sexta-feira, 19 de outubro de 2012 07.09.40, Koehne Kai wrote:
> So, _if_ we already rename half of the tools I don't see why qmlplugindump +
> qmlviewer should be the exception. Same goes for qmlviewer. Designer is a
> bit different since I guess 90% of the people just use it with stock
> compo
On sexta-feira, 19 de outubro de 2012 11.54.36, Joerg Bornemann wrote:
> On 18/10/2012 19:09, Thiago Macieira wrote:
> > Let me be very clear: the distributions aren't fixing the distribution's
> > problem. They'd be fixing *ours*.
>
> Putting every binary into one directory excludes installing di
On sexta-feira, 19 de outubro de 2012 08.33.28, Ziller Eike wrote:
> Do we have a libraries-only install for Qt5? I have only heard of SDK
> installers yet. We had something in that direction for Qt4, but actually I
> think it's a bad idea, as I already outlined in previous discussions (even
> Xcod
On Fri, Oct 19, 2012 at 11:59 AM, d3fault wrote:
> I proposed it, therefore if nobody disagrees, I get consensus and the
> decision goes into effect. I'll quote myself in an earlier post to
> actually give this thread some substance:
Hi,
First you should let more than a day for people to answer.
QWindow has properties like windowTitle, windowIcon, windowModality,
windowState and so on, which are named that way to be familiar to users of
QWidget. However it causes some silliness in Qt Quick: QQuickWindow inherits
QWindow, and that means it inherits those properties too (even though they
Are you willing to put the security of your operations in the hands of
all the wives and children who might have access to their dad's
computer (he being a member of that trusted network of analysts)?
Humans can be bought/persuaded/compromised/etc with ease.
l2security
d3fault
___
How long does it usually take to receive this massage? I've got some tenseness
in my neck that's been bothering me.
On Friday, October 19, 2012 04:38:29 AM Roseline Thompson wrote:
>From Mrs Roseline Thompson,
Rue 6 Lot 12 Cocody
Cote d'Ivoire
Dearest in Christ,
Greetings in the name of our
On Fri, Oct 19, 2012 at 8:27 AM, Oswald Buddenhagen
wrote:
> google "responsible disclosure"
No need, and that's hardly an argument. What if I said: google "full
disclosure" as my counter-argument?
So anyways I'll bite, even though we've already been over this.
Responsible disclosure is very si
On 19.10.2012, at 16:55, d3fault wrote:
> On Fri, Oct 19, 2012 at 1:08 AM, André Somers wrote:
>> You may not agree with the decision
>> taken, but the grown-up thing to do is to accept that and move on.
>
> Tell that to the Jews who were forced to go to the holocaust.
Now that this thread has
On Fri, Oct 19, 2012 at 07:55:52AM -0700, d3fault wrote:
> Anybody want to respond telling me why they think full disclosure is
> worse than behind closed doors security?
>
google "responsible disclosure"
___
Development mailing list
Development@qt-proje
I closed the bug, and shortly after, re-opened it. Closing a bug is not an
irreversible action. If the reporter disagrees with the closure - which is not
unusual, considering the inherent difficulty of reproducing some bugs, the lack
of information provided in some reports or the occasional mist
I proposed it, therefore if nobody disagrees, I get consensus and the
decision goes into effect. I'll quote myself in an earlier post to
actually give this thread some substance:
On Thu, Oct 18, 2012 at 3:40 PM, d3fault wrote:
> tl;dr:
> Open Project
> Closed Security
>
> The officially endorsed
On Fri, Oct 19, 2012 at 1:08 AM, André Somers wrote:
>You may not agree with the decision
> taken, but the grown-up thing to do is to accept that and move on.
Tell that to the Jews who were forced to go to the holocaust.
>Please focus your energy on more productive ventures.
...so you're saying
thanksAndré, it should be the default style
http://dooble.svn.sourceforge.net/viewvc/dooble/trunk/browser/Source/dtabwidget.cc?revision=4784&view=markup
http://dooble.svn.sourceforge.net/viewvc/dooble/trunk/browser/Source/dtabwidget.cc?revision=4755&view=markup
though it could be manually defined,
On Fri, Oct 19, 2012 at 03:01:05PM +0200, Simon Hausmann wrote:
> Wouldn't it be kind of weird though if the libQtCore.so symlink would live in
> say /usr/lib/qt5/lib but libQtCore.so.5.0.0 itself would be locacted in
> /usr/lib?
>
no, because libQtCore.so.5.0.0 would also live in /usr/lib/qt5/
On Friday, October 19, 2012 02:24:09 PM Oswald Buddenhagen wrote:
> On Fri, Oct 19, 2012 at 01:24:37PM +0200, Simon Hausmann wrote:
> > (1) It seems that there is an agreement on the naming of the libraries and
> > pkg-config files.
>
> not really. i'm not as strongly opposed to it as to renaming
On Fri, October 19, 2012 09:14:39 AM Chris Adams wrote:
> On Fri, Oct 19, 2012 at 2:06 AM, Jon Trulson wrote:
> > On Tue, 16 Oct 2012, Thiago Macieira wrote:
> > On terça-feira, 16 de outubro de 2012 15.25.40, Jon Trulson wrote:
> >>> However, compiling qtwayland fails with many errors - errors t
On Fri, Oct 19, 2012 at 01:24:37PM +0200, Simon Hausmann wrote:
> (1) It seems that there is an agreement on the naming of the libraries and
> pkg-config files.
>
not really. i'm not as strongly opposed to it as to renaming the tools,
but i think renaming the libraries is mostly counterproductive
On 19 October 2012 12:29, Oswald Buddenhagen
wrote:
> On Fri, Oct 19, 2012 at 11:00:04AM +, Sune Vuorela wrote:
>> On 2012-10-19, Alberto Mardegan wrote:
>> > 3) Provide a script to switch, per user and maybe even per $PWD, what
>> > version of Qt /usr/bin/qmake should generate the makefiles
Sune Vuorela [nos...@vuorela.dk]
> I have, as a distributor, frequently gotten 'hate' in #qt for providing
> switchable qmakes.
> And from a 'user support' PoV, having to write "depending on what you
> have set as your default you can maybe write qmake, maybe you need to
> oither switch the defau
> as i've already written about three times, this is an argument for you
> guys finally agreeing on something and actually sticking to it, not
> upstream forcing this change on *all* users.
I fully agree.
Laszlo
___
Development mailing list
Development@
On Friday 19 October 2012 13:09:15 Martin Koller wrote:
> Hi,
>
> I wanted to clone the Qt5 repo according to
> http://qt-project.org/wiki/Building-Qt-5-from-Git
>
> and get:
>
> git clone https://git.gitorious.org/qt/qt5.git qt5
> Cloning into qt5...
> warning: remote HEAD refers to nonexistent
On Fri, Oct 19, 2012 at 11:00:04AM +, Sune Vuorela wrote:
> On 2012-10-19, Alberto Mardegan wrote:
> > 3) Provide a script to switch, per user and maybe even per $PWD, what
> > version of Qt /usr/bin/qmake should generate the makefiles for.
>
> I have, as a distributor, frequently gotten 'hat
On Thursday, October 18, 2012 08:30:03 AM Thiago Macieira wrote:
[...]
Tor Arne and I have been discussing this once more and we'd like to make an
alternative proposal. But first let's try to summarize.
(1) It seems that there is an agreement on the naming of the libraries and
pkg-config files.
Hi,
I wanted to clone the Qt5 repo according to
http://qt-project.org/wiki/Building-Qt-5-from-Git
and get:
git clone https://git.gitorious.org/qt/qt5.git qt5
Cloning into qt5...
warning: remote HEAD refers to nonexistent ref, unable to checkout.
should I be worried about this ?
--
Best regard
On Thursday, 2012-10-18, Shawn Rutledge wrote:
> I have another idea in mind for qmlviewer...
>
> You can configure your system so that double-clicking a .qml file opens it
> in qmlviewer. This would be a nice use case to suggest/support, because
> it's silly to be required to write a boilerplate
On 2012-10-19, Alberto Mardegan wrote:
> 3) Provide a script to switch, per user and maybe even per $PWD, what
> version of Qt /usr/bin/qmake should generate the makefiles for.
I have, as a distributor, frequently gotten 'hate' in #qt for providing
switchable qmakes.
And from a 'user support' P
Sorvig Morten wrote:
> Knoll Lars wrote:
> > Hi,
> >
> > looks like there's quite some discussion about Thiago's proposal.
> > Let's see if we can get at least agreement on most of the changes
> > and then focus on the parts that are controversial.
>
> To me this looks like a case where there c
On 18/10/2012 19:09, Thiago Macieira wrote:
> Let me be very clear: the distributions aren't fixing the distribution's
> problem. They'd be fixing *ours*.
Putting every binary into one directory excludes installing different
versions of one binary. Obviously the coinstallation problem is unsolve
On 10/19/2012 10:31 AM, Knoll Lars wrote:
> Unfortunately qmake is bound to the Qt version and not backwards compatible.
> So if we want to make it possible to co-install Qt 5 with Qt 4, we have very
> little choice but to rename it.
This is not entirely true. Surely at any given time /usr/bin/q
Thiago Macieira:
> On sexta-feira, 19 de outubro de 2012 06.07.34, Kalinowski Maurice wrote:
> > On Windows there is no global qmake or such to call and distinguish between
> > versions. Each Qt version will have to live in its own package, either made
> > by the binary distribution or self-compile
May I ask some stupid question: how many different qmake-s you're need
in your $PATH ?!
Maybe it's only me? - on Windows I do have a directory per Qt build,
on Linux I do have symlink /user/bin/qmake ->
/usr/opt/Qt/4.8/bin/qmake. And I never have a feeling I need few more
qmake-s around!
2012/10/
> -Original Message-
> From: development-bounces+jan-arve.saether=digia@qt-project.org
> [mailto:development-bounces+jan-arve.saether=digia@qt-project.org]
> On Behalf Of Simon Hausmann
> Sent: 18. oktober 2012 16:42
> To: development@qt-project.org
> Cc: Thiago Macieira
> Subject:
On 19 Oct 2012, at 02:37, Thiago Macieira wrote:
> On sexta-feira, 19 de outubro de 2012 10.17.39, Lincoln Ramsay wrote:
>> On 19/10/12 01:30, Thiago Macieira wrote:
>>> After all of my patches are integrated, here are the changes that will
>>> happen:
>>>
>>> - bin:
>>
>>> The following tools
Another thing that comes to my mind, that will break when renaming tools,
instead of installing links in paths like "/usr/bin" and keeping the the tools
unrenamed in specific version directories:
At the moment one can define an "external tool" in Qt Creator.
Configuration of these external tools
On Fri, 19 Oct 2012 07:57:05 +, Uwe Rathmann wrote:
> Well, use cases for cosmetic pens also exist for Qwt,...
Of course I meant "use cases for non-cosmetic pens".
Uwe
___
Development mailing list
Development@qt-project.org
http://lists.qt-projec
On 18 Oct 2012, at 20:26, Thiago Macieira wrote:
> On quinta-feira, 18 de outubro de 2012 18.05.31, Ziller Eike wrote:
>> I'd throw Mac out of sentences that have Linux in them in this discussion:
>> There are no "Mac" distributions/distributors that package Qt
>
> There's MacPorts.
We really
Op 19-10-2012 3:50, slfj sfjie schreef:
Also, the guy didn't even disagree with me. He pretty much reiterated
the first post and said absolutely nothing. You disagreed with me for
a little bit (CVE/Mitre), but getting around those problems is trivial
by setting up a security-priv...@qt-proje
> looks like there's quite some discussion about Thiago's proposal. Let's see if
> we can get at least agreement on most of the changes and then focus on the
> parts that are controversial.
>
> Going through the list below, most of the changes will not affect anybody in a
> big way.
>
>
> On Oct
On Oct 19, 2012, at 9:51 AM, Sorvig Morten wrote:
> On Oct 19, 2012, at 9:31 AM, Knoll Lars wrote:
>
>> Hi,
>>
>> looks like there's quite some discussion about Thiago's proposal. Let's see
>> if we can get at least agreement on most of the changes and then focus on
>> the parts that are cont
On Thu, 18 Oct 2012 09:08:30 +, Bache-Wiig Jens wrote:
> We keeping the explicit 0-pen
> working as before. In addition, we introduce a CosmeticPenByDefault
> render hint that Qwt can set on its painter to make all pens cosmetic
> by default. (not just 0-pen)
Well, use cases for cosmetic pe
On Oct 19, 2012, at 9:31 AM, Knoll Lars wrote:
> Hi,
>
> looks like there's quite some discussion about Thiago's proposal. Let's see
> if we can get at least agreement on most of the changes and then focus on the
> parts that are controversial.
To me this looks like a case where there clearl
> -Original Message-
> From: development-bounces+kai.koehne=digia@qt-project.org
> [mailto:development-bounces+kai.koehne=digia@qt-project.org] On
> Behalf Of Jana Aurindam
> Sent: Thursday, October 18, 2012 7:15 PM
> To: Thiago Macieira
> Cc:
> Subject: Re: [Development] Summary o
Op 18-10-2012 19:36, Randolph D. schreef:
> Hello
>
> in the tab widget several tabs have a background colour of dark-grey
> and the active forground tab has the background colour of light-grey.
>
> This is misleading, as all apps with a mainframe have the colour of
> light grey, so the active ta
Hi,
looks like there's quite some discussion about Thiago's proposal. Let's see if
we can get at least agreement on most of the changes and then focus on the
parts that are controversial.
Going through the list below, most of the changes will not affect anybody in a
big way.
On Oct 18, 2012
> -Original Message-
> From: development-bounces+kai.koehne=digia@qt-project.org
> [mailto:development-bounces+kai.koehne=digia@qt-project.org] On
> Behalf Of Thiago Macieira
> Sent: Thursday, October 18, 2012 7:31 PM
> To: development@qt-project.org
> Subject: Re: [Development] Sum
84 matches
Mail list logo
