Re: [Development] Summary of renaming changes

[Alberto Mardegan]

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 care if this is the main executable or a symlink to something 
> else, as long as it exists, works and is official.
> 
> Please note that we cannot expect QT_INSTALL_BINS to be in $PATH, so we need 
> to change the documentation anyway. Either we point to the executables with 
> their new and global names, or we document how to find them.

\o/

As you mentioned in another message, it would be great if these paths
were discoverable, either with a qt5-config tool or (better, IMHO) with
a qt5.pc pkg-config file defining these variables, so that one could do:

$ pkg-config --variable=QT_INSTALL_BINS qt5
/usr/lib/qt5/bin


Ciao,
  Alberto

-- 
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

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 and mocking Thiago. Sarcasm > You.

> We have a fully worked out proposal by Rich on the table that many people 
> agreed with, and we'll stick with it for now.
>

His proposal is alright, with the exception of handling incoming
vulnerabilities. He didn't even discuss the subject, so what do you
even mean sticking with it?

> Lars

I'd expect more from you, being the Chief Maintainer of the project
and all. What a worthless post. You didn't even attempt to tackle my
argument.

Speaking of which, if ANYBODY can defeat it, I'll shut up here and now.



Ok noobs, you leave me no choice. Just like when someone doesn't
believe a specific vulnerability is legit, I guess I have to prove it
with an actual exploit. So I'll be ditching this alias and creating a
new one. Unlike the provingapoint12345 puppet, it will appear entirely
real (hurr I can use tor etc you morons (TAILs means any 5 year old
can)). I will stop being mean to people, and I'll even contribute
random bug fixes or other small contributions just to earn merit.
Thiago has already indicated that it's pretty easy for someone to join
Qt's security team. So after I get in, I'll be secretly publishing all
the reports to cracker circles around the globe.

Guess your only counter is to never let anybody else join the security
team. Good security policy you got there. Sholy Hit I'm surrounded by
retards.

Anonymous

...rejoice that I am leaving, but know that I am here in the shadows
watching you [mas7urba7e] from a distance...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Porting exported qt_[win|mac|x11] functions Qt 5.

[Donald Carr]

/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 with dingle
berries like these if need be.

You might need to kill the from_pascal_string convenience function out
of honor. This kind of thing is growing increasingly popular in Norway
these days, no?

On Thu, Oct 18, 2012 at 1:07 AM, Sorvig Morten  wrote:
> According to git grep Qt 4 has 47 semi-public exported "qt_platform" 
> functions offering platform-spesific functionality. Most platform code is now 
> in plugins and can no longer export symbols. We need a plan for dealing with 
> these in Qt 5.
>
> After a brief investigation these fall into several categories (some are in 
> more than one category):
>
> - helper functions for other parts of Qt (qt_win_display_dc?)
> - utility functions (qt_mac_execute_apple_script, qt_mac_secure_keyboard)
> - access to Qt platform internals (qt_mac_nativeview_for)
> - obsolete (qt_mac_from_pascal_string)
> - strange (qt_mac_resolve_sys which just calls dlsym)
>
> Proposed solution 0) Ignore the problem for Qt 5.0.
>
> Proposed solution 1) Fix it:
>
> - Remove/don't port obsolete functions (we can add them back later if it was 
> a mistake)
> - Add to QPA where it makes sense. The QPlatformNativeInterface subclasses 
> already gives access to may platform internal objects.
> - Public compatibility API goes int the platform extras modules. Many of the 
> utility functions can be implemented here as well.
> - Create "extras" modules for all platforms (we currently have qtmacextras in 
> the Qt playground)
> - Add the extras modules to the default Qt 5 distribution.
>
> Given the current workload and schedule solution 0) is actually tempting, at 
> least for me. Releasing 5.0 with missing functions will perhaps tell us which 
> ones are in use.
>
> Does anyone want to pick this up?
>
> Morten
>
>
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New proposal for the tool naming

[Thiago Macieira]

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
> default to $prefix/libexec/qt5, which some distros will change to
> $prefix/lib/qt5/libexec.

Change of idea: this should default to $libdir/qt5/libexec and Linux distros 
are under strict recommendations *not* to change it.

Why? Because this directory contains tools that are arch-dependent. The 64-bit 
qmlplugindump cannot be used with 32-bit plugins.

Unless distros have a suggestion for how to deal with this.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New proposal for the tool naming

[Thiago Macieira]

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 current idea is to have this tool backed by multiple files, stored in
/etc/xdg/qmake and ~/.config/qmake. Therefore, the "5" version might be a
symlink to another file.

This also allows distributions to install and remove multiple Qt versions by
just dropping the file in or taking it out.

> Also, why not use pkg-config --list-all and simply look for everything
> called "libqt-x.y.z" or alike? (I know, I know, no external dependencies is
> an advantage and this new qmake is very easy to implement but still...)

Because:
a) I don't want to depend on pkg-config
b) that's not what pkg-config was designed for
c) that requires installing one more .pc file, in addition to the ones we have
d) the location of this pkg-config install is most likely *different* from
$libdir/pkgconfig.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New proposal for the tool naming

[Pau Garcia i Quiles]

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 option "-qtX" means "-qt=X".
>  This argument will be stripped from the command-line before calling the
> real
> qmake.
>  Without this option, it will fall back to a well-known environment
> variable
> (say, QT_SELECT=5). And if that is also missing, it selects some
> system-defined
> or user-defined default.
>
> [..]


>  In turn, the official Qt 5 documentation should always talk about qmake
> like
> so:
> qmake -qt5 "LIBS+=-L/usr/local/lib -lmysqlclient_r" mysql.pro
>

What's "-qt5" ? Latest Qt 5.x.y available? A shorthand for "qmake
-qt=5.0.0"? Something else?

Also, why not use pkg-config --list-all and simply look for everything
called "libqt-x.y.z" or alike? (I know, I know, no external dependencies is
an advantage and this new qmake is very easy to implement but still...)

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Alternative Proposal

[Thiago Macieira]

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 don't think our users will think it that way
either. If they follow the documentation from qt-project.org/doc and it
doesn't work, they'll blame us, not the middle-man.

> This is only one platform that this effects, and only under certain
> conditions.

It's technically all Unix apart from Mac OS X, even though we seem to care
very little about any of them besides Linux. And it's the condition that most
people will see Qt installed at, since the distributions are probably our
largest vehicle of distribution. (True, though, the overwhelming majority
won't be developers)

> We didn't need to rename commands going from qt2 ->qt3, nor from qt3 ->qt4.

Qt 2 had no qmake. It still used tmake. I don't remember how distros dealt
with moc's name. As for the library name, it changed from libqt.so to libqt-
mt.so.

>From qt3 to qt4, there was definitely trouble. That's why qmake-qt3 and qmake-
qt4 exist today, despite being largely ignored by the upstream developers
(us). Every now and then, someone comes into the #qt channel and says their
application can't compile because QApplication wasn't found. When we look at
the output, we see:
-I/usr/include/qt-3.3

So don't tell me that we didn't need to rename. We needed to, we just failed
to do it.

> Personally I don't think there is a problem. With the name change comes
> heaps of problems on the other platforms. Less problems wins.
>
> Personally I think it's a big waste of time, and too big of change to be
> done now. This feature should have to wait until qt 6.

Only if we scrap Qt 5 now and start working on Qt 6. I still have those
container changes applied to my branch, you know :-)

> First and foremost, where's the bug reports from linux distros that need
> this change, or is the problem made up?

Go back to the beginning of the discussion. I linked to a bug report by the
Fedora packagers.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] New proposal for the tool naming

[Thiago Macieira]

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 we appear
to have a consensus.

The proposal:

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 default to
$prefix/libexec/qt5, which some distros will change to $prefix/lib/qt5/libexec.

This directory is *not* expected to be in $PATH on any system and therefore
the documentation cannot assume it is.

In this directory, we'll install the tools not usually run by the user, tools
that are often run by other tools. They will keep their current names. These
tools are:
qmake
moc
rcc
uic
qdbusxml2cpp
qdbuscpp2xml
lconvert
lrelease
lupdate
qml*
qhelpgenerator
qhelpconverter
qcollectiongenerator
qdoc

2) the $bindir, defaulting to $prefix/bin, will now be found by qmake property
QT_INSTALL_APPS and QLibraryInfo::ApplicationsPath. It contains end-user
applications that retain backwards compatibility of purpose as well as output.
Those applications are:
qdbus
qdbusviewer
designer
assistant
linguist
qglinfo
pixeltool
[creator]

I'm open to suggestions on whether some of the tools should be symlinked here
(e.g., qmlscene5 -> $libexecdir/qmlscene).

3) In addition, we'll create a *new* tool also called qmake that will be
installed to $bindir. This tool shall have the following behaviours:

 a) under most circumstances, it will simply find another qmake and pass
through all arguments. That is:
qmake -project
basically will exec
$someotherpath/qmake -project

 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+Þbug
etc.
 As a shorthand, the option "-qtX" means "-qt=X".
 This argument will be stripped from the command-line before calling the real
qmake.
 Without this option, it will fall back to a well-known environment variable
(say, QT_SELECT=5). And if that is also missing, it selects some system-defined
or user-defined default.

 c) it adds one extra option: -print-versions, which will list which Qt
versions are known to this tool

 It is our intention that this new tool replace all pre-existing qmake found
in $PATH. One tool to rule them all. Creator can query this tool to find all
known Qt versions and populate its listing.

 In turn, the official Qt 5 documentation should always talk about qmake like
so:
qmake -qt5 "LIBS+=-L/usr/local/lib -lmysqlclient_r" mysql.pro

This allows the Troll qset function to be implemented like:
function qset() {
local prefix=$(qmake -qt=$1 -query QT_INSTALL_PREFIX)
if [ $? -gt 0 ]; then
echo >&2 No such Qt version "$1"
else
export QT_SELECT=$1
export QTDIR=$prefix
local libdir=$(qmake -query QT_INSTALL_LIBS)
export 
LD_LIBRARY_PATH=$libdir${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH)
export PKG_CONFIG_PATH=$libdir/pkgconfig:$PKG_CONFIG_PATH
# optional:
#PATH=$(qmake -query QT_INSTALL_BINS):$PATH
fi
}
function qcd() { cd $QTDIR; }

Additionally, this tool may support options like -add-qt and -set-default-qt.
I'm also open to adding an option -run-tool= (e.g., qmake -qt=5 -run-
tool=qmlplugindump) if that's of interest to people.

I haven't decided whether this tool should be a shell script, a perl script or
another bootstrapped executable.

Please comment.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Alternative Proposal

[Lorn Potter]

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 with the distros and their rules,
> but that affects *us* and our *users*.
>
> 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.

This is only one platform that this effects, and only under certain 
conditions.

We didn't need to rename commands going from qt2 ->qt3, nor from qt3 ->qt4.
Personally I don't think there is a problem. With the name change comes 
heaps of problems on the other platforms. Less problems wins.

Personally I think it's a big waste of time, and too big of change to be 
done now. This feature should have to wait until qt 6.

First and foremost, where's the bug reports from linux distros that need 
this change, or is the problem made up?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[Knoll Lars]

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 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.

We have a fully worked out proposal by Rich on the table that many people 
agreed with, and we'll stick with it for now.

Lars

> 
> On Thu, Oct 18, 2012 at 3:40 PM, d3fault  wrote:
>> tl;dr:
>> Open Project
>> Closed Security
>> 
>> The officially endorsed method for reporting security issues for Qt is
>> to send them to secur...@qt-project.org , which is a private mailing
>> list. I have a problem with that.
>> 
>> "Experience has shown that 'security through obscurity' does not work.
>> Public disclosure allows for more rapid and better solutions to
>> security problems" ( http://www.debian.org/security/ ).
>> 
>> "Security information moves very fast in cracker circles. On the other
>> hand, our experience is that coding and releasing of proper security
>> fixes typically requires about an hour of work -- very fast fix
>> turnaround is possible. Thus we think that full disclosure helps the
>> people who really care about security" (
>> http://openbsd.org/security.html ).
>> 
>> If the Qt Project does not intend on taking security issues seriously,
>> then we should remove security related classes from the project
>> (QSslSocket namely). Leaving them in is misleading.
>> 
>> d3fault
> 
> d3fault
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Summary of renaming changes

[Thiago Macieira]

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
> > muscle memory, but who are usually the most capable in creating shell
> > aliases.
>
> There were some other arguments saying that this will also make our life
> easier on the tooling side, as e.g. creator relies on these names
> currently. If not we'll need a lot of magic in creator to figure out the
> name of the tool depending on the Qt version being used. This probably
> makes adding a Qt 4 target to Qt Creator later on a lot easier.

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 care if this is the main executable or a symlink to something 
else, as long as it exists, works and is official.

Please note that we cannot expect QT_INSTALL_BINS to be in $PATH, so we need 
to change the documentation anyway. Either we point to the executables with 
their new and global names, or we document how to find them.
 
> > But I'll happily implement those changes if it helps!
> 
> It sounds like it will be more easy to accept for most people here. And it
> actually helps with all the Qt developers that will have to deal with Qt 4
> and Qt5 builds in different directories.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Knoll Lars]

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 reasoning that this is unusable as "proper solution".
> 
> It is a solution. We can very well do that.
> 
> 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 muscle 
> memory, but who are usually the most capable in creating shell aliases.

There were some other arguments saying that this will also make our life easier 
on the tooling side, as e.g. creator relies on these names currently. If not 
we'll need a lot of magic in creator to figure out the name of the tool 
depending on the Qt version being used. This probably makes adding a Qt 4 
target to Qt Creator later on a lot easier.

> But I'll happily implement those changes if it helps!

It sounds like it will be more easy to accept for most people here. And it 
actually helps with all the Qt developers that will have to deal with Qt 4 and 
Qt5 builds in different directories.

Cheers,
Lars

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

Re: [Development] renaming all QWindow properties that have "window" in them

[Thiago Macieira]

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 be inconsistent and leave that one as
> windowState then?

The name "state" is also very generic, so that's a candidate for not being 
used. We need descriptive names that convey meaning and aren't ambiguous. That 
one doesn't fit the bill. For example, QAbstractSocket has a state() property 
that returns an enum of type SocketStatus. To be honest, socketState() might 
have made more sense, as QSslSocket later overloads that with the "encryption 
state".

Whether the other ones like "title" make sense without the "window" prefix, you 
need to decide. Is it unambiguous what that title is referring to? How about 
the modality? Do people usually refer to it as the "window modality"? Food for 
thought.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Alternative Proposal

[Thiago Macieira]

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 *us* and our *users*.

The distros *will* apply renaming. And without our help, they may introduce
bugs and they will be definitely deviating from the documented way.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)

[Thiago Macieira]

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, the name that people 
run is "python3", as seen in many scripts:

#!/usr/bin/env python3

So I really don't care if we have qmake5.0, qmake5.1, qmake5.1.2-digia3, so 
long as there's a qmake5 that works and is the official way.


Really, I don't care what qmake5 is and where it points to, so long as:
 a) it exists
 b) it works
 c) it's the official and documented way of creating Qt applications in Qt 5

Any other names are under the customer's taste.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Thiago Macieira]

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 solution. We can very well do that.

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 muscle
memory, but who are usually the most capable in creating shell aliases.

But I'll happily implement those changes if it helps!

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[André Pönitz]

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. Demanding to
> > use an approach that will break thousands of other projects is a
> > different one. It is unreasonable.
> 
> I am a bit saddened by this paragraph. I'm not demanding anything. I'm
> *explaining* my situation *hoping* that we can do something.

Sorry if this came out more personal than it was intended. 
 
> I could also be *begging* if *you* would prefer that, but I wouldn't
> expet that.

I don't expect or want begging. It would be sufficient if proposals
that clearly increase total pain when taking all users into account
would not need to be discussed.


> [...]
> Oh. btw, whattabout a solution with all tools having a 5 suffixed in
> /usr/bin and then creating a symlink farm somewhere with unversioned
> tools for people who has special needs?

The solution "out-of-path-dir-with-binaries + links" allows an
arbitrary number of fully functional Qt builds being present,
not just for major versions, but also for different configutations
of the same version, easy selection between such builds by
modifying PATH, and does not hurt non-Linux users.

The solution of putting renamed binaries in the path (with or
without additional symlinks) allows only one set of binaries,
or, at the very least makes on such set "special". Moreover,
the renaming as such introduces problems, see the comments on
gerrit.

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

Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)

[Konstantin Ritt]

> 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, symlinks, etc.
(and of course, we should care about DESTDIR! :) )

> 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?

That's not so unusual. The last time I've installed mysql on my Linux
box, it was installing exactly like this.

> (and then add multi-arch to the mix :)

Also note that it could be /usr/lib{,64}, /usr/lib{32,}, or even
/usr/lib/{i686,x86_64}-unknown-linux-gnu. Whatever it is, I don't want
x64 libs and/or executables in my lib 32 dir or vice versa.
I'd expect /user/lib/qt5 and /usr/lib{,64}/qt5/lib for the libraries
and /usr/lib{,64}/qt5/{bin,libexec} for the platform specific/version
specific/"private" executables; the common parts are expected just in
/usr/share/qt5 (where collisions are ignored). Same applies to the
headers ( /usr/include/qt5 ) with one exception -- like Oswald
mentioned above, qconfig.h can be arch-specific and then I'd expect to
find it in /usr/lib{,64}/qt5/include .
This way we could reasonable keep out libraries not renamed.
That brings nothing new (and that's how I did co-installation of Qt3
and Qt4 on my BLFS box years ago).

Now, the more attractive thing - qmake!
The idea isn't new as well: let is be a script or a dumb small
executable that simply wraps the requested Qt's qmake. As for example:
> qmake -list-versions
*Qt-5.0.0-beta2-x32 -> /usr/lib/qt5/libexec/qmake
 Qt-5.0.0-beta2-x64 -> /usr/lib64/qt5/libexec/qmake
 Qt-5.0.0-daily-mingw32 -> /usr/local/opt/qt5/mingw32/bin/qmake
> qmake -use-version 5.0.0-daily-mingw32 (or -target mingw32)
> qmake -v
QMake version 3.0
Using Qt version 5.0.0 in /usr/local/opt/qt5/mingw32
> qmake -r project.pro && make

The switch could be done via the envvars, as for example.
Which installed version is the system-default one is up to the distro
maintainer. At the same time, this could work just ok for Qt6, for
developer's Qt and so on...
The only bitter pill for the packagers to swallow I see is to ensure
Qt4's qmake is renamed to something else or moved out from /usr/bin,
and to ensure that the newly-installed Qt gets registered into such a
qmake wrapper's database.

What I have missed?


Konstantin


2012/10/19 Laszlo Papp :
> 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 the most recent release of Qt. This provides
>>> consistency with Qt on other platforms as well as the handling of other
>>> command line programs such as python, gcc, ruby, etc. within the distros.
>>
>> I'm not sure I agree with this part. For one thing, you can bet that "qmake"
>> will *not* be Qt 5's for the next year or two, as people are still developing
>> Qt 4 applications.
>>
>> And like I said in another email, Qt 5's qmake is in an entirely different
>> category from gcc, ruby, etc.
>>
>> But I'm glad you brought python up!
>>
>> Fedora$ ls -l /bin/python /bin/python?
>> lrwxrwxrwx. 1 root root 7 Aug  6 15:23 /bin/python -> python2
>> lrwxrwxrwx. 1 root root 9 Aug  6 15:23 /bin/python2 -> python2.7
>> -rwxr-xr-x. 3 root root 12888 Jun  7 22:36 /bin/python3
>>
>> openSUSE$ ls -l /usr/bin/python /usr/bin/python?
>> lrwxrwxrwx 1 root root 9 Jul  8 03:03 /usr/bin/python -> python2.7
>> lrwxrwxrwx 1 root root 9 Jul  8 03:03 /usr/bin/python2 -> python2.7
>> lrwxrwxrwx 1 root root 9 Oct 19 10:38 /usr/bin/python3 -> python3.2
>>
>> Debian$ ls -l /usr/bin/python /usr/bin/python?
>> lrwxrwxrwx 1 root root 9 May 14 11:03 /usr/bin/python -> python2.6
>>
>> Ubuntu$
>> $ ls -l /usr/bin/python{,?}
>> lrwxrwxrwx 1 root root 9 Apr 17  2012 /usr/bin/python -> python2.7
>> lrwxrwxrwx 1 root root 9 Apr 17  2012 /usr/bin/python2 -> python2.7
>>
>> As you can see, they are not symlinks to /etc/alternatives/. Those are non-
>> configurable symlinks. So even if Python 3 were installed on those Ubuntu and
>> Debian, it still wouldn't have overwritten.
>>
>> If you want to take python as precedence, then we conclude "qmake" is for Qt 
>> 4
>> and we need to find a new name for Qt 5.
>
> 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". :-)
>
> Laszlo
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing 

Re: [Development] renaming all QWindow properties that have "window" in them

[Shawn Rutledge]

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. http://doc.qt.digia.com/qq/qq13-apis.html#theartofnaming ,
> "general naming rules".
>
> i don't see why this shouldn't apply equally to qml. if it poses a
> problem in a particular case, it is most likely indicative of a serious
> API issue.

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 be inconsistent and leave that one as
windowState then?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Sune Vuorela]

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 a
> different one. It is unreasonable.

I am a bit saddened by this paragraph. I'm not demanding anything. I'm
*explaining* my situation *hoping* that we can do something.

I could also be *begging* if *you* would prefer that, but I wouldn't
expet that.

I do know that I can't *demand* anything.

I do know, though, that the only way Qt can ensure the same is done on
all distributions is to solve it in Qt.

I will try hard, if the distributions need to solve it, to ensure that
most distros implement it the same way. but I also can't demand anything
there. And I have already heard people saying that qmake-qt5 is a much
better name.

Oh. btw, whattabout a solution with all tools having a 5 suffixed in
/usr/bin and then creating a symlink farm somewhere with unversioned
tools for people who has special needs?

/Sune


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

Re: [Development] renaming all QWindow properties that have "window" in them

[Oswald Buddenhagen]

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 ,
"general naming rules".

i don't see why this shouldn't apply equally to qml. if it poses a
problem in a particular case, it is most likely indicative of a serious
API issue.

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

Re: [Development] Summary of renaming changes

[André Pönitz]

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 proves my point quite good...
> 
> > 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.
> 
> Assuming distro1 needs change A and B to be applied to be in line with
> distro policies, distro2 needs change B and C, and distro 3 needs change
> D and E, and all distros want to do as little changes to upstream as
> possible... 
> 
> I guess distros and stuff could do a permanent fork thingie, but do we,
> as in Qt Project actually want to encourage that? Like go-oo.org? like
> eglibc? like ...
> 
> Really. I really want, both as a Qt contributor and a Qt packager to
> ship a pristine Qt. Please help me make it happen.

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".


In any case, you as packager are in a very specific situation. There
are only a few of you, and I understand you do carry a burden, and
I am not opposed to the idea of reducing that burden, if reasonably
possible.

Demanding to be relieved from that burden is one thing. Demanding to
use an approach that will break thousands of other projects is a
different one. It is unreasonable.


Andre'

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

Re: [Development] Summary of renaming changes

[Lorn Potter]

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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Alternative Proposal

[Lorn Potter]

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
> solve the problem of co-installation using versioned directories.

+2
I won't add anything but my support for leaving it alone. Let the Linux 
distributions solve their own problems, which they already have.

-- 
Lorn Potter
Senior Software Engineer, QtSensors/QtSensorGestures/QtSystemInfo


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

Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)

[Laszlo Papp]

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 the most recent release of Qt. This provides
>> consistency with Qt on other platforms as well as the handling of other
>> command line programs such as python, gcc, ruby, etc. within the distros.
>
> I'm not sure I agree with this part. For one thing, you can bet that "qmake"
> will *not* be Qt 5's for the next year or two, as people are still developing
> Qt 4 applications.
>
> And like I said in another email, Qt 5's qmake is in an entirely different
> category from gcc, ruby, etc.
>
> But I'm glad you brought python up!
>
> Fedora$ ls -l /bin/python /bin/python?
> lrwxrwxrwx. 1 root root 7 Aug  6 15:23 /bin/python -> python2
> lrwxrwxrwx. 1 root root 9 Aug  6 15:23 /bin/python2 -> python2.7
> -rwxr-xr-x. 3 root root 12888 Jun  7 22:36 /bin/python3
>
> openSUSE$ ls -l /usr/bin/python /usr/bin/python?
> lrwxrwxrwx 1 root root 9 Jul  8 03:03 /usr/bin/python -> python2.7
> lrwxrwxrwx 1 root root 9 Jul  8 03:03 /usr/bin/python2 -> python2.7
> lrwxrwxrwx 1 root root 9 Oct 19 10:38 /usr/bin/python3 -> python3.2
>
> Debian$ ls -l /usr/bin/python /usr/bin/python?
> lrwxrwxrwx 1 root root 9 May 14 11:03 /usr/bin/python -> python2.6
>
> Ubuntu$
> $ ls -l /usr/bin/python{,?}
> lrwxrwxrwx 1 root root 9 Apr 17  2012 /usr/bin/python -> python2.7
> lrwxrwxrwx 1 root root 9 Apr 17  2012 /usr/bin/python2 -> python2.7
>
> As you can see, they are not symlinks to /etc/alternatives/. Those are non-
> configurable symlinks. So even if Python 3 were installed on those Ubuntu and
> Debian, it still wouldn't have overwritten.
>
> If you want to take python as precedence, then we conclude "qmake" is for Qt 4
> and we need to find a new name for Qt 5.

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". :-)

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

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)

[Thiago Macieira]

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 with Qt on other platforms as well as the handling of other
> command line programs such as python, gcc, ruby, etc. within the distros.

I'm not sure I agree with this part. For one thing, you can bet that "qmake" 
will *not* be Qt 5's for the next year or two, as people are still developing 
Qt 4 applications.

And like I said in another email, Qt 5's qmake is in an entirely different 
category from gcc, ruby, etc.

But I'm glad you brought python up!

Fedora$ ls -l /bin/python /bin/python?
lrwxrwxrwx. 1 root root 7 Aug  6 15:23 /bin/python -> python2
lrwxrwxrwx. 1 root root 9 Aug  6 15:23 /bin/python2 -> python2.7
-rwxr-xr-x. 3 root root 12888 Jun  7 22:36 /bin/python3

openSUSE$ ls -l /usr/bin/python /usr/bin/python?
lrwxrwxrwx 1 root root 9 Jul  8 03:03 /usr/bin/python -> python2.7
lrwxrwxrwx 1 root root 9 Jul  8 03:03 /usr/bin/python2 -> python2.7
lrwxrwxrwx 1 root root 9 Oct 19 10:38 /usr/bin/python3 -> python3.2

Debian$ ls -l /usr/bin/python /usr/bin/python?
lrwxrwxrwx 1 root root 9 May 14 11:03 /usr/bin/python -> python2.6

Ubuntu$
$ ls -l /usr/bin/python{,?}
lrwxrwxrwx 1 root root 9 Apr 17  2012 /usr/bin/python -> python2.7
lrwxrwxrwx 1 root root 9 Apr 17  2012 /usr/bin/python2 -> python2.7

As you can see, they are not symlinks to /etc/alternatives/. Those are non-
configurable symlinks. So even if Python 3 were installed on those Ubuntu and 
Debian, it still wouldn't have overwritten.

If you want to take python as precedence, then we conclude "qmake" is for Qt 4 
and we need to find a new name for Qt 5.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] renaming all QWindow properties that have "window" in them

[Konstantin Ritt]

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 
>> QWidget.  However it causes some silliness in Qt Quick: QQuickWindow 
>> inherits QWindow, and that means it inherits those properties too (even 
>> though they have not yet been documented).  But we would like the QML API 
>> for Window to be more typical, e.g.
>>
>> Window {
>>   title: "the title"
>>   modality: Qt.ApplicationModal
>> }
>>
>> QQuickWindow could of course add the extra properties, but then you would be 
>> able to access either one, because I don't know of a way to hide an 
>> inherited property.  Furthermore because inherited signals don't work in 
>> Q_PROPERTY declarations, it's not enough to just add
>>
>> Q_PROPERTY(Qt::WindowModality modality READ windowModality WRITE 
>> setWindowModality NOTIFY windowModalityChanged)
>>
>> in order to reuse the accessors and just rename the property.  There must be 
>> a new signal in the subclass too.  So then I have to add a setter to emit 
>> the signal when the property changes.  This is why it's easier to rename 
>> them in QWindow; and really the naming was redundant anyway.  If you have a 
>> QWidget, you need to be clear what kind of title is being set, because there 
>> can be an implied window; but if you have a QWindow it's already clear.
>>
>> So that change resulted in the following patches so far:
>>
>> https://codereview.qt-project.org/#change,37763
>> https://codereview.qt-project.org/#change,37764
>> https://codereview.qt-project.org/#change,37765
>> https://codereview.qt-project.org/#change,37766
>> https://codereview.qt-project.org/#change,37762
>>
>> and I have one for Webkit as well.  I just wondered if there are any 
>> objections before we proceed with testing and trying to integrate this, or 
>> if anyone sees something that I missed .  I will be doing further testing to 
>> make sure we get the desired result in Qt Quick.
>
> Agreed, this makes sense from the C++ API side as well,
> window->setModality() is nicer API-wise than
> window->setWindowModality(). It's less redundant and also more
> consistent, since we don't do window->setWindowPos() to set the position
> of the window for example.
>
> Are people in general ok with fixing API warts in new APIs like these
> while we still have the chance?
>
> --
> Samuel
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] renaming all QWindow properties that have "window" in them

[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 
> QWidget.  However it causes some silliness in Qt Quick: QQuickWindow inherits 
> QWindow, and that means it inherits those properties too (even though they 
> have not yet been documented).  But we would like the QML API for Window to 
> be more typical, e.g.
>
> Window {
>   title: "the title"
>   modality: Qt.ApplicationModal
> }
>
> QQuickWindow could of course add the extra properties, but then you would be 
> able to access either one, because I don't know of a way to hide an inherited 
> property.  Furthermore because inherited signals don't work in Q_PROPERTY 
> declarations, it's not enough to just add
>
> Q_PROPERTY(Qt::WindowModality modality READ windowModality WRITE 
> setWindowModality NOTIFY windowModalityChanged)
>
> in order to reuse the accessors and just rename the property.  There must be 
> a new signal in the subclass too.  So then I have to add a setter to emit the 
> signal when the property changes.  This is why it's easier to rename them in 
> QWindow; and really the naming was redundant anyway.  If you have a QWidget, 
> you need to be clear what kind of title is being set, because there can be an 
> implied window; but if you have a QWindow it's already clear.
>
> So that change resulted in the following patches so far:
>
> https://codereview.qt-project.org/#change,37763
> https://codereview.qt-project.org/#change,37764
> https://codereview.qt-project.org/#change,37765
> https://codereview.qt-project.org/#change,37766
> https://codereview.qt-project.org/#change,37762
>
> and I have one for Webkit as well.  I just wondered if there are any 
> objections before we proceed with testing and trying to integrate this, or if 
> anyone sees something that I missed.  I will be doing further testing to 
> make sure we get the desired result in Qt Quick.

Agreed, this makes sense from the C++ API side as well, 
window->setModality() is nicer API-wise than 
window->setWindowModality(). It's less redundant and also more 
consistent, since we don't do window->setWindowPos() to set the position 
of the window for example.

Are people in general ok with fixing API warts in new APIs like these 
while we still have the chance?

--
Samuel

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

Re: [Development] Summary of renaming changes

[Sune Vuorela]

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 is an argument for you
> guys finally agreeing on something and actually sticking to it, not
> upstream forcing this change on *all* users.

Assuming distro1 needs change A and B to be applied to be in line with
distro policies, distro2 needs change B and C, and distro 3 needs change
D and E, and all distros want to do as little changes to upstream as
possible... 

I guess distros and stuff could do a permanent fork thingie, but do we,
as in Qt Project actually want to encourage that? Like go-oo.org? like
eglibc? like ...

Really. I really want, both as a Qt contributor and a Qt packager to
ship a pristine Qt. Please help me make it happen.

*hugs* and *kisses*

/Sune

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

Re: [Development] Summary of renaming changes

[Thiago Macieira]

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.trolltech" to "org.qtproject" (yes, without the dash). The Qt 4 version 
of the tool warns but accepts the old name, the Qt 5 version errors out.

I can bring it back to compatibility though. I'll also add a "--qt5" option 
that is currently ignored to both versions, for future use.

> But the name changes should be mostly invisible to developers as the tools
> are being called by the build system.
> >   lconvert-> lconvert5
> >   lrelease-> lrelease5
> >   lupdate -> lupdate5
> 
> These tools are in-between, as they IMO get called both by build systems as
> well as by developers directly. But if they are not compatible with Qt 4,
> we can't really have the same name unfortunately.

Indeed. Right now, they produce the same output, as far as I understand, but 
Ossi says he cannot guarantee that it will remain like that. 

What's more, both lrelease and lupdate now try to parse .pro files and they run 
qmake for that. Those two are definitely not backwards compatible anymore.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Sune Vuorela]

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
qmake5, but maybe the distro chose some other naming scheme so it could
also be qmake-qt5 or /usr/lib/ia64-linux-gnu/qt5/bin/qmake"

/Sune


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

Re: [Development] Summary of renaming changes

[Thiago Macieira]

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". If
> we set the standards for distributions to have also e.g.
> /usr/lib/qt5/bin/qmake

Yes, you can query qmake. But first you need to find it. Currently and for the 
next couple of years, that qmake is definitely not Qt 5's. It might be Qt 3's 
or Qt 4's, but will definitely not be Qt 5's.

> in addition to a symbolic link from /usr/bin/qmake to the "current" setting,
> a script can take "qmake" from the PATH (which can be set to whatever), and
> ask it where the other things are.

A system-wide symlink is not a solution for people who aren't admins. Besides, 
that breaks multiple builds, for people who will be engaged in porting and 
need to try the older Qt 4 application at the same time as the newer Qt 5 one.

The only solution that works is modifying PATH, with a script (it can't be 
done globally either, for the same reasons as above).

> > I did propose that we move all binaries except qmake
> 
> Why leave qmake out of the equation?

See above. You need to find qmake in order to find the other tools. And "qmake" 
will not be Qt 5's.

Therefore, we need another name for the tool that lets us find the other tools. 

Here's an idea: put *all* tools in libexec, including qmake, but install a 
new, global qt5-config. That tool allows one to find the rest, like:

kde4-config --prefix
python3 --prefix
icu-config --prefix
xslt-config --prefix
mysql_config --prefix

Or the other 47 that I have in my system:
$ ls /bin/*[_-]config | wc -l
52

Note: such tool needs to work for multiarch too, unlike mysql_config.

> > and the end-user
> > applications to a "libexec" dir, which is basically what that dir of yours
> > is. It didn't happen because, as I was starting this effort, I was
> > convinced to go for the option of renaming everything instead: moc, uic,
> > rcc, etc.  are well- defined tools with well-defined interfaces, manuals,
> > etc.. They are not internal helpers.
> > 
> > [1] we already copy the .dll files because of that problem and the DLLs
> > are
> > much larger, so copying the executables is no big deal.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Thiago Macieira]

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 majority of Qt users is not affected at all.
> 
> - The "solution" is invasive.
>* Some of the follow-up changes are only triggered by the renaming
>  E.g. the "need" to co-install lupdate does not exist yet, but is 
>  introduced by the qmake changes.
>* It affects any user project setup involving moc, uic, etc "custom
>  buildstep", like the ones all Qt using Visual Studio projects have,
>  therefore eliminating the possibilty of having a code base running
>  on both Qt 4 and Qt 5, and even hampering a direct Qt 4 -> Qt 5 port.
>   * Documentation needs to be adjusted.
>   * Existing third party documentation of Qt in use, howto's, tutorials, 
> in the *net lose value, because it will be not accurate anymore.

Please add this factor into your analysis, then:

Packagers WILL rename and there will be installations with renamed tools.

How does that affect the documentation? How does that affect the existing 
setups? How does that tutorials, etc.?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Thiago Macieira]

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 define an "external tool" in Qt Creator.
> Configuration of these external tools is in Environment > External Tools,
> you can define any executable to run there with arguments etc, and a menu
> item for the tool will be shown in Tools > External.
> 
> E.g. we ship by default with an external tool definition for running lupdate
> and lrelease, and the "executable" we run is defined as:
> 
> %{CurrentProject:QT_INSTALL_BINS}/lrelease
> 
> Qt Creator resolves that variable in there by taking the current project,
> taking the current Qt version setting for that project, and asking that Qt
> version for "qmake -query QT_INSTALL_BINS".
> 
> At the moment that should work for Qt4 and Qt5.
> If you rename lrelease to lrelease5 (or any other tool that we ship), this
> is no longer possible and gets pretty fancy.

Having lrelease unrenamed in a different path would still require a change in 
the definition, to %{CurrentProject:QT_INSTALL_LIBEXEC}/lrelease.

In any case, I think that lrelease and lupdate being run directly is the wrong 
solution. They should be run by the Makefile, by having a correct .prf that 
gets processed and adds the correct rules.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Thiago Macieira]

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 intuitive, is it ?  Also, what happens if we release a Qt 6 with
> a qml 2 compatibility viewer?
> 
> Thinking about it, I'd rather keep the qmlviewer, qmlscene names, and go for
> 
> qmlviewer -> qt 4
> qmlviewer5 -> qt 5 , qtquick 1
> qmlscene5 -> qt 5 , qtquick 2

Sounds like a plan. Any other supporters?

I don't mind either way. I've done it the way I did because:

> >   [qml1plugindump had already been renamed]

and I simply followed the logic that was already there.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

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 team receives a notification of an incident, one
> or more members review it and consider its impact on the stable
> release of Debian (i.e. if it's vulnerable or not). If our system is
> vulnerable, we work on a fix for the problem. The package maintainer
> is contacted as well, if they didn't contact the security team
> already. Finally, the fix is tested and new packages are prepared,
> which are then compiled on all stable architectures and uploaded
> afterwards. After all of that is done, an advisory is published." [1]
>

Weird that Debian contradicts themselves, but hardly relevant. Plenty
of projects use responsible disclosure... but that is NOT an argument
in favor of it. Lots of projects are also insecure, get it?

> Now let's say someone found a security flaw in Qt, report the attack
> vector and we blindly publish it with the fix not yet in work. What
> happen if somebody in the meantime make a proper with bad intention
> and spread it over? Millions of products run Qt. Then we don't have
> anything to provide to help our user it's too late. When we put the
> exploit public, there should already be a patch committed and
> announcement made so people can update their Qt before it gets too
> late.
>

Fix'd:

> Now let's say someone found a security flaw in Qt, report the attack
> vector and we sit on it for a week or two. What
> happen if somebody in the meantime leaks that vulnerability with bad intention
> and spread it over? Millions of products run Qt. Then we don't even
> give our users the option of shutting down their vulnerable systems
> until a fix can be delivered. They are sitting in the dark waiting for
> a fix to an exploit they don't even know exists (but the crackers certainly 
> do!)


> When we put the
> exploit public, there should already be a patch committed and
> announcement made so people can update their Qt before it gets too
> late.

That is an impossible requirement without extending the window in
which an vulnerability can be exploited.

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

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[Giuseppe D'Angelo]

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
Developers' Reference[1] says:

5.8.5.2. Confidentiality

Unlike most other activities within Debian, information about security
issues must sometimes be kept private for a time. This allows software
distributors to coordinate their disclosure in order to minimize their
users' exposure. Whether this is the case depends on the nature of the
problem and corresponding fix, and whether it is already a matter of
public knowledge.

[1] http://www.debian.org/doc/manuals/developers-reference/pkgs#bug-security

Cheers,
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Thiago Macieira]

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
> component sets ...

Ok, I haven't (un)done the change yet, so I'm holding back on it now.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Thiago Macieira]

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 different
> versions of one binary. Obviously the coinstallation problem is unsolved
> for Linux distributions. Everyone is forced to do nasty workarounds
> where this could be solved in a proper way by agreeing on a standard.

Different versions of one binary but that retain backwards compatibility and 
purpose is not an issue. Those are rare cases anyway and, sure, tricks are 
often needed.

One case people keep bringing up is GCC. So let's talk about GCC.

When I last upgraded GCC from 4.6 to 4.7, it still compiled my programs. Where 
it didn't, it was usually broken code anyway. GCC developers reserve the right 
to fix bugs with their compliance with the C++ standard, just like we do 
reserve the right to fix bugs and change behaviour so long as we're still 
following our documentation.

So when I last upgraded GCC, it simply replaced the old one. "gcc" used to be 
4.6, now it is 4.7. The purpose is still the same: compile C and C++ programs.

The same can be said of, for example, CMake. Whenever there's an upgrade, from 
2.6 to 2.8, to 2.8.8, etc., it still performs the same functions. It still 
parses the same .txt files and loads the same scripts from  /usr/share/cmake. 
Their developers are actually quite careful about changing even small 
behaviour changes, which are triggered only by setting options (the policies).

But that can't be said of qmake. Upgrading qmake from Qt 4's version to Qt 5's 
changes it completely. It does not parse the same .prf files, they're not even 
in the same location! It does not serve the same purpose: that of compiling an 
application for Qt 4.

The qmake that comes with Qt 5 is serving an entirely different *purpose* than 
the one that came with Qt 3 or Qt 4. That's why it needs to be allowed to co-
exist with those others.

>This *is* the problem of Linux distributions. FHS doesn't cover this
> problem properly and this is the point where it should be fixed.
>You're making life harder for every platform - not only Linux - by
> fixing their problem.

You may argue that case, but they'll argue back that this solution has worked 
quite well for almost all packages for over a decade.

But I think that discussion is irrelevant and moot. The distributions will not 
change. If we fail to apply the fixes to our build, they will patch Qt and 
they've said as much on this mailing list. The end result of that is that they 
change *our* product, which means our documentation no longer applies to 
people who develop from packages, the help we give in #qt or other forums 
isn't entirely accurate.

What's more, they may introduce subtle bugs that may take a long time to be 
discovered. When tools like lrelease and lupdate fail to work, who will the 
users blame? Distributions or us?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] renaming qmake for everyone (was: Re: Co-installation & library naming rules=)

[Thiago Macieira]

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
> Xcode doesn't do a global install anymore, except if you really really
> really force it, then you can install the command line tools globally (only
> one version simultaneously), but not the SDKs).

Isn't a libraries-only global frameworks install what we released for beta1? 
Sure, the plan for beta2 is a general SDK.

> Frameworks are not renameable, but solve the "major version" problem anyhow,
> so why rename them.

Frameworks are not getting renamed. That would break source compatibility too.

> > What I haven't understood yet is how you select a different version
> > besides
> > "Current" in Mac frameworks.
> 
> You don't  select different versions besides "Current".
> 1) Runtime linking is done against a specific version
> "QtGui.framework/Versions/4/QtGui" anyhow, so at runtime the right version
> is taken 

Sure, that's runtime though.

> 2) You just don't use a global framework install for development.

A-ha! That's exactly the point, then. If Mac developers do not expect global 
frameworks for development, then we shouldn't provide it, we shouldn't bother 
to support it and we don't have to worry about making them work.

> Point is: We don't need to optimize for the uncommon case, while making
> everything more obscure for the common case.

Agreed.

So on both Mac and Windows, Qt libraries are always installed on their own 
prefixes. There's no global install. That means there's no conflict of names 
either, in either libraries or tooling.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure

[Alexis Menard]

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.

Secondly I disagree with your statement and using the same link
(Debian) you sent let me quote something else :

"A: Once the security team receives a notification of an incident, one
or more members review it and consider its impact on the stable
release of Debian (i.e. if it's vulnerable or not). If our system is
vulnerable, we work on a fix for the problem. The package maintainer
is contacted as well, if they didn't contact the security team
already. Finally, the fix is tested and new packages are prepared,
which are then compiled on all stable architectures and uploaded
afterwards. After all of that is done, an advisory is published." [1]

Q: How can I reach the security team?

A: Security information can be sent to secur...@debian.org or
t...@security.debian.org, both of which are read by the members of the
security team.

They also have a private mail, only read by the security team.

I'll give you another example. WebKit is the same there is a private
security mailing list.

The fact that *after* the fix is done you do a full public disclosure
is totally fine. But you should keep the exploit private up until the
fix is done.

Now let's say someone found a security flaw in Qt, report the attack
vector and we blindly publish it with the fix not yet in work. What
happen if somebody in the meantime make a proper with bad intention
and spread it over? Millions of products run Qt. Then we don't have
anything to provide to help our user it's too late. When we put the
exploit public, there should already be a patch committed and
announcement made so people can update their Qt before it gets too
late.

[1] http://www.debian.org/security/faq#handling

>
> On Thu, Oct 18, 2012 at 3:40 PM, d3fault  wrote:
>> tl;dr:
>> Open Project
>> Closed Security
>>
>> The officially endorsed method for reporting security issues for Qt is
>> to send them to secur...@qt-project.org , which is a private mailing
>> list. I have a problem with that.
>>
>> "Experience has shown that 'security through obscurity' does not work.
>> Public disclosure allows for more rapid and better solutions to
>> security problems" ( http://www.debian.org/security/ ).
>>
>> "Security information moves very fast in cracker circles. On the other
>> hand, our experience is that coding and releasing of proper security
>> fixes typically requires about an hour of work -- very fast fix
>> turnaround is possible. Thus we think that full disclosure helps the
>> people who really care about security" (
>> http://openbsd.org/security.html ).

The report is also on a private part on BSD :

"If you find a new security problem, you can mail it to dera...@openbsd.org. "

>>
>> If the Qt Project does not intend on taking security issues seriously,
>> then we should remove security related classes from the project
>> (QSslSocket namely). Leaving them in is misleading.
>>
>> d3fault
>
> d3fault
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



-- 
Software Engineer @
Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] renaming all QWindow properties that have "window" in them

[Rutledge Shawn]

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 have 
not yet been documented).  But we would like the QML API for Window to be more 
typical, e.g.

Window {
title: "the title"
modality: Qt.ApplicationModal
}

QQuickWindow could of course add the extra properties, but then you would be 
able to access either one, because I don't know of a way to hide an inherited 
property.  Furthermore because inherited signals don't work in Q_PROPERTY 
declarations, it's not enough to just add

Q_PROPERTY(Qt::WindowModality modality READ windowModality WRITE 
setWindowModality NOTIFY windowModalityChanged)

in order to reuse the accessors and just rename the property.  There must be a 
new signal in the subclass too.  So then I have to add a setter to emit the 
signal when the property changes.  This is why it's easier to rename them in 
QWindow; and really the naming was redundant anyway.  If you have a QWidget, 
you need to be clear what kind of title is being set, because there can be an 
implied window; but if you have a QWindow it's already clear.

So that change resulted in the following patches so far:

https://codereview.qt-project.org/#change,37763
https://codereview.qt-project.org/#change,37764
https://codereview.qt-project.org/#change,37765
https://codereview.qt-project.org/#change,37766
https://codereview.qt-project.org/#change,37762

and I have one for Webkit as well.  I just wondered if there are any objections 
before we proceed with testing and trying to integrate this, or if anyone sees 
something that I missed.  I will be doing further testing to make sure we get 
the desired result in Qt Quick.

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

Re: [Development] RFC: Qt Security Policy

[d3fault]

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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Donation From Mrs Roseline Thompson

[Mitch Curtis]

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 Lord Jesus Christ, I am Mrs Roseline Thompson 
from republic of Kuwait. I am married to Mr Micheal Thompson . who worked with 
Kuwait embassy in for nine years before he died in the year 2003. We were 
married for eleven years without a child. He died after a brief illness that 
lasted for only fourteen days. Before his death we were both born again 
christian and he was posted to Abidjan Cote D Ivoire and he took me along.

Since his death I decided not to remarry or get a child outside my matrimonial 
home which the word of God is against. When my late husband was alive he 
deposited the sum of US$8million dollars in a (Finance and Storrage Company) 
while we were in Cote d'ivoire . Presently, this money is still in the Company 
in Cote d'ivoire and I don't want to leave it there because of my illness. 
Recently, my Doctor told me that I would not last for the next Eight months 
due to cancer problem. The one that disturbs me most is my stroke sickness. 

Having known my condition I decided to donate this fund to a charity 
organization that will utilize this money the way I am going to instruct 
herein. I want an organization that will use this fund for orphanages, school 
and church, widows, propagating the word of God and to endeavor that the house 
of God is maintained. The Bible made us to understand that "Blessed is the 
hand that giveth".I took this decision because I don't have any child that 
will inherit this money and my husband relatives are not Christians and I 
don't want my husband's efforts to be used by unbelievers. 

I don't want a situation where this money will be used in an ungodly way. This 
is why I am taking this decision. I am not afraid of death hence I know where 
I am going. I know that I am going to be in the bosom of the Lord.Exodus 14 VS 
14 says that "the lord will fight my case and I shall hold my peace". I don't 
need any telephone communication in this regard because of my health hence the 
presence of my husband's relatives around me always. I don't want them to know 
about this development.With God all things are possible. As soon as I receive 
your reply I shall give you the contact of the Company in Cote d'ivoire to 
enble you contact them and ask them on how to retreave the money from their 
Company and deliver it to you in your Country.. 

I will also issue you a power of attorney and letter of authorization that 
will prove you the present beneficiary of this fund. I want you and the church 
to always pray for me because the lord is my shephard. My happiness is that I 
lived a life of a worthy Christian. Whoever that Wants to serve the Lord must 
serve him in spirit and Truth. Please always be prayerful all through your 
life.

please get back to me as soon as you receive this massage so that i will give 
you the Contact of the Company. delay in your reply will not give me room in 
sourcing another person or church for this same purpose. Please assure me that 
you will act accordingly as I Stated herein. Hoping to receive your reply. 

Remain blessed in the Lord.

Yours in Christ,

Sister Roseline Thompson



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

Re: [Development] RFC: Qt Security Policy

[d3fault]

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 similar to Full disclosure except that
there's a window of time where a variable size group of individuals
are sitting on the vulnerability information until a fix is delivered.
As I've said before, holding onto that information only extends the
window in which an exploit can be utilized. It has a vital flaw: it
requires you to trust other human beings. A group of them no less.

"Security information moves very fast in cracker circles." (
http://openbsd.org/security.html )

You only need ONE weak/corrupt link in your group of "trusted"
analysts for the practice of "Responsible Disclosure" to now ACTIVELY
CAUSE HARM TO USERS who you are trying to protect.

Full disclosure allows everyone to analyze their own situation and
decide whether or not to bring their systems down (sometimes this
can't be helped) until a fix is available.

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

Re: [Development] RFC: Qt Security Policy

[Daniel Molkentin]

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 satisfied Godwin's law, can we please kick him off 
this list? He and his badly faked sock-puppet are my time.

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

Re: [Development] RFC: Qt Security Policy

[Oswald Buddenhagen]

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-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Help fixing, or WONTFIXing, an 8+ month old bug: QTBUG-24304

[Curtis Mitchell]

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 mistake by the closer 
- then the bug can be reopened. I've been looking at lots of older bugs lately, 
most of which were reported earlier than yours, so you're not alone in that 
it's been a while since someone's looked at it.

Oh and, yes, I missed the link to the screenshot in the description; I do 
apologise for that.

From: development-bounces+mitch.curtis=digia@qt-project.org 
[development-bounces+mitch.curtis=digia@qt-project.org] on behalf of 
d...@nospammail.net [d...@nospammail.net]
Sent: 11 October 2012 21:01
To: development@qt-project.org
Subject: [Development] Help fixing, or WONTFIXing,  an 8+ month old bug:  
QTBUG-24304

I filed a bug ~ 8 months ago for a reproducible problem's that's been
around since at least Qt v4.7.4, and continues in Qt v4.8.3.

In the OP, and recently, I've included procedure to reproduce &
screenshots.

Here's the bug:

15/Feb/12 6:35 PM
https://bugreports.qt-project.org/browse/QTBUG-24304
Qt LineEdit incorrectly truncates "Password" dialog elements
when entered with a KDE Custom Shortcut ...

In those 8 months, the only activity has been to pop up and suddenly
close the bug, and incorrectly claim that I never included a screenshot
in the 1st place.

I've been trying to get someone to address this for a colleague with
accessibility challenges.

Could some dev spare time/effort to either address the issue, or simply
communicate that it's not going to get fixed?

8+ months seems a reasonable amount of time for an end-user to wait for
some sort of activity.

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

[Development] Proposal: Change Qt's Security Policy to Full Disclosure

[d3fault]

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 method for reporting security issues for Qt is
> to send them to secur...@qt-project.org , which is a private mailing
> list. I have a problem with that.
>
> "Experience has shown that 'security through obscurity' does not work.
> Public disclosure allows for more rapid and better solutions to
> security problems" ( http://www.debian.org/security/ ).
>
> "Security information moves very fast in cracker circles. On the other
> hand, our experience is that coding and releasing of proper security
> fixes typically requires about an hour of work -- very fast fix
> turnaround is possible. Thus we think that full disclosure helps the
> people who really care about security" (
> http://openbsd.org/security.html ).
>
> If the Qt Project does not intend on taking security issues seriously,
> then we should remove security related classes from the project
> (QSslSocket namely). Leaving them in is misleading.
>
> d3fault

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

Re: [Development] RFC: Qt Security Policy

[d3fault]

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 discussing/modifying/improving Qt's security
policies isn't productive? Interesting.


I find it hilarious that, despite me being the immature baby at times
(admittedly), everybody else (the 'mature grown-ups') attack my
persons instead of my arguments. I'm consistently surprised at how
illogical programmers can be (considering programming is logic...).


Welcome to Qt: The community where if you suggest something FIRST,
your opinions are written in stone and irreversible. If I would have
started this thread instead and offered up the suggestions, due to a
lack of disagreement I would have gotten consensus. Sounds pretty
stupid to me.

Anybody want to respond telling me why they think full disclosure is
worse than behind closed doors security? You know, instead of telling
me something I already know (that I'm a baby/immature/etc ).

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

Re: [Development] highlight/background colour of active tabs

[Randolph D.]

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, I ask Qt people to switch default, the
active one to white, or the inactive tabs to lightgrey and the active tab
to dark grey. either or, thanks.

2012/10/19 André Somers 

> 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 tab is regarded as the general background
> > colour, and this is misleading, better would it be, if all tabs not
> > active are light-grey, (as any other frame colour) and the ACTIVE tab
> > is default  dark-grey (or alternatively white).
> > e.g. in the qt web browser http://dooble.sf.net you can see this
> > phenomen. Can someone swith the active tab colour either to white, or
> > switch the non-active tabs to light-grey and the active tab to dark-grey?
> >
> Well, this is of course style dependent. What style are you talking about?
>
> André
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)

[Oswald Buddenhagen]

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/lib and
the one in /usr/lib would be a symlink only. *all* FHS locations would
be symlinks only. know the tool 'stow'?

> (and then add multi-arch to the mix :)
> 
just make it /usr/lib/i386-linux-gnu/qt5/lib.
not sure how duplication of headers would be handled, but given that
qconfig.h theoretically can be arch-specific, the whole set may need to
be duplicated.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)

[Simon Hausmann]

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 the tools,
> but i think renaming the libraries is mostly counterproductive, too:
> - the change is linux-only. on mac it simply cannot be done (in the
>   framework case) and on windows it is already this way. the latter is
>   rather ugly, as mentioned before.
> - it is entirely unnecessary for deployment, as shared object versioning
>   perfectly supports co-installed major versions
> - it is sort-of unnecessary for development, as -I & -L can be used to
>   specify which libraries to build against

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?
 
(and then add multi-arch to the mix :)


Simon

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

Re: [Development] qtwayland module fails to build for Raspberry Pi

[Thomas Senyk]

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 that
> >>> imply qtwayland cannot work with the wayland installed on the rpi.
> >> 
> >> Probably. Upgrade your Wayland to 0.95 at least.
> > 
> > Ok, I tried this - got wayland itself to build, but qtwayland fails
> > compiling compositor_api/**waylandsurfaceitem.cpp:
> > 
> > compositor_api/**waylandsurfaceitem.cpp:55:32: fatal error:
> > QtQuick/QQuickCanvas: No such file or directory
> > 
> > I believe this header was depricated some time ago?
> 
> It was renamed to QQuickWindow.

and it's already fixed ... so a git pull in qtwayland should help

> 
> > I will try the SHA1 mentioned in emails below - but IIRC when I tried
> > that originally, it too failed due to changes made in
> > waylandresourcecollection.cpp and waylandresourcecollection.h in later
> > qtwayland commits.
> > 
> > I will try this again right now though - maybe I missed something, it
> > was a long night :)
> > 
> > 
> > 
> > --
> > Jon Trulson
> > 
> > The Higgs Field is what make atoms matter.
> > 
> > -- Tom L.
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Alternative Proposal (was: Re: Summary of renaming changes)

[Oswald Buddenhagen]

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, too:
- the change is linux-only. on mac it simply cannot be done (in the
  framework case) and on windows it is already this way. the latter is
  rather ugly, as mentioned before.
- it is entirely unnecessary for deployment, as shared object versioning
  perfectly supports co-installed major versions
- it is sort-of unnecessary for development, as -I & -L can be used to
  specify which libraries to build against

i'm considering renaming the pkg-config files, as they target
specifically linux and are the official entry point for the last item
above. it's far from decided, though.

> In short: We find that there is no _need_ to rename the tools and that
> we can solve the problem of co-installation using versioned
> directories.
>
correct.
i find andre's "implementation" more precise. your "proposal" is
basically a summary of the status quo amongst linux distros.

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

Re: [Development] Summary of renaming changes

[Matt Williams]

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 for.
>>
>> I have, as a distributor, frequently gotten 'hate' in #qt for providing
>> switchable qmakes.
>>
> using (debian style) altenatives for that is pretty stupid.
>
> using a "menu" function which manipulates PATH in the current shell is
> exactly the right thing to do. that's the ominious "qset" some trolls
> have been talking about.

There is also 'modules' (http://modules.sourceforge.net/) which is
used at my University to achieve a similar thing.

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

Re: [Development] Summary of renaming changes

[Poenitz Andre]

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 default to qt5 or alternatively write qmake5 to
> build things" is a much longer sentence than
> 
> "write qmake5 to build things".
>
> The advantage of doing it upstream, rather than having me to do it,
> kevin to do it, will to do it, jonathan to do it, ... is that
>  - the implementation is the same
>  - the result is the same
>  - you do not have to consider what distribution teh user is on when
>trying to help in #qt, on interest@ or in forums. just write 'use
>qmake5

That's achievable by a few lines of text:

   Linux distributors are strongly advised to install all Qt 5 related 
executables
   (qmake, uic, rcc, ...) with unmodified names to a directory that is not 
   in $PATH and set up symlinks  'qmake5' etc that are in $PATH.

   Linux distributors are strongly advised to install all Qt 4 related 
executables
   (qmake, uic, rcc, ...) with unmodified names to a _different_ directory 
   that is not  in $PATH and set up symlinks  'qmake4' etc that are in $PATH.

   If Linux distributors feel strong about it, they may use their distributions
   "native" system to handle alternatives to set up  'qmake' etc links in the 
   path to point to the qmake binary in either  the Qt 4 or the Qt 5 binaries 
   directory,  [Suggesting to modify PATH is probably the saner choice, 
   I don't really care about this part]

User support could then be:

  "write qmake5 to build Qt 5 things"

Users/Admins could then use the distribution's "defaults" system to 
switch the "system" Qt version, they can also override the system
setup by modifying their local PATH settings, per-shell even.

None of these operations are "unusual", or "technically challenging",
or "cumbersome", and it does not require, or even only benefit, from the 
proposed renaming of the binaries.

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

Re: [Development] Summary of renaming changes

[Laszlo Papp]

> 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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] cloning qt5 warning ?

[Sean Harmer]

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 ref, unable to checkout.

Sounds like gitorious being its unreliable self. Just try again in a few 
minutes.

Cheers,

Sean

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

Re: [Development] Summary of renaming changes

[Oswald Buddenhagen]

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 'hate' in #qt for providing
> switchable qmakes.
> 
using (debian style) altenatives for that is pretty stupid.

using a "menu" function which manipulates PATH in the current shell is
exactly the right thing to do. that's the ominious "qset" some trolls
have been talking about.

> The advantage of doing it upstream, rather than having me to do it,
> kevin to do it, will to do it, jonathan to do it, ... is that 
>  - the implementation is the same
>  - the result is the same
>  - you do not have to consider what distribution teh user is on when
>trying to help in #qt, on interest@ or in forums. just write 'use
>qmake5
> 
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.

regards (slightly annoyed ones by now)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Alternative Proposal (was: Re: Summary of renaming changes)

[Simon Hausmann]

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.

(2) It also seems that there is an agreement that we don't have to rename the 
applications such as Qt Creator, Qt Designer, etc. - programs that are very 
much meant to be launched explicitly by the user via the menu.

(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.

On Mac OS X and Windows co-installation is an established concept for Qt users 
by containing each version in different directories and making a choice via the 
PATH environment variable.

The same approach is used by users of Qt compiling from source on Linux as 
well. The only problem left is co-installation of Qt when it is supplied by 
the Linux distribution.

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 with 
Qt on other platforms as well as the handling of other command line programs 
such as python, gcc, ruby, etc. within the distros.

With this in mind, let's look at the possible options of namespacing the 
command line tools:

(a) We can keep the names but contain them in a directory outside of /usr/bin, 
just like on Windows, Mac OS X and source builds.

This would mean that /usr/bin/qmake is implemented as a symlink to for example 
/usr/lib/qt5/libexec/qmake.

[See footnote [1] regarding the implementation of this solution]

(b) We can pre-/postfix the binary names and leave them in their default 
location /usr/bin.

This would mean that /usr/bin/qmake is implemented as a symlink to 
/usr/bin/qmake5. However for consistency this would mean that qmake would have 
to be renamed to qmake5 on the other platforms, too, where we don't have a 
problem to solve and the renaming just introduces unnecessary changes to 
existing workflows, as described by numerous people in this thread, such as 
having to change existing vcproj files or changes in Qt Creator to find the 
right qml viewer to launch.

The first option however matches the other platforms and existing workflows and 
has no disadvantages compared to the pre-/postfixing of the binaries.

In fact it has advantages, such as continuing to offer the ability to put the 
contained directory into your PATH, just like you do it for source builds and 
on the other platforms.

In short: We find that there is no _need_ to rename the tools and that we can 
solve the problem of co-installation using versioned directories.



Simon & Tor Arne



[1] Implementation:

Distros would configure Qt with -prefix /usr -bindir /usr/lib/qt5/libexec etc. 
This could also be implemented via a convenience ./configure -fhs-compliant 
parameter.

We would then add an option to configure that ensures that at install time a 
symlink is created from /usr/bin/qmake to the binary 
in 
libexec. This allows you to call a specific version of qmake conveniently from 
/usr/bin if required.

The only missing part then is the missing symlink of /usr/bin/qmake to the 
real qmake binary, which is a distribution specific mechanism, such as update-
alternatives on Debian based distros.

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

[Development] cloning qt5 warning ?

[Martin Koller]

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 regards/Schöne Grüße

Martin

A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

This mail was not scanned before sending.
It was sent from a secure Linux desktop.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Kevin Krammer]

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 C++ launcher for every
> little app or utility that you write in QML.

As you have mentioned yourself later on, a .qml extension alone is not 
sufficient information to determine its runtime requirements.

There is the difference between QtQuick1 and QtQuick2, at least needing a 
different view. Then there is BB10 Cascades, needing a very different 
application instance, KDE Plasma .qml might also have their own requirements.

The explicit split in Qt5 between QML and QtQuick2 makes it even more likely 
that we will see other usages of the QML engine to provide declarative input 
for processing problems (IIRC there is a QML based cmake frontend prototype).

Cheers,
Kevin
-- 
** Qt Developer Conference: http://qtconference.kdab.com/ **

Kevin Krammer | kevin.kram...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions


smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Sune Vuorela]

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' 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 default to qt5 or alternatively write qmake5 to 
build things" is a much longer sentence than 

"write qmake5 to build things".

The advantage of doing it upstream, rather than having me to do it,
kevin to do it, will to do it, jonathan to do it, ... is that 
 - the implementation is the same
 - the result is the same
 - you do not have to consider what distribution teh user is on when
   trying to help in #qt, on interest@ or in forums. just write 'use
   qmake5

/Sune

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

Re: [Development] Summary of renaming changes

[Poenitz Andre]

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 clearly won't be a consensus, 
> which means we're going to need a Chief Maintainer decision at some
> point. I hope we can all respect what ever that will be, and then move on.

The problem is only solved by a decision if the decision is "stay put".

In the other case, someone has to cleanup the fallout. Neither tooling 
nor user projects will magically adjust just because there was a Word.

Andre'

PS: I honestly start wondering how a change with such an impact can be
seriously considered _at all_ that late in the process. Trivial additions
have been rejected for months because we are in feature freeze and 
now _that_. 

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

Re: [Development] Summary of renaming changes

[Joerg Bornemann]

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 unsolved 
for Linux distributions. Everyone is forced to do nasty workarounds 
where this could be solved in a proper way by agreeing on a standard.
   This *is* the problem of Linux distributions. FHS doesn't cover this 
problem properly and this is the point where it should be fixed.
   You're making life harder for every platform - not only Linux - by 
fixing their problem.


Cheers,

Jörg

-- 
Joerg Bornemann
Senior Software Engineer - Digia, Qt
http://qt.digia.com/

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

Re: [Development] Summary of renaming changes

[Alberto Mardegan]

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/qmake must
be either the Qt4 or the Qt5 qmake, but this doesn't mean that qmake
needs to be renamed.

It's perfectly possible to install the unrenamed qmake tool in different
directories, like for instance:
/opt/Qt4/bin/qmake
/opt/Qt5/bin/qmake

Then distributors could choose their preferred way to make these tools
reachable by a user, by a variety of means:

1) Provide symlinks:
   /usr/bin/qmake -> /opt/Qt4/bin/qmake
   /usr/bin/qmake5 -> /opt/Qt5/bin/qmake

2) Provide nothing, just let the user setup his PATH manually.

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'm not suggesting anything new, all these options have been suggested
by other people before and I'm just summarizing them (sorry for not
remembering who proposed them).

Option 1) is very similar, from an application developer point of view,
to Thiago's proposal, but it leaves the final choice to distributors.

Ciao,
  Alberto

-- 
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Summary of renaming changes

[Poenitz Andre]

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-compiled. Hence that argument is
> > obsolete.
> 
> For Windows, that's correct.
> 
> > So you are creating distribution scripts which then point to the currently
> > used Qt version for qmake? If not, who is creating those for the other
> > libraries/tools, which follow a similar attempt of having a simlink in
> > /usr/bin or /usr/local/bin pointing to libexec. Has anyone talked to those
> > package managers how they see it?
> 
> No, we're not creating scripts. As I replied to Lorn, I don't see the value in
> having qmake duplicated in $bindir and $libexecdir.
> 
> Since $bindir/qmake is already taken, if we put something in $bindir, it needs
> to be called something else. The only other option is to not install anything
> in $bindir. If we choose that, however, how will users find qmake in the first
> place?
> 
> So we have $bindir/qmake5 and we update all the documentation to say "qmake5".
> What's the use of $libexecdir/qmake now?
> 
> In my plan, "qmake" will never be for Qt 5. Whether it's for Qt 3 or for Qt 4,
> it's undefined. That mess is already present and we can't fix it anymore.

I started -2'ing the changes, based on the outcome of a cost/benefit "analysis":

- 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 majority of Qt users is not affected at all.

- The "solution" is invasive.
   * Some of the follow-up changes are only triggered by the renaming
 E.g. the "need" to co-install lupdate does not exist yet, but is 
 _introduced_ by the qmake changes.
   * It affects any user project setup involving moc, uic, etc "custom
 buildstep", like the ones _all_ Qt using Visual Studio projects have,
 therefore eliminating the possibilty of having a code base running
 on both Qt 4 and Qt 5, and even hampering a direct Qt 4 -> Qt 5 port.
  * Documentation needs to be adjusted.
  * Existing third party documentation of Qt in use, howto's, tutorials, 
in the *net lose value, because it will be not accurate anymore.

This is a completely unreasonable trade-off.

Andre'







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

Re: [Development] Summary of renaming changes

[Konstantin Ritt]

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/19 Ziller Eike :
> 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".
> If we set the standards for distributions to have also e.g. 
> /usr/lib/qt5/bin/qmake
> in addition to a symbolic link from /usr/bin/qmake to the "current" setting, 
> a script can take "qmake" from the PATH (which can be set to whatever), and 
> ask it where the other things are.

That's almost the same I've told about at IRC today :)

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

Re: [Development] Co-installation & library naming rules

[Saether Jan-Arve]

> -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: Re: [Development] Co-installation & library naming rules
> 
> On Thursday, October 11, 2012 04:11:10 PM Thiago Macieira wrote:
> > On quinta-feira, 11 de outubro de 2012 21.16.56, Oswald Buddenhagen
> wrote:
> > > On Thu, Oct 11, 2012 at 11:56:44AM -0700, Thiago Macieira wrote:
> > > > Considering all the changes I am proposing do NOT harm any of the
> > > > people that build from sources,
> > >
> > > they *do* harm. i positively do *not* want to use qmake-qt5 just
> > > because it's the least evil for linux package users.
> >
> > That's the very most important change that needs to be done: renaming
> qmake.
> > All the other tools could be separated elsewhere, the libs could be
> in
> > different dirs. But qmake is the one tool run directly by users, the
> > one tool that Qt Creator asks users to locate.
> >
> > It needs to be renamed..
> >
> > If you don't want to make it the default, then at the very least we
> > need to add the option to our configure script to force the renaming.
> > We need to adapt our buildsystem to creating the renamed tool. This
> is
> > not debatable... we simply need to do it in Qt.
> >
> > I don't want distribution packagers choosing different methods: I
> want
> > them all to have the same solution, the one solution that will be
> > recommended to LSB 5.0, the one solution that the helpful people in
> > #qt, interest@ and other discussion channels will need to know.
> >
> > In other words, the renaming will be the de-facto default for
> everyone
> > using Linux.
> >
> > Why the hell shouldn't it be the de jure default too?
> 
> As it turns out, we may not need to rename it. Let's just take it out
> of /usr/bin, along with the other binaries. Let's put them into
> /usr/lib/qt5/libexec for example. (Heck, distros can tweak that via
> configure if they want to).
> 
> If instead we had a proper equivalent of "qset" as a real program that
> would allow changing between different Qt versions easily, then it
> wouldn't matter where that qmake binary is. If it's in
> $HOME/dev/qt5/qtbase/bin or in /usr/lib/qt5/libexec/ - I would use "qt
> qmake" and depending on what my current Qt version is, it would call
> the right qmake binary.
+1
It should also be possible to just use "qmake" (instead of "qt qmake") 
by using aliases. (But that's just sugar on top)

Jan Arve

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

Re: [Development] Summary of renaming changes

[Ziller Eike]

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 have been renamed:
>> So... You just don't care about the calls from myself and others to
>> leave the names alone instead install newly-named (aliased) things into
>> common directories (ie. /usr/bin) as is standard practice for other
>> things that get co-installed?
> 
> I'm not ignoring. I was just summarising the effort I've done so far. I'm 
> posting it so we can review it and correct further, if needed.
> 
>> eg.
>> 
>> /usr/bin <-- something special has to be done here, (eg. qmake-qt5 or
>> qmake as a symlink to a specific Qt install)
>> /usr/lib/qt5/bin <-- binaries go here with their NORMAL names
> 
> Thanks, but I don't think that solves many problems. That extra path would 
> exist only for people like you or I who are used to them. I don't see further 
> use for them. Here's why:
> 
> 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".
If we set the standards for distributions to have also e.g.
/usr/lib/qt5/bin/qmake
in addition to a symbolic link from /usr/bin/qmake to the "current" setting,
a script can take "qmake" from the PATH (which can be set to whatever), and ask 
it where the other things are.

> For example, a 
> buildsystem needs to search for qmake5 or qmake-qt5. And it needs to find 
> qmake 
> so that it can query where the other binaries are located, as they could be 
> in:
>   /usr/lib/qt5/bin
>   /usr/lib64/qt5/bin
>   /usr/lib/i386-linux-gnu/qt5/bin
>   /usr/local/lib/qt5/bin
>   /home/thiago/obj/qt/qt5/qtbase/lib/qt5/bin
>   and so forth
> 
> The tool cannot depend on the legacy path being on $PATH or that, if it is on 
> $PATH, that the Qt 5 path comes before the Qt 4 one. Besides, we as 
> helpgivers 
> cannot depend on that either when giving advice: we need to tell people to 
> run 
> "qmake5".
> 
> What's more, this creates more work for us (well, for me, since I'm the one 
> doing this). Adding symlinks in either direction is very hard, especially 
> since they don't work on Windows. The tool would need to be copied instead[1].
> 
> I did propose that we move all binaries except qmake

Why leave qmake out of the equation?

> and the end-user 
> applications to a "libexec" dir, which is basically what that dir of yours 
> is. 
> It didn't happen because, as I was starting this effort, I was convinced to 
> go 
> for the option of renaming everything instead: moc, uic, rcc, etc.  are well-
> defined tools with well-defined interfaces, manuals, etc.. They are not 
> internal 
> helpers.
> 
> [1] we already copy the .dll files because of that problem and the DLLs are 
> much larger, so copying the executables is no big deal.
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Summary of renaming changes

[Ziller Eike]

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 is in Environment > External Tools, you 
can define any executable to run there with arguments etc, and a menu item for 
the tool will be shown in Tools > External.

E.g. we ship by default with an external tool definition for running lupdate 
and lrelease, and the "executable" we run is defined as:

%{CurrentProject:QT_INSTALL_BINS}/lrelease

Qt Creator resolves that variable in there by taking the current project, 
taking the current Qt version setting for that project, and asking that Qt 
version for "qmake -query QT_INSTALL_BINS".

At the moment that should work for Qt4 and Qt5.
If you rename lrelease to lrelease5 (or any other tool that we ship), this is 
no longer possible and gets pretty fancy.

++ Eike

On 19 Oct 2012, at 01:10, Thiago Macieira  wrote:

> On sexta-feira, 19 de outubro de 2012 01.03.29, André Pönitz wrote:
>> On Thu, Oct 18, 2012 at 08:30:03AM -0700, Thiago Macieira wrote:
>>> lconvert-> lconvert5
>>> lrelease-> lrelease5
>>> lupdate -> lupdate5
>> 
>> Sorry, I don't get the joke.
> 
> Because it was no joke. It's serious.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] New high-dpi QPen proposal

[Uwe Rathmann]

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-project.org/mailman/listinfo/development

Re: [Development] renaming qmake for everyone (was: Re: Co-installation & library naming rules=)

[Ziller Eike]

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 don't have to set standards for MacPorts/Homebrew.

>> On Mac, Qt will either be self-compiled (you are on your own which is fine),
>> or installed through our binary installers - which will install different
>> Qt versions (version + tool chain specific) into different directories
>> (http://qt-project.org/wiki/Qt5_beta2_component_tree) so there is no
>> conflict either. Same situation like on Windows, except that Windows has
>> the environment set up thingies.
> 
> That's the SDK hierarchy. The Libraries Only install does a global install 
> with frameworks, but frameworks suffers from not being renameable.

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 
Xcode doesn't do a global install anymore, except if you really really really 
force it, then you can install the command line tools globally (only one 
version simultaneously), but not the SDKs).

Frameworks are not renameable, but solve the "major version" problem anyhow, so 
why rename them.

>> Developers who distribute their Qt application on Windows and Mac usually
>> ship a private Qt copy with their application --> no conflict. But even if
>> they install Qt systemwide, we are using frameworks on Mac which
>> automatically do versioning for major versions if done right, and we are
>> adding the major version to dlls on Windows already.
> 
> Yup.
> 
> What I haven't understood yet is how you select a different version besides 
> "Current" in Mac frameworks.

You don't  select different versions besides "Current".
1) Runtime linking is done against a specific version 
"QtGui.framework/Versions/4/QtGui" anyhow, so at runtime the right version is 
taken
2) You just don't use a global framework install for development. Or if you do, 
you live with developing against "Current" (which is linked into the binaries 
as a specific version). The globally installed framework is a real exception on 
Mac: I have a total of 9 frameworks in /Library/Frameworks, 6 of them start 
with "iLife" or "iTunes". There are basically no globally installed dylibs on 
Mac besides the system ones, and there's no standard for putting them anywhere 
either.

Point is: We don't need to optimize for the uncommon case, while making 
everything more obscure for the common case.

>> The only thing that would be solved is how Linux distributors can install
>> multiple (major) versions of Qt simultaneously.
> 
> Right.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] RFC: Qt Security Policy

[André Somers]

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-project.org 
 address for your elitist club.

D3fault,

Really: behaving like a baby won't get you the candy you're whining for. 
That might work with your mother, but not here. Please, either grow up, 
or shut up. You're not helping anyone. You may not agree with the 
decision taken, but the grown-up thing to do is to accept that and move 
on. You simply won't win all arguments in life, and some voices here 
(such as Thiago's) carry more weight than others (such as yours or mine) 
based on their trackrecord in the community. And rightly so.


Please focus your energy on more productive ventures.

André

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

Re: [Development] Summary of renaming changes

[Shaw Andy]

> 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, at 5:30 PM, Thiago Macieira 
> wrote:
> 
> > After all of my patches are integrated, here are the changes that will
> happen:
> >
> > - bin:
> > The following tools have been renamed:
> > qmake   -> qmake5
> 
> This one is visible to the developer.

This is the one that's going to be hard for people to swallow the most 
especially on Windows as there the whole setup is straightforward as you just 
ensure you have the one version of Qt in your path and thus it will point to 
the right one.  I've been doing this for a long time as do a number of people I 
have communicated with in the past even within the Qt 4.x range because one 
version of qmake is strictly speaking not compatible with the other even from 
4.8.1 to 4.8.2 because it has hard-coded paths in it.  So you could still end 
up picking up the wrong version anyway and subsequently end up compiling and 
linking against the wrong version of Qt but generally at that level it is not a 
big problem at least.

Is there no way we could compromise on this?  For instance by adding a symlink 
or something like that so that if someone types qmake it will invoke qmake5, 
that way if the distributors don't want that they can just remove it and then 
everyone is happy, the docs would refer to qmake5 and there is a solution there 
to help people transition over.  Granted I know that people could just add this 
themselves, but I get the feeling that I will be hearing a lot about this 
otherwise.

[snip]

> > lconvert-> lconvert5
> > lrelease-> lrelease5
> > lupdate -> lupdate5
>
> These tools are in-between, as they IMO get called both by build systems as
> well as by developers directly. But if they are not compatible with Qt 4, we
> can't really have the same name unfortunately.

For these I have the same problem as I do with qmake because they are invoked 
by the user directly too and thus the same suggestion about having a symlink 
stands in this case for me too.

[snip]

Maybe we should open this up for more feedback on a blog post perhaps?   A lot 
of the people would be using it aren't necessarily going to see the change here 
and therefore they may have some good comments on it.

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

Re: [Development] Summary of renaming changes

[Martin Smith]

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 controversial.
> 
> 
> To me this looks like a case where there clearly won't be a consensus, which 
> means we're going to need a Chief Maintainer decision at some point. I hope 
> we can all respect what ever that will be, and then move on.
> 
> Morten
> 

+1

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

Re: [Development] New high-dpi QPen proposal

[Uwe Rathmann]

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 pens also exist for Qwt, but are by far less 
important. So such a modification limits the number of Qwt applications 
that will be broken.

> We already set the render hint NonCosmeticPenByDefault on 
> GraphicsView ...

I'm not completely happy with a solution where Qwt sets some magic mode 
behind the scene, that is not set for usual QPainter use cases. But as 
the user seems to be used to such a thing from QGV ...

Uwe

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

Re: [Development] Summary of renaming changes

[Sorvig Morten]

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 clearly won't be a consensus, which 
means we're going to need a Chief Maintainer decision at some point. I hope we 
can all respect what ever that will be, and then move on.

Morten


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

Re: [Development] Summary of renaming changes

[Koehne Kai]

> -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 of renaming changes
> 
> On Oct 18, 2012, at 5:30 PM, Thiago Macieira wrote:
> 
> 
>   After all of my patches are integrated, here are the changes that will
> happen:
> 
>   - bin:
>   The following tools have been renamed:
>   qmake -> qmake5
>   moc -> moc5
>   uic -> uic5
>   rcc -> rcc5
>   qdbusxml2cpp -> qdbusxml2cpp5
>   qdbuscpp2xml -> qdbuscpp2xml5
>   lconvert -> lconvert5
>   lrelease -> lrelease5
>   lupdate -> lupdate5
>   xmlpatterns -> xmlpatterns5
>   xmlpatternsvalidator -> xmlpatternsvalidator5
> 
>   qmlviewer -> qml1viewer
> 
> 
> This should be just qmlviewer (as it was in Qt 4.8).. I dont see a reason for
> this renaming..

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 intuitive, is it ? :( Also, what happens if we release a Qt 6 with 
a qml 2 compatibility viewer?

Thinking about it, I'd rather keep the qmlviewer, qmlscene names, and go for

qmlviewer -> qt 4
qmlviewer5 -> qt 5 , qtquick 1
qmlscene5 -> qt 5 , qtquick 2

> 
>   [qml1plugindump had already been renamed]
> 
> 
> This should be reverted back to qmlplugindump .. (Same reason as above..
> For QtQuick2, the related binaries can be renamed to qml2* (to reflect the
> version change)
> 
> 
> 
>   qmlscene -> qml2scene
> 
> 
> This should be qml2viewer.
>
>   qmlplugindump -> qml2plugindump

I have two problems with the 'qml2x' names:
 - It can be misread as a qml _to_ x converter tool
 - What happens if we have a QML2 compatibility module in qt 6? 

I think we should go therefore for following the names from the other modules, 
and just add a '5' at the end for tools that we probably cannot promise 
compatibility for in a hypothetical Qt 6. The only exception being 
qmlplugindump, because there are two versions of it even in Qt 5:

qml1plugindump5
qml2plugindump5

>   qmlbundle -> qml2bundle

qmlbundle5

(yes, it cannot be used with Qt Quick 1, but that's a documentation issue)

>   qmlmin -> qml2min

I'd be very surprised if qmlmin cannot also handle .qml files from QtQuick1 (Qt 
5 or Qt 4) -> can stay qmlmin.

>   qmlprofiler -> qml2profiler

qmlprofiler5

(yes, it cannot be used with Qt Quick 1 right now, but that's a documentation 
issue. If there's demand we could even make it compatible ...)

>   qmltestrunner -> qml2testrunner

qmltestrunner has an option to run with Qt Quick 1 -> can stay qmltestrunner.

>   The following tools require more information:
>   qdoc: not renamed because the Qt 4 version was called "qdoc3"
>   qhelpgenerator, qcollectiongenerator, qhelpconverter: they
> apparently
>   keep backwards compatibility, so they should replace the Qt 4
> versions
>   qglinfo: new tool from qt3d
> 
>   The following are user applications and they have not and will not be
> renamed:
>   qdbus
>   qdbusviewer
>   assistant
>   designer
>   linguist
>   creator
>   pixeltool
> 
>   - lib:
>   All libraries are now called libQt5Name.so.5 on Unix systems,
>   libQt5Name(_debug).5.dylib on Mac, Qt5Name(d).dll on Windows.
> This also
>   applies to the qmake .prl files, the libtool .la files and the 
> pkg-config
> .pc
>   files. The cmake files had already had the "5".
> 
>   EXCEPT in Mac Framework builds. Since the header search path
> takes the
>   framework's name, for source compatibility, the framework builds
> did not get
>   the "5" in the name.
> 
>   - include:
>   No change.
> 
>   - doc:
>   On Windows builds and on -no-prefix-install builds, no change.
> Otherwise, the
>   default install path is now $prefix/share/qt5/doc.
> 
>   Question: should it be $prefix/doc/qt5 to match autoconf's default?
> 
>   - mkspecs:
>   On Windows builds, on -no-prefix-install builds, and on builds with -
> hostprefix,
>   no change. Otherwise, the default install path is now
> $prefix/lib/qt5/mkspecs.
> 
>   - plugins:
>   The default install path is now $prefix/lib/qt5/plugins on all
> systems.
> 
>   - imports:
>   The default install path is now $prefix/lib/qt5/imports on all
> systems. It
>   applies to QML 1 and Qt Quick 1 only.
> 
>   QML2 imports go to "qmldir", which defaults to $prefix/lib/qt5/qml
> on all
>   systems.
> 
>   --
>   Thiago Macieira - thiago.macieira (AT) intel.com
>Software Architect - Intel Open Source Technology Center
>   ___
>   Develop

Re: [Development] highlight/background colour of active tabs

[André Somers]

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 tab is regarded as the general background 
> colour, and this is misleading, better would it be, if all tabs not 
> active are light-grey, (as any other frame colour) and the ACTIVE tab 
> is default  dark-grey (or alternatively white).
> e.g. in the qt web browser http://dooble.sf.net you can see this 
> phenomen. Can someone swith the active tab colour either to white, or 
> switch the non-active tabs to light-grey and the active tab to dark-grey?
>
Well, this is of course style dependent. What style are you talking about?

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

Re: [Development] Summary of renaming changes

[Knoll Lars]

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, at 5:30 PM, Thiago Macieira  wrote:

> After all of my patches are integrated, here are the changes that will happen:
> 
> - bin:
> The following tools have been renamed:
>   qmake   -> qmake5

This one is visible to the developer.

>   moc -> moc5
>   uic -> uic5
>   rcc -> rcc5
>   qdbusxml2cpp -> qdbusxml2cpp5
>   qdbuscpp2xml -> qdbuscpp2xml5

Do we need to rename the dbus tools? They are compatible afaik.

But the name changes should be mostly invisible to developers as the tools are 
being called by the build system.

>   lconvert-> lconvert5
>   lrelease-> lrelease5
>   lupdate -> lupdate5

These tools are in-between, as they IMO get called both by build systems as 
well as by developers directly. But if they are not compatible with Qt 4, we 
can't really have the same name unfortunately.

>   xmlpatterns -> xmlpatterns5
>   xmlpatternsvalidator -> xmlpatternsvalidator5

The xmlpatterns tools don't need renaming IMO. Nothing has changed there, and I 
don't think they will.
> 
>   qmlviewer -> qml1viewer
>   [qml1plugindump had already been renamed]
> 
>   qmlscene-> qml2scene
>   qmlplugindump -> qml2plugindump
>   qmlbundle -> qml2bundle
>   qmlmin -> qml2min
>   qmlprofiler -> qml2profiler
>   qmltestrunner -> qml2testrunner

Feels weird/wrong that we use qml1 and qml2, since we just renamed the QML 
1/Quick 1module to QtDeclarative, and are trying to avoid the 2 for marketing 
as well.

Maybe use declarativeviewer and qmlscene instead?

> 
> The following tools require more information:
>   qdoc: not renamed because the Qt 4 version was called "qdoc3"
>   qhelpgenerator, qcollectiongenerator, qhelpconverter: they apparently 
>   keep backwards compatibility, so they should replace the Qt 4 versions
>   qglinfo: new tool from qt3d

These should be ok as is.
> 
> The following are user applications and they have not and will not be renamed:
>   qdbus
>   qdbusviewer
>   assistant
>   designer
>   linguist
>   creator
>   pixeltool
> 
> - lib:
> All libraries are now called libQt5Name.so.5 on Unix systems, 
> libQt5Name(_debug).5.dylib on Mac, Qt5Name(d).dll on Windows. This also 
> applies to the qmake .prl files, the libtool .la files and the pkg-config .pc 
> files. The cmake files had already had the "5".
> 
> EXCEPT in Mac Framework builds. Since the header search path takes the 
> framework's name, for source compatibility, the framework builds did not get 
> the "5" in the name.

Don't see a problem with this, as it's transparent to the app developer.

>  - include:
> No change.
> 
> - doc:
> On Windows builds and on -no-prefix-install builds, no change. Otherwise, the 
> default install path is now $prefix/share/qt5/doc.
> 
> Question: should it be $prefix/doc/qt5 to match autoconf's default?

The second option is less linux centric, but is not being used by distributions 
afaict. I think distributions use either
/usr/share/doc/qt5 or /usr/share/qt5/doc.
> 
> - mkspecs:
> On Windows builds, on -no-prefix-install builds, and on builds with 
> -hostprefix, 
> no change. Otherwise, the default install path is now $prefix/lib/qt5/mkspecs.

Sounds ok.
> 
> - plugins:
> The default install path is now $prefix/lib/qt5/plugins on all systems.

Ok as well.
> 
> - imports:
> The default install path is now $prefix/lib/qt5/imports on all systems. It 
> applies to QML 1 and Qt Quick 1 only.
> 
> QML2 imports go to "qmldir", which defaults to $prefix/lib/qt5/qml on all 
> systems.

Both ok for me.

Most of the changes above only affect build system maintainers, or people doing 
packaging. So in the end the discussion seems to boil down to the problem of 
renaming qmake, the one build tool that's very visible to developers.

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.

On the plus side, this should then also be the main change that's visible to 
developers, and I don't think it's going to be a huge problem. For those of us 
using in-tree builds (and Qt4/Qt5 builds in parallel), we could simply extend 
the qset shell script many people are using to also add an alias from qmake to 
qmake5 when calling qset with a Qt 5 based Qt.

Cheers,
Lars

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

Re: [Development] Summary of renaming changes

[Koehne Kai]

> -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] Summary of renaming changes
> 
> [...]
> So I'm going to recommend renaming qmlviewer and qmlplugindump back
> to the Qt
> 4 names and call them "applications". Distributions will not co-install both:
> one simply upgrades them and keeps *all* of the functionality.

Especially for qmlplugindump I don't agree. Its sole use right now is to get 
meta information about a QML plugin for Qt Creator code completion: It's either 
called internally from Qt Creator, or the plugin developer can also explicity 
dump the information to a .qmltypes file e.g. in the build process of the 
plugin. Now, experience shows people often rather live with broken code 
completion in Qt Creator compared to having any hassle with qmlplugindump, so 
asking them to always compile their plugins with latest Qt 5 just to get code 
completion won't work.

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 component sets 
...

Regards

Kai

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development