Kill KIO (was: Repositioning the KDE brand)

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

Adam Treat-2
On Monday 13 July 2009 12:36:35 pm nf2 wrote:
> However the devil is in the detatils. I can't tell if GIO/GVFS can
> really provide everything KDE needs. I tried to investigate with
> KIO-Giobridge for the most common protocols and that worked. But HTTP,
> POP3 might be hairy.

I wonder that you started this thread then?  You begged to kill KIO, but here
you state that you can't even be sure GVFS provides everything KDE needs.  
That either indicates an astonishingly reckless attitude or questionable
motivation.  And right after this you state, "really don't want to damage
KDE."  Can you explain this seeming contradiction?

Cheers,
Adam
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

Bugzilla from koos.vriezen@gmail.com
In reply to this post by nf2.email
2009/7/13 nf2 <[hidden email]>:
> On Mon, Jul 13, 2009 at 10:59 AM, Jos Poortvliet<[hidden email]> wrote:

> However the devil is in the detatils. I can't tell if GIO/GVFS can
> really provide everything KDE needs. I tried to investigate with
> KIO-Giobridge for the most common protocols and that worked. But HTTP,
> POP3 might be hairy.

I've posted a link to GVFS developer before when asking for the HTTP
redirect notification
Not sure if this is still the case, but you might make a try case of
nspluginviewer. Try embedded youtube videos.
Btw. didn't webkitgtk change curl for libsoup (ie. no gvfs in sight)?

More or less OT, since the main competitor or KDE might be chrome
soon, ever thought of  chrome/net? Nice BSD license, tested on
Mac/Linux/Win, works on phones, paid developers etc.

Koos
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

Alexander Neundorf
In reply to this post by Adam Treat-2
On Monday 13 July 2009, Adam Treat wrote:

> On Monday 13 July 2009 12:36:35 pm nf2 wrote:
> > However the devil is in the detatils. I can't tell if GIO/GVFS can
> > really provide everything KDE needs. I tried to investigate with
> > KIO-Giobridge for the most common protocols and that worked. But HTTP,
> > POP3 might be hairy.
>
> I wonder that you started this thread then?  You begged to kill KIO, but
> here you state that you can't even be sure GVFS provides everything KDE
> needs. That either indicates an astonishingly reckless attitude or
> questionable motivation.  And right after this you state, "really don't
> want to damage KDE."  Can you explain this seeming contradiction?

I think Norbert thinks that it would be better if there wouldn't be two
different VFS implementations (I don't really object to that).
Also I think that e.g. wrapping GFS inside KIO should be easier to do than
wrapping KIO inside GFS (I think GFS is more POSIX like, they can seek (or
can we too with KDE4 ?)), but I'm not sure about that. I think Norbert is
actually the one who knows this best.
And I guess the motivation for this thread was to find developers to join him
and try to do it (without damaging KDE).

Alex
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

Friedrich W. H. Kossebau-2
In reply to this post by Boudewijn Rempt-2
Lundi, le 13 juillet 2009, à 08:49, Boudewijn Rempt a écrit:

> On Sunday 12 July 2009, Harri Porten wrote:
> > What I find more sad is that a KDE dependency is always treated like
> > pestilence - even on KDE lists. People go out of their way to rewrite
> > things, dumb them down instead of simply linking against a library that
> > is already available. "Qt-only" is a misnomer anyway as e.g. QtGui links
> > against lots of other libraries already. If the feeling is that e.g. KIO
> > is too hard to distribute without pulling in all of kdelibs then more
> > modularization would be the way to go imo.
>
> I definitely think that much more modularization is needed. Because the
> libraries are intertwined instead of being like the teeth of a comb,
> separate, independent and providing just one thing, you need most of the
> kdelibs which makes it hard to cut down the size of your application, which
> is needed for some platforms.

+1

The rough split of the KDE foundation libraries into only kdelibs and
kdepimlibs seems to big a big hurdle. Let's follow Qt here (if this does it
as argument for some ;).

> For me, KDE as a development platform only really works when developing for
> a Unix desktop environment, and when I want to have my applications
> available on other platforms, I'll gladly trade down to Qt-only, losing
> some of the KDE smarts in return for ease of deployment and less memory
> usage.

Qt-only programs always makes me wonder what is wrong with the KDE libs, as
these are supposed to help for better programs.

Cheers
Friedrich
--
Okteta - KDE 4 Hex Editor - http://utils.kde.org/projects/okteta
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

Pau Garcia i Quiles
Hello,

> Qt-only programs always makes me wonder what is wrong with the KDE libs, as
> these are supposed to help for better programs.

One of the main hurdles on Windows is DBus. Then there's the awful lot
of KDE libraries you need to redistribute: most of what you distribute
are KDE libraries and its dependencies, and only a small part is your
actual application.

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

Boudewijn Rempt-2
On Tuesday 14 July 2009, Pau Garcia i Quiles wrote:
> Hello,
>
> > Qt-only programs always makes me wonder what is wrong with the KDE libs,
> > as these are supposed to help for better programs.
>
> One of the main hurdles on Windows is DBus. Then there's the awful lot
> of KDE libraries you need to redistribute: most of what you distribute
> are KDE libraries and its dependencies, and only a small part is your
> actual application.

It's the same on OSX. On OSX you don't want dbus (or knotify or that daemon
that never seems to run but makes sure the file dialogs work, I've forgotten
the name of that atm)

--
Boudewijn Rempt | http://www.valdyas.org
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

Thiago Macieira
In reply to this post by Pau Garcia i Quiles
Em Terça-feira 14 Julho 2009, às 11:06:06, Pau Garcia i Quiles escreveu:
> Hello,
>
> > Qt-only programs always makes me wonder what is wrong with the KDE libs,
> > as these are supposed to help for better programs.
>
> One of the main hurdles on Windows is DBus. Then there's the awful lot
> of KDE libraries you need to redistribute: most of what you distribute
> are KDE libraries and its dependencies, and only a small part is your
> actual application.

The problem is not the KDE libraries. Using kdecore, kdeui, kpty, kutils, etc.
is not a problem.

The "problem" is that the KDE libraries expect a KDE runtime environment. They
will read from sycoca (which may trigger running of kbuildsycoca4), they will
try and talk to kded, kglobalacceld, klauncher. KIO, in special, will ask
klauncher to start the ioslaves to do I/O.

And all of that requires D-Bus.

Qt is a simply a toolkit library, integrating with the platform. KDE, on the
other hand, *is* the platform, which means its libraries do "platform-y" stuff,
like launching daemons, collecting information about installed plugins,
requiring D-Bus. The libraries have their own concept of locale and settings,
completely separate from the rest of the system even!

The way I see it, there's nothing *wrong* with this picture.

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)

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Software
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

Boudewijn Rempt-2
On Tuesday 14 July 2009, Thiago Macieira wrote:

> Em Terça-feira 14 Julho 2009, às 11:06:06, Pau Garcia i Quiles escreveu:
> > Hello,
> >
> > > Qt-only programs always makes me wonder what is wrong with the KDE
> > > libs, as these are supposed to help for better programs.
> >
> > One of the main hurdles on Windows is DBus. Then there's the awful lot
> > of KDE libraries you need to redistribute: most of what you distribute
> > are KDE libraries and its dependencies, and only a small part is your
> > actual application.
>
> The problem is not the KDE libraries. Using kdecore, kdeui, kpty, kutils,
> etc. is not a problem.

Well, where they simply add bulk and dependencies while not providing
something over Qt, it's a problem. And, actually, the size _is_ a problem in
for some target platforms. Even just the size the library files take up on
disk or in the installer.

> The "problem" is that the KDE libraries expect a KDE runtime environment.
> They will read from sycoca (which may trigger running of kbuildsycoca4),
> they will try and talk to kded, kglobalacceld, klauncher. KIO, in special,
> will ask klauncher to start the ioslaves to do I/O.

Yes, that's a big problem.

> And all of that requires D-Bus.
>
> Qt is a simply a toolkit library, integrating with the platform. KDE, on
> the other hand, *is* the platform, which means its libraries do
> "platform-y" stuff, like launching daemons, collecting information about
> installed plugins, requiring D-Bus. The libraries have their own concept of
> locale and settings, completely separate from the rest of the system even!
>
> The way I see it, there's nothing *wrong* with this picture.

It does mean that a KDE application is not portable to other platforms; if you
try to do so, you drag the KDE platform with you, and that is undesirable. I
want Krita or any other app I am working on to be a Windows, an OSX, a Maemo,
an S60, a KDE application, not an application on of KDE on top of Windows,
OSX, Maemo, S60, whatever.

KDE is actually very similar to gnustep here: that also claims not to be a
desktop but a development platform, but the only platform where it is native
is its own desktop.

So, for my applications, I need to find a way to switch out the KDE libraries
when porting them to other platforms.

> 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)


--
Boudewijn Rempt | http://www.valdyas.org
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

Thiago Macieira
Em Terça-feira 14 Julho 2009, às 16:19:07, Boudewijn Rempt escreveu:

> On Tuesday 14 July 2009, Thiago Macieira wrote:
> > Em Terça-feira 14 Julho 2009, às 11:06:06, Pau Garcia i Quiles escreveu:
> > > Hello,
> > >
> > > > Qt-only programs always makes me wonder what is wrong with the KDE
> > > > libs, as these are supposed to help for better programs.
> > >
> > > One of the main hurdles on Windows is DBus. Then there's the awful lot
> > > of KDE libraries you need to redistribute: most of what you distribute
> > > are KDE libraries and its dependencies, and only a small part is your
> > > actual application.
> >
> > The problem is not the KDE libraries. Using kdecore, kdeui, kpty, kutils,
> > etc. is not a problem.
>
> Well, where they simply add bulk and dependencies while not providing
> something over Qt, it's a problem. And, actually, the size _is_ a problem
> in for some target platforms. Even just the size the library files take up
> on disk or in the installer.
If they didn't provide anything, they would be empty. They have something
there that they do provide.

There are classes building upon what Qt does, adding new functionality not
present in Qt. That's what I meant that it's completely fine.

>
> > The "problem" is that the KDE libraries expect a KDE runtime environment.
> > They will read from sycoca (which may trigger running of kbuildsycoca4),
> > they will try and talk to kded, kglobalacceld, klauncher. KIO, in
> > special, will ask klauncher to start the ioslaves to do I/O.
>
> Yes, that's a big problem.

The way I see it, there are two types of "platform-y" things:

1) unnecessary, done only because it was convenient to do so, like locale
formatting reading configuration files, timezone things communicating with
daemons, etc.

2) necessary, because the _real_ platform underneath doesn't provide the
functionality. This is the case of kglobalacceld, knotify, etc. And if you
want to go even further, KIO (the original topic of this thread) is also an
example. If there had been a VFS layer before KIO, we would have most likely
used it and not rolled out our own.

Now, from those two types again, there are things present in other
environments, like Windows, Mac and maybe Maemo too. (Maemo is a full platform
like KDE)

And the reason I wrote "problem" above in quotes is because I don't believe
this to be bad. It just is the way it is because the real platform underneath
KDE is so low that we have to build up far too much to get things done.

> > Qt is a simply a toolkit library, integrating with the platform. KDE, on
> > the other hand, *is* the platform, which means its libraries do
> > "platform-y" stuff, like launching daemons, collecting information about
> > installed plugins, requiring D-Bus. The libraries have their own concept
> > of locale and settings, completely separate from the rest of the system
> > even!
> >
> > The way I see it, there's nothing *wrong* with this picture.
>
> It does mean that a KDE application is not portable to other platforms; if
> you try to do so, you drag the KDE platform with you, and that is
> undesirable.
Desirable depends on who's asking.

I believe KDE libs should integrate into the platform as much as they can, if
they're not running on the KDE Workspace. That would mean using standard
global shortcut APIs on Mac and Windows instead of launching kglobalacceld,
for example.

But I also believe that KDE libs should use what technologies they have that
are better than what the other desktops have. This includes, for example, the
file dialog: I definitely don't want to see the GTK file dialog in my KDE
applications if I launch them in GNOME.

The point is that KDE libs don't have the same goal as Qt. Qt wants to
integrate to the platform where it is as much as possible, so that your app
can look native. KDE libs want to bring the best desktop experience you can
have and, if that means being different from the platform because we think
we're doing better, then so be it.

> So, for my applications, I need to find a way to switch out the KDE
> libraries when porting them to other platforms.

I think we need a "platformless" set of libraries, like you want. That is,
technically, Qt's goal, so those widgets and other APIs should be either in
Qt, or in Qt-related projects. See what I had written below:

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

PS: Maemo also has the D-Bus daemon, the equivalent of klauncher and many
daemons too. That only goes to prove what I said about the underlying platform
being far too primitive.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Software
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Alexander Neundorf
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 ?
Isn't that issue somewhat similar to programs installing their own copy of the
JRE ? For them it's usually no problem.

Alex
Reply | Threaded
Open this post in threaded view
|

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

Pau Garcia i Quiles
On Tue, Jul 14, 2009 at 8:34 PM, Alexander Neundorf<[hidden email]> 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.

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 would be a
matter of checking if the KDE 4.3 redistributable package is installed
and if it's not, tell the user to download and install it, just like
Microsoft does for Visual C++ 2005, 2008, etc.

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/ )

There are issues with DBus to implement this approach in case you have
two KDE runtimes installed (e. g. KDE 4.3 and KDE 4.4) but when I
talked about this with Holger Schöder at GCDS, he told me they should
be solvable.

The only reason I have not implemented what I'm proposing is currently
I'm too busy with work. In fact, I would not be able to start with
that until October, which may mean these will not be ready until KDE
4.5.

I don't know what's the situation in Mac but I guess a similar
approach (distributing 2-3 huge packages with all the required
libraries, daemons, etc) might also work.

> Isn't that issue somewhat similar to programs installing their own copy of the
> JRE ? For them it's usually no problem.

AFAIK, most applications will tell you to install the latest JRE
version from Sun. Only a few dinosaurs (OpenOffice.org, Oracle and so)
would install their own version.


--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Reply | Threaded
Open this post in threaded view
|

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

Gary Greene-5
In reply to this post by Alexander Neundorf
On 7/14/09 11:34 AM, "Alexander Neundorf" <[hidden email]> 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 ?
> Isn't that issue somewhat similar to programs installing their own copy of the
> JRE ? For them it's usually no problem.
>
> Alex

In many ways this is no different than the people that make Gtk+ apps for
Windows too. They have to bundle up all the Gtk+, Glib, Pango, Bonobo, and
Cairo libs themselves, or do it via a unified community package.

--
Gary L. Greene, Jr.
IT Operations
Minerva Networks, Inc.
Cell:  (650) 704-6633
Phone: (408) 240-1239

Reply | Threaded
Open this post in threaded view
|

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

Boudewijn Rempt-2
In reply to this post by Alexander Neundorf
On Tuesday 14 July 2009, Alexander Neundorf wrote:

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

That's probably part of the problem. I've tried to run KOffice on Windows, on
OSX and on Maemo -- and everywhere that runtime environment consisting of
daemons tied together with dbus was a pain. Making a krita installer for
windows, using cpack or bitrock, is hard. I've never been able to get a
version of Krita running on OSX that enabled me to open files using the file
browser. Of course, I'm not the smartest developer around, but, well, I should
have a better chance than most users who aren't into software the way I am,
and I cannot see any way of making an app bundle for krita like I've made at
work.

Because in the meantime I've been developing a Qt-based application at work
that we've delivered to a few hunderd thousand users on Windows, OSX and
Linux, and apart from Phonon (which caused crashes on Linux and couldn't play
.wav on XP or mp3 on Vista and vice versa or the other way around), we never
had a problem that wasn't caused by the platform itself or by clear bugs in
Qt, not by design problems in Qt.

> 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 ?
> Isn't that issue somewhat similar to programs installing their own copy of
> the JRE ? For them it's usually no problem.

Well, for a lot of people, the JRE _is_ a hurdle to far, and for the JRE, the
situation isn't as bas as with KDE: it's fairly small, you can bundle it as
one neat package that's smaller than Qt and it doesn't need all kinds of
processes to run in addition to your application.

It's really the platform stuff Thiago described so much better than I can
that's not worth the trouble. If we'd use something special like plasma,
perhaps, yes, it might be worth it. But kio doesn't add enough for the
ordinary user, and QSettings is good enough that we don't need kconfig.
There's a cheap and cheerful statically linkable zip storage lib so we don't
need ktar/kzip. I don't want my plugins all over the system, but neatly in the
app bundle/directory, so I don't need the query stuff, qpluginloader is good
enough. The KDE version of the widgets aren't as similar to the platform
widgets, so I don't want them either, they may be nicer, but users don't want
them -- and so on. Plus, it takes memory we might not have available.

Personally, I'd prefer to write a Qt-only program and have Qt adapt to the KDE
platform, like it adapts to Windows, OSX, Maemo, Gnome or S60, i.e, the
hierarchy is exactly the wrong way around.

--
Boudewijn Rempt | http://www.valdyas.org
Reply | Threaded
Open this post in threaded view
|

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

Thiago Macieira
In reply to this post by Pau Garcia i Quiles
Pau Garcia i Quiles wrote:
>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.

kdelibs + kdebase-runtime. KDE applications are useless without the
runtime.

--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

Boudewijn Rempt-2
In reply to this post by Thiago Macieira
On Tuesday 14 July 2009, Thiago Macieira wrote:

> If they didn't provide anything, they would be empty. They have something
> there that they do provide.

But can they earn their keep?

> There are classes building upon what Qt does, adding new functionality not
> present in Qt. That's what I meant that it's completely fine.

For my purposes, KPushButton, KComboBox, KApplication, KMessageBox just add
api and platform L&F integration -- nothing of intrinsic value. And nothing
users of Krita on another platform expect -- or would be able to discover,
even. And if the choice is between krita and no krita, not even the network
transparency of kio or the menu merging of kxmlgui will help.

> The way I see it, there are two types of "platform-y" things:
>
> 1) unnecessary, done only because it was convenient to do so, like locale
> formatting reading configuration files, timezone things communicating with
> daemons, etc.
>
> 2) necessary, because the _real_ platform underneath doesn't provide the
> functionality. This is the case of kglobalacceld, knotify, etc. And if you
> want to go even further, KIO (the original topic of this thread) is also an
> example. If there had been a VFS layer before KIO, we would have most
> likely used it and not rolled out our own.

If the platform doesn't provide those, what use are they? Users don't know
they will be there, and for things like knotify, would be well out of it. On a
mac, you have growl, or nothing. And more than growl is not something any mac
user expects -- so Qt's growl support is sufficient.

> Now, from those two types again, there are things present in other
> environments, like Windows, Mac and maybe Maemo too. (Maemo is a full
> platform like KDE)

Yes, that's one of the platforms I've been playing with. On maemo, since mini-
sd cards are no longer available, I need to fit krita in the internal memory.
With KDE, that won't work. On OSX, I've never been able to get a setup where I
could open a file using the file dialog, and even getting there was hell. On
Windows -- I've been able to install everything using the wonderful KDE
installer for windows, but that's not something I'd expect ordinary users to
use. They want a bitrock installer.

Now, personally, I don't want to lose all the nice KDE things, when working on
and in my chosen platform. Compared to KDE, I feel clumsy everywhere else. But
they are KDE advantages, so I'd like to abstract them away, and have Krita use
those facilities only when running on KDE.

> And the reason I wrote "problem" above in quotes is because I don't believe
> this to be bad. It just is the way it is because the real platform
> underneath KDE is so low that we have to build up far too much to get
> things done.

But if it prevents my app from running, it is a problem. And if it gives my
app behaviour that the users on those platforms report as bugs (like, cannot
open a file on OSX), it's a problem.

> Desirable depends on who's asking.

Yes, well... I don't like nf2's harping on using gobject and so on. But in
this case, I am spending work on trying to make krita use KDE when running on
KDE, but just Qt and other non-KDE dependencies when running elsewhere.

> I believe KDE libs should integrate into the platform as much as they can,
> if they're not running on the KDE Workspace. That would mean using standard
> global shortcut APIs on Mac and Windows instead of launching kglobalacceld,
> for example.

And not using additional memory (on disk and in ram) if they don't deliver
anything extra that's truly compelling.

> But I also believe that KDE libs should use what technologies they have
> that are better than what the other desktops have. This includes, for
> example, the file dialog: I definitely don't want to see the GTK file
> dialog in my KDE applications if I launch them in GNOME.

I would, actually, love that. It would save so many complaints...

> The point is that KDE libs don't have the same goal as Qt. Qt wants to
> integrate to the platform where it is as much as possible, so that your app
> can look native. KDE libs want to bring the best desktop experience you can
> have and, if that means being different from the platform because we think
> we're doing better, then so be it.

Yes, that's part of the problem: I want KDE to be the best desktop, the best
platform, but I don't want users of other platforms to get an extra platform
when they install my application.

> > So, for my applications, I need to find a way to switch out the KDE
> > libraries when porting them to other platforms.
>
> I think we need a "platformless" set of libraries, like you want. That is,
> technically, Qt's goal, so those widgets and other APIs should be either in
> Qt, or in Qt-related projects. See what I had written below:

Yes, indeed. And for the rest it should be easy to switch it off without
hacking in the source. That's platform, it should be papered over by Qt.

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

But... kded, klauncher, dbus and all that jazz doesn't make Krita better on
Windows, it makes it worse, because it adds bulk, confuses the user and makes
installation harder.

> PS: Maemo also has the D-Bus daemon, the equivalent of klauncher and many
> daemons too. That only goes to prove what I said about the underlying
> platform being far too primitive.

Which is even worse -- krita needs its own klauncher, so on the very
constrained maemo platform, we have to run two of everything! Of course, it
would have been smart to not just switch to Qt, but also to switch to KDE, but
as long as that hasn't happened...


--
Boudewijn Rempt | http://www.valdyas.org
Reply | Threaded
Open this post in threaded view
|

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

Gary Greene-3
In reply to this post by Alexander Neundorf
On 7/14/09 11:34 AM, "Alexander Neundorf" <[hidden email]> 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 ?
> Isn't that issue somewhat similar to programs installing their own copy of the
> JRE ? For them it's usually no problem.
>
> Alex

In many ways this is no different than the people that make Gtk+ apps for
Windows too. They have to bundle up all the Gtk+, Glib, Pango, Bonobo, and
Cairo libs themselves, or do it via a unified community package.


--
Gary L. Greene, Jr.
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.



Reply | Threaded
Open this post in threaded view
|

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

Jaroslaw Staniek-3
In reply to this post by Pau Garcia i Quiles
2009/7/14 Pau Garcia i Quiles <[hidden email]>:

> On Tue, Jul 14, 2009 at 8:34 PM, Alexander Neundorf<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

nf2.email
In reply to this post by Thiago Macieira
On Tue, Jul 14, 2009 at 5:47 PM, Thiago Macieira<[hidden email]> wrote:
> But I also believe that KDE libs should use what technologies they have that
> are better than what the other desktops have. This includes, for example, the
> file dialog: I definitely don't want to see the GTK file dialog in my KDE
> applications if I launch them in GNOME.
>

Yes, but you would probably expect them to use the file-management
engine provided by the system. AFAIK that's what Gnome tried to
achieve with GIO. It's just a set of GInterfaces, and the GObjects
which implement those interfaces are defined in adaptor modules.  If
you for instance run Gimp or Dia on Windows, they will still have Gtk
filechoosers with embedded previews, but the engine which drives it,
is obviously Windows filemanagement. No GVFS, D-Bus etc...

The interesting thing seems to be, that they are able to abstract
everything what's needed in a filechooser through GIO: Also the items
that appear in the "places" pane on the left side (like C: on
Windows).

Cheers,
Norbert
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

Thiago Macieira
In reply to this post by Boudewijn Rempt-2
Boudewijn Rempt wrote:
>Now, personally, I don't want to lose all the nice KDE things, when
> working on and in my chosen platform. Compared to KDE, I feel clumsy
> everywhere else. But they are KDE advantages, so I'd like to abstract
> them away, and have Krita use those facilities only when running on
> KDE.

I believe the problem here is a historical one. Since KDE has always been
the platform and the KDE libraries only had one platform to integrate
with, we have never had the need for separation.

That need is now arising.

We would need an architecture more or less like this:
 - the underlying platform
 - what should be in the platform but isn't there, like global
accelerators, configuring of date and time formats, VFS, etc.
 - a cross-platform toolkit abstracting the platform
 - a set of libraries providing cross-platform functionality that no
platform has, but we feel our apps should have.

The current architecure is nowhere like that. The underlying platform is
too low, the cross-platform toolkit isn't complete for all tasks. And we
complemented the platform by writing the necessary tools using not only
the toolkit, but the our own libraries as well.

That's a dependency reversal. How can Qt integrate with a platform that
builds on top of Qt? That's an answer I've been trying to answer for the
past two years in my day job :-)

I don't know how to solve this without stopping all KDE 4 work and
spending 2 years into making KDE 5.

--
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Kill KIO (was: Repositioning the KDE brand)

nf2.email
On Tue, Jul 14, 2009 at 11:29 PM, Thiago Macieira<[hidden email]> wrote:

> I believe the problem here is a historical one. Since KDE has always been
> the platform and the KDE libraries only had one platform to integrate
> with, we have never had the need for separation.
>
> That need is now arising.
>
> We would need an architecture more or less like this:
>  - the underlying platform
>  - what should be in the platform but isn't there, like global
> accelerators, configuring of date and time formats, VFS, etc.
>  - a cross-platform toolkit abstracting the platform
>  - a set of libraries providing cross-platform functionality that no
> platform has, but we feel our apps should have.
>

What kind of "platform" do you mean? A platform shared with other desktops?

Regarding the dependencies of GVFS you were talking about in an
earlier mail: Which of those dependencies do you think would be
problematic for KDE? KWallet vs. Keyring - i think there are attempts
to fix that (Cool!), there are some minor dependencies to gconf AFAIK,
but i guess that could be fixed if KDE says "we really want to use
GVFS, but..."

Cheers,
Norbert
123