Kill KIO (was: Repositioning the KDE brand)
boud at valdyas.org
Wed Jul 22 07:38:22 BST 2009
On Monday 20 July 2009, Alexander Neundorf wrote:
> On Monday 20 July 2009, Boudewijn Rempt wrote:
> > On Friday 17 July 2009, Alexander Neundorf wrote:
> > > Can you make a list of concrete things which are problematic for you as
> > > it is now ?
> > Well, basically the things Thiago mentioned earlier:
> > * anything that needs to run another process than my application (kded,
> > kglobalacceld, klauncher, knotify, dbus...)
> I think dbus is something we should want to have also in Windows. We are
> not the only project using dbus, so if it is easy to have dbus working on
> Windows, other (non-KDE) free software projects may use it too.
> The other things, aren't they started automatically when you start a KDE
> application and they are not yet running ?
If the installation is complete and correct, yes. But it almost forces us into
a unix-like dependency tree, because you don't want to package dbus and
everything else with your application, install it, try to start it, notice
another version started by another app is already running and then be in
And, on OSX, I've never seen them work correctly. That's probably fixable, but
fink and macports are hacks -- I cannot tell an artist from deviant art to try
Krita on his mac if he has to use either fink or macports. So I have to find a
a way to make a simple app bundle.
Now I used to care very little about this, because by preference I use KDE and
when I have to use something else, everything reminds me why I prefer KDE, but
people are asking about it, and if I provide something, I want to do it
properly. (For krita the issue is moot on windows, since we apparently wrote
C++ that Visual Studio cannot compile, and I don't have an environment to
figure out what I did wrong...)
> Which of them are necessary on Windows or Mac is a different question.
> > * anything that wants to finds installed stuff in some pre-ordained path
> > or file system structure.
> I.e. on Windows and Mac hardcoding/compiling in paths depending in
> CMAKE_INSTALL_PREFIX is bad, but locations should be determined at runtime
> relative to <something>. Isn't something like this already done under
> > * and for this particular issue, anything that adds size on disk or in
> > memory for something I am not using.
> I guess that's also true on Linux (... especially on low end
> netbooks/embedded systems/etc).
Yes, I was also thinking about that. Sometimes it's not worth the extra
features, and it would be nice if Qt papered over this; that if KDE platform
features are available, Qt uses it, but that I wouldn't have to code different
versions of my apps for when KDE is around and when it isn't.
And if I want to provide libraries that are generally useful, like KOffice's
odf library, I really want to have something that doesn't need KDE, but can
use it if it's present.
Boudewijn Rempt | http://www.valdyas.org
More information about the kde-core-devel