[kubuntu-devel] Re: debugging and conf file location

Harald Sitter apachelogger at ubuntu.com
Wed Nov 10 18:19:44 GMT 2010


On Wednesday 10 November 2010 17:22:31 Jonathan Riddell wrote:
> On Wed, Nov 10, 2010 at 06:17:17PM +0100, Harald Sitter wrote:
> > On Tuesday 09 November 2010 15:06:17 Jonathan Riddell wrote:
> > > Anyone remember why we have QT_NO_DEBUG set but we still get debug
> > > output (some turned on by default)?
> > 
> > Where do we have QT_NO_DEBUG?
> 
> 08_add_debian_build_type.diff in kde4libs (and every build log)

Oh. Well. That will only affect kDebug(), on my system the most useless 
messages come from Qt though (size/position warnings in plasma, ibus ...). 
Hence I think we should also define it at Qt level. Combined with kdebugrc this 
should get rid of every debug message by default.

> > > As a separate issue, maybe we should move our config files to
> > > /usr/share/config/
> > 
> > How does /usr/share/config play into any of this?
> > Maybe you mean /usr/share/config/kde4? In that case there would be a
> > problem since that is where some apps have their default configs...
> 
> Maybe I ment /usr/share/kde4/config :)
> 
> Yes that's an issue.

Let's approach the problems from another angle.
I think the main concerns here are:
- setting kds in /etc/kde4rc affects also custom (developer) builds of KDE
- possibility of increased startup time

...The first one we could probably resolve by patching kds into the search path 
of our KDE, rather than doing it via the config.

...The second one I still would like to see actual data on, what the config 
cascading does is only adding additional path lookups for every config. I do 
however believe that this is neglectable overhead, I think we are looking in 
more paths for libraries than for configs for instance.

What is expensive about this is the actual cascading (i.e. the merging of 
multiple configs (worst case: user-kdeglobals>etc-kdeglobals>kds-
kdeglobals>kd[n/m]s-kdeglobals). We cannot do much about this. user and etc 
are given, kds is a necessary evil to not patch around wildely. However, the 
additional cascading of netbook/mobile settings could be improved.

I mentioned this briefly when Rodrigo and I were talking about speed at UDS, 
however I do not think I elaborated this.

The general idea is to introduce install-time-cascading. Since each of netbook 
and mobile overrides settings in kds, you could merge kds with the given 
specific type, into say kubuntu-default-settings-merged, at the time the 
specific package gets installed. In startkde, then instead of exporting both 
the specific path *and* kds, they would only export the merged path, hence 
removing one level of the cascade.

Although. Thinking about it... One maybe could use the same approach to get 
kds into /usr/share/kde4/config...

If we got our packages to install files to /usr/share/kde4/config-raw, then 
trigger a script upon changes in that directory as well as 
/usr/share/kde4/config-kubuntu, the trigger can then merge them into 
/usr/share/kde4/config.

See [1] for some info on dpkg triggers. They are for example used to keep the 
GTK icon cache updated (e.g. see hicolor)

Opinions?

[1] http://www.seanius.net/blog/2009/09/dpkg-triggers-howto/

-- 
Harald Sitter
Kubuntu Core Developer
http://www.kubuntu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20101110/98cb85f0/attachment.pgp 


More information about the kubuntu-devel mailing list