Kill KIO (was: Repositioning the KDE brand)

[Boudewijn Rempt]

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 
trouble.

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
> Windows?
>
> > * 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