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
signature.asc
Description: This is a digitally signed message part.
-- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
