KDE apps non Windows and mac Was: Re: Kill KIO (was: Repositioning the KDE brand)

[Jaroslaw Staniek]

2009/7/14 Pau Garcia i Quiles <pgquiles at elpauer.org>:
> On Tue, Jul 14, 2009 at 8:34 PM, Alexander Neundorf<neundorf at kde.org> wrote:
>> On Tuesday 14 July 2009, Thiago Macieira wrote:
>>> Em Terça-feira 14 Julho 2009, às 16:19:07, Boudewijn Rempt escreveu:
>> ...
>>> > > What could be considered wrong is if there's a nice feature that
>>> > > doesn't depend on anything of the "platform-y" stuff. If that's the
>>> > > case, then it should be moved upstream through the libraries. (Or the
>>> > > case of features that do depend on those things, but for silly reasons,
>>> > > like our locale formatting routines requiring KConfig)
>>>
>>> KDE libs, IMHO, should remain focussing on "the best desktop".
>>>
>>> And, that said, I also believe KDE applications should be "the best
>>> applications" and that may mean deviating from the platform where
>>> necessary. Therefore, I do want Krita to be the best app you can get on Mac
>>> and Windows. And if that brings in kded, klauncher and the D-Bus daemon, so
>>> be it.
>>
>> I think we have a problem if even Boudewijn sees it as a problem to depend on
>> KDE libraries on non-Linux.
>> I can/could understand this concern in KDE 2/3 days, but with KDE 4 we should
>> be able to make that work smoothly, now that Qt is LGPL everywhere and our
>> software is (more or less) fully portable.
>>
>> How can we do that ? I don't know. I think the Windows and Mac developers need
>> to help here.
>> Maybe provide a dead-easy to install "KDE environment" package which brings
>> everything you need to run a full blown KDE application ?
>
> This is quite off-topic here but still:
>
> On Windows, I have been suggesting for a long time we make
> redistributable packages for kdelibs (for instance, "kdelibs 4.3
> redistributable runtime") which includes kdelibs and all its
> depencencies. The same goes for kdepimlibs and kofficelibs.
>
> Add side-by-side assemblies (
> http://en.wikipedia.org/wiki/Side-by-side_assembly ) features to those
> redistributables and now you can have kate for kde 4.3 installed and
> okular for kde 4.4 installed and you only need a single copy of
> kdelibs in your system for all the applications.
>
> We would still have the problem of the third-party dependencies for
> kdebase applications, kdegraphics, applications, etc. As creating so
> many redistributable runtime packages would be a bit confusing and
> tedious to users installing KDE applications, IMHO the kdelibs
> redistributable should include all the dependencies for all the
> applications in kdebase, kdegraphics, etc.

Pau, I remember we've been discussing this in Belgium.
The question is why would deps of KOffice not get there?
If you say "ok" then there's a problem: the deps are huge and change
from time to time (to say at least).
Deps for kexi and krita alone is going to make the redistributable
package the biggest than deps of MS Office.

I find that the reason of existence of redeist. packages is that MS
controls their contents and their dependencied. We are not, what is
clear rule of FOSS development.

That's why I liked and still like the fine-grained splitting to
packages and _good_ dedicated installer, more importantly: the
installer we can control, independent on OS differences between Vista
and Windows 7/8/whatever.
Also, the more splitted packages are, the cheaper installation of
multiple versions is. What I try to say is that sidebyside assemblies
are not silver bullets. They may encourage for accepting redundancy.
See what windows vista update did with my space:
% cd windows/winsxs/ ; du -h
[..]
7.5GiB .

That's a lot of side-by-side not-uninstalled dirt, considering that it
does not include MS Office of Java (that resides in program files). On
the fine-grained-packaging-type-of-OS, my _fat_ linux system with 2
java versions and openoffice, /usr/lib takes 2GiB, /usr - 4GiB (even
with some source code..).

> What I am proposing is certainly not the best solution (it takes an
> awful lot of space) but at least it makes distributing a KDE
> application on Windows easier than now (the KDE on Windows installer
> works very well but it's very confusing to users).

It can be addressed and I am sure it will be. The developers base
grows and more apps are written without excluding non-linux OSes.

> As for updating applications, we could have a KDE Update applet, like
> Google, Real Player, etc have (for instance, using Google Update
> Engine: http://code.google.com/p/update-engine/ )

We still can use this feature as a part og the KDE for Windows
installer, right?
BTW: Last I checked, leading apps like adobe's, sun's or google's
contain custom update tools; ignoring installation infrastructure of
Windows. IIRC this was another point not to consider depending on MS
tools _too much_: others and I did not hear users excaping from
Adobe/Google/SUN Java/whatever apps because their update/installation
tools are custom.

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org)
 KDE Libraries for MS Windows (http://windows.kde.org)
 http://www.linkedin.com/in/jstaniek
_______________________________________________
Kde-windows mailing list
Kde-windows at kde.org
https://mail.kde.org/mailman/listinfo/kde-windows