Qt KDE integration in kdereview.

[Kevin Krammer]

On Wednesday, 2009-11-04, Olivier Goffart wrote:
> Le Wednesday 04 November 2009, Kevin Krammer a écrit :
> > This cmake parameter makes the documentation wrong or at least not
> > precise enough, which is really a pity.
> > Variables that can be unset or empty should have specified defaults so
> >  third parties implementing their own code can rely on that.
> >
> > Has this always been overridable this way or is this a recent (KDE4)
> >  addition?
> 
> I think it is new since KDE4 but i might be wrong.

Most likely. Don't like it but there's nothing we can do about this now.
Whoever added it should thinkg about fixing our docs though.

> > True. Lettings KDE handle these things is definitely better.
> > Will avoid problems like the current heuristics in Qt which mistakenly
> >  prefer .kde4 over .kde instead of the other way around (preferring
> >  canonical default over one potential override).
> 
> The thing is: in practice, many distribution had .kde4 for kde4 and .kde
>  for kde3 applications.
> When we detect we are running in a kde4 desktop (again heuristics), we
>  prefer .kde4 if it exists.

I understand the intentions but IMHO this "solution" emerges from too closed 
thinking.
True, some installations have modified defaults, either patched or through t 
cmake parameters. Anyone changing defaults of important environment variables 
will of course grep for them in other sources to make sure to change the 
defaults there as well.
Especially in the case of Linux distributors, because they care about their 
users' experience.

This is not something you as the provider of Qt have to work around. In fact 
you working around any broken system, makes the experience for everyone with 
correct setups worse. Now those with unchanged defaults have to explicitly 
pathc Qt to remove your workaround.

> Now, we had the case of people that had a .kde4 in their /home because they
> tested development version at some point, and now use the distro package
>  that uses .kde, and Qt get it wrong.

Or people testing experiemental packages and then using the real ones, or 
people where packages for KDE3 switch from .kde to .kde3 and packages for KDE4 
switch from .kde4 to .kde

There are just too many combinations to get it right, and the ones who can do 
it correctly, i.e. those who change the defaults in the first place, might not 
even be aware of your adaption because it hides the problem they created.

It is basically a silent catch of somebody esle's mistake, an error hiding 
another.

If Qt Development Framworks really wants to give people with intentionally 
differing setups a free pass, do slap those with KDE as we provide it.
Maybe the code could check if .kde exists and if it contains something KDE4 
specific, e.g. plasmarc, before doing the fallback for broken setups which 
have modified KDE but not Qt.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091105/01e065b4/attachment.sig>