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
See  for some info on dpkg triggers. They are for example used to keep the
GTK icon cache updated (e.g. see hicolor)
Kubuntu Core Developer
kubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel