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)

nf2.email
On Mon, Jul 13, 2009 at 10:52 PM, Alexander Neundorf<[hidden email]> wrote:
> 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).
>

Thanks, Alex, for defending my initial statement in this thread. :-)
Not sure if it really deserves that ;-). The "dead dog" I regret a bit
- that was nasty...

However, I think it isn't always that important how you say things. I wanted to
put a bit of "spice" into this one. People here are smart enough to get the
message from either an emotional commentary or a very cautious and
diplomatic one.


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 nf2.email
nf2 wrote:
>What kind of "platform" do you mean? A platform shared with other
> desktops?

Yes.

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

The point is that there is no platform yet. I don't consider GVFS to be
part of such platform.

The things closest to being platform are Hal and Avahi. Even Network
Manager isn't really in the "platform" category because many important
distributions don't use it.

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

Thiago Macieira
In reply to this post by nf2.email
nf2 wrote:

>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...
That could be done with KIO too.

The difference is we chose not to, because it falls into the category of
"things we do better than the platform".

(And, obviously, because no one even tried to port KIO to Windows VFS)
--
  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
In reply to this post by Thiago Macieira
On Wed, Jul 15, 2009 at 8:38 AM, Thiago Macieira<[hidden email]> wrote:

> nf2 wrote:
>>What kind of "platform" do you mean? A platform shared with other
>> desktops?
>
> Yes.
>
>>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?
>
> The point is that there is no platform yet. I don't consider GVFS to be
> part of such platform.
>

Sure, but why?

Which are the important arguments against choosing it as a platform technology?
Is it dependencies, is it its technical design, the features, the
quality or non technical reasons?

I would just like to know...

Norbert
Reply | Threaded
Open this post in threaded view
|

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

Thiago Macieira
Em Quarta-feira 15 Julho 2009, às 16:05:16, nf2 escreveu:

> On Wed, Jul 15, 2009 at 8:38 AM, Thiago Macieira<[hidden email]> wrote:
> > nf2 wrote:
> >>What kind of "platform" do you mean? A platform shared with other
> >> desktops?
> >
> > Yes.
> >
> >>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?
> >
> > The point is that there is no platform yet. I don't consider GVFS to be
> > part of such platform.
>
> Sure, but why?
It doesn't exist. Do I have to explain why it doesn't? My point here is that
there was nothing to integrate with when KIO was written and there continues
to be nothing to integrate with now, replacing the functionality.

> Which are the important arguments against choosing it as a platform
> technology? Is it dependencies, is it its technical design, the features,
> the quality or non technical reasons?

How would I know? It wasn't designed to be a replacement for KIO (as far as I
know, KDE developers weren't invited to help the designing so that it would be
a suitable replacement). That's a direct opposite of D-Bus, which was designed
to replace DCOP, with input from KDE developers too.

I think you're the one best qualified to give the technical reasons why. And
given your emails previously, it seemed to me that you don't believe it to be
a replacement for KIO either. (you listed many things that KIO does and it
doesn't)

I think there are many things we should fold back into fd.o with suitable
"platform" implementations. And there are many things we have to have
abstractions for in KDE, for the benefit of other systems. VFS may be one of
them, but it's by far the most complex one that I can think of, so it's
probably going to be the last one to go too.

Can we fix first global shortcuts, system tray icons, proxy configuration, etc.?

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

Gary Greene-3
On 7/15/09 10:04 AM, "Thiago Macieira" <[hidden email]> wrote:

> Em Quarta-feira 15 Julho 2009, às 16:05:16, nf2 escreveu:
>> On Wed, Jul 15, 2009 at 8:38 AM, Thiago Macieira<[hidden email]> wrote:
>>> nf2 wrote:
>>>> What kind of "platform" do you mean? A platform shared with other
>>>> desktops?
>>>
>>> Yes.
>>>
>>>> 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?
>>>
>>> The point is that there is no platform yet. I don't consider GVFS to be
>>> part of such platform.
>>
>> Sure, but why?
>
> It doesn't exist. Do I have to explain why it doesn't? My point here is that
> there was nothing to integrate with when KIO was written and there continues
> to be nothing to integrate with now, replacing the functionality.
>
>> Which are the important arguments against choosing it as a platform
>> technology? Is it dependencies, is it its technical design, the features,
>> the quality or non technical reasons?
>
> How would I know? It wasn't designed to be a replacement for KIO (as far as I
> know, KDE developers weren't invited to help the designing so that it would be
> a suitable replacement). That's a direct opposite of D-Bus, which was designed
> to replace DCOP, with input from KDE developers too.
>
> I think you're the one best qualified to give the technical reasons why. And
> given your emails previously, it seemed to me that you don't believe it to be
> a replacement for KIO either. (you listed many things that KIO does and it
> doesn't)
>
> I think there are many things we should fold back into fd.o with suitable
> "platform" implementations. And there are many things we have to have
> abstractions for in KDE, for the benefit of other systems. VFS may be one of
> them, but it's by far the most complex one that I can think of, so it's
> probably going to be the last one to go too.
>
> Can we fix first global shortcuts, system tray icons, proxy configuration,
> etc.?

With proxy configuration being first on the list imo. Having a single shared
interface for that for all apps that are network facing would be a huge win,
since right now, UNIX/Linux is the last place where this needs to be done
(already exists in Mac OS X and Windows.)

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

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

:-). For me, it's only been in the past year or so that I started to realize
that I'd like to Qt be on top of KDE...

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

Eeek!

For now, I'm trying to experiment with ways of abstracting away KDE in some
form, like two plugins, one that links to the KDE dependencies and provides
all the extras, one that only uses Qt, and use that from KOffice. I'm not
really happy with it, though.

--
Boudewijn Rempt | http://www.valdyas.org
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 Wed, Jul 15, 2009 at 7:04 PM, Thiago Macieira<[hidden email]> wrote:

> Em Quarta-feira 15 Julho 2009, às 16:05:16, nf2 escreveu:
>> On Wed, Jul 15, 2009 at 8:38 AM, Thiago Macieira<[hidden email]> wrote:
>> > nf2 wrote:
>> >>What kind of "platform" do you mean? A platform shared with other
>> >> desktops?
>> >
>> > Yes.
>> >
>> >>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?
>> >
>> > The point is that there is no platform yet. I don't consider GVFS to be
>> > part of such platform.
>>
>> Sure, but why?
>
> It doesn't exist. Do I have to explain why it doesn't? My point here is that
> there was nothing to integrate with when KIO was written and there continues
> to be nothing to integrate with now, replacing the functionality.
>

Well, for the VFS functionality there is something. :-)

Regarding the more eccentric things KIO does (like HTTP, POP3) -
moving them to a "shared platform" wouldn't be such a win. Quite often
things like that are handled by different APIs than file-management.

My initial statement was not accurate of course. It was not about KIO
in general as a technology of async IO helpers or as an API. Just the
VFS part inside it (with VFS i mean the items that usually show up
inside filemanagers and file-choosers).

>> Which are the important arguments against choosing it as a platform
>> technology? Is it dependencies, is it its technical design, the features,
>> the quality or non technical reasons?
>
> How would I know? It wasn't designed to be a replacement for KIO (as far as I
> know, KDE developers weren't invited to help the designing so that it would be
> a suitable replacement). That's a direct opposite of D-Bus, which was designed
> to replace DCOP, with input from KDE developers too.

I don't really have the background knowledge here. I have heard
contradictory things. And GIO/GVFS has not been developed in total
secrecy either. Even if they way it happened has not been ideal, it
might still be suitable.

>
> I think you're the one best qualified to give the technical reasons why. And
> given your emails previously, it seemed to me that you don't believe it to be
> a replacement for KIO either. (you listed many things that KIO does and it
> doesn't)

I believe that's rather a matter of just wanting it. If KDE wants it,
there will be ways to make it work.

The benefit would be a standard filemangement layer for the
freedesktop platform.

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

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

Evgeny Egorochkin
On Friday 17 July 2009 00:37:29 nf2 wrote:

> On Wed, Jul 15, 2009 at 7:04 PM, Thiago Macieira<[hidden email]> wrote:
> > Em Quarta-feira 15 Julho 2009, às 16:05:16, nf2 escreveu:
> >> On Wed, Jul 15, 2009 at 8:38 AM, Thiago Macieira<[hidden email]> wrote:
> >> > nf2 wrote:
> >> >>What kind of "platform" do you mean? A platform shared with other
> >> >> desktops?
> >> >
> >> > Yes.
> >> >
> >> >>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?
> >> >
> >> > The point is that there is no platform yet. I don't consider GVFS to
> >> > be part of such platform.
> >>
> >> Sure, but why?
> >
> > It doesn't exist. Do I have to explain why it doesn't? My point here is
> > that there was nothing to integrate with when KIO was written and there
> > continues to be nothing to integrate with now, replacing the
> > functionality.
>
> Well, for the VFS functionality there is something. :-)
>
> Regarding the more eccentric things KIO does (like HTTP, POP3) -
> moving them to a "shared platform" wouldn't be such a win. Quite often
> things like that are handled by different APIs than file-management.

But why such stupid restrictions? KIO is basically an API for manipulating
file-like objects which can be (made to be) addressed by URLs. If it fits the
api, why not use it?

IMAP4 can be treated much like a FTP server that only stores files of
particular format(email). Yeah there may be an API that's better suited and
exposes more functionality of POP3 and IMAP4, but this doesn't help an
application that only understands KIO and doesn't really need anything other
than fetch the file it's pointed at.

This makes KIO abstraction not only sufficient, but useful because the app would
probably not implement several specialized APIs. Actually it's the same issue
of using KIO vs libhttp, libftp etc. Or to illustrate my point, why people
writing scripts use wget to fetch some page and not firefox?

if some other DE wants a subset of KIO slaves(eg because their software tends
to use only a subset of KIO and some other API for other things), distro
maintainers will be glad to separately package slaves into kio-essential and
kio-alltherest.

You can replace GIO with KIO, but not vice versa.

Sharing 4 kio slave implementations with GIO is like wrapping a wrapper for a
library when we already have a wrapper for the library. A lot more useful in
this case is sharing of account passwords across different VFS implementations.

> My initial statement was not accurate of course. It was not about KIO
> in general as a technology of async IO helpers or as an API. Just the
> VFS part inside it (with VFS i mean the items that usually show up
> inside filemanagers and file-choosers).

An artifical distinction for the most part as explained above with a proposed
solution for people who want to stick to this distinction no matter what.

> >> Which are the important arguments against choosing it as a platform
> >> technology? Is it dependencies, is it its technical design, the
> >> features, the quality or non technical reasons?
> >
> > How would I know? It wasn't designed to be a replacement for KIO (as far
> > as I know, KDE developers weren't invited to help the designing so that
> > it would be a suitable replacement). That's a direct opposite of D-Bus,
> > which was designed to replace DCOP, with input from KDE developers too.
>
> I don't really have the background knowledge here. I have heard
> contradictory things. And GIO/GVFS has not been developed in total
> secrecy either.

No KDE tech was ever developed in secrecy let alone total secrecy ;)

> Even if they way it happened has not been ideal,

It really doesn't matter. I can either ask for your input or anticipate what
your input would be without asking. If I make the right guess(es), the product
will be just as good.

> it
> might still be suitable.

Suitable for what? Apparently nothing had been done to make it useful for KDE.
Otherwise a working GIO-KIO bridge with password storage and UI(file transfer
status notifications) integration would be already available in playground
since it appears that somebody wants to make it happen...

> > I think you're the one best qualified to give the technical reasons why.
> > And given your emails previously, it seemed to me that you don't believe
> > it to be a replacement for KIO either. (you listed many things that KIO
> > does and it doesn't)
>
> I believe that's rather a matter of just wanting it. If KDE wants it,
> there will be ways to make it work.

KDE wanting or not wanting it also depends on effort involved to make it work
and benefits it brings.

> The benefit would be a standard filemangement layer for the
> freedesktop platform.

Standard doesn't mean good or useful unf.

Are GIO guys even interested in what you are doing? Do they care to read this
thread?

-- Evgeny
Reply | Threaded
Open this post in threaded view
|

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

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

> On Tuesday 14 July 2009, Thiago Macieira wrote:
> > 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 :-)
> >
> :-). For me, it's only been in the past year or so that I started to
> : realize
>
> that I'd like to Qt be on top of KDE...
>
> > I don't know how to solve this without stopping all KDE 4 work and
> > spending 2 years into making KDE 5.
>
> Eeek!
>
> For now, I'm trying to experiment with ways of abstracting away KDE in some
> form, like two plugins, one that links to the KDE dependencies and provides
> all the extras, one that only uses Qt, and use that from KOffice. I'm not
> really happy with it, though.

Can you make a list of concrete things which are problematic for you as it is
now ?
Then it may get easier to get some progress.

Alex

Reply | Threaded
Open this post in threaded view
|

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

Thiago Macieira
In reply to this post by nf2.email
nf2 wrote:
>Regarding the more eccentric things KIO does (like HTTP, POP3) -

HTTP is the most important of the protocols. If the other solution doesn't
handle it, then we can forget the discussion.

--
  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
In reply to this post by Evgeny Egorochkin
On Fri, Jul 17, 2009 at 4:51 AM, Evgeny
Egorochkin<[hidden email]> wrote:
> On Friday 17 July 2009 00:37:29 nf2 wrote:
>>
>> I believe that's rather a matter of just wanting it. If KDE wants it,
>> there will be ways to make it work.
>
> KDE wanting or not wanting it also depends on effort involved to make it work
> and benefits it brings.

Of course.

>
>> The benefit would be a standard filemangement layer for the
>> freedesktop platform.
>
> Standard doesn't mean good or useful unf.

Not necessarily, that's right. But in this case i think it would be
good and useful. I think it would not only solve that "lack of common
platform" problem in this particular area, but improve the
filemanagement experience within KDE as well. Especially when working
with file-servers.

Cheers,
Norbert
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 Fri, Jul 17, 2009 at 10:24 AM, Thiago Macieira<[hidden email]> wrote:
> nf2 wrote:
>>Regarding the more eccentric things KIO does (like HTTP, POP3) -
>
> HTTP is the most important of the protocols. If the other solution doesn't
> handle it, then we can forget the discussion.
>

Ok :-)

Cheers,

Norbert
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 Alexander Neundorf
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...)
* anything that wants to finds installed stuff in some pre-ordained path or
file system structure.
* and for this particular issue, anything that adds size on disk or in memory
for something I am not using.

As Thiago says, the problem is the expected runtime environment :-(.

I love KDE, and I miss it sorely when I have to use something else, whether
that's my phone, my mac or my windows vm -- but if I want to make my app
available on those platforms, KDE is a liability.
--
Boudewijn Rempt | http://www.valdyas.org
Reply | Threaded
Open this post in threaded view
|

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

Alexander Neundorf
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 ?
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).

Alex
Reply | Threaded
Open this post in threaded view
|

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

Evgeny Egorochkin
In reply to this post by Boudewijn Rempt-2
On Monday 20 July 2009 22:15:34 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...)
> * anything that wants to finds installed stuff in some pre-ordained path or
> file system structure.
> * and for this particular issue, anything that adds size on disk or in
> memory for something I am not using.

Wouldn't this issue be resolved if we had a number of smaller dependencies in
place of kdelibs. So if you don't use some functionality, there's a chance you
won't drag it along with your app?

> As Thiago says, the problem is the expected runtime environment :-(.
>
> I love KDE, and I miss it sorely when I have to use something else, whether
> that's my phone, my mac or my windows vm -- but if I want to make my app
> available on those platforms, KDE is a liability.


-- Evgeny
Reply | Threaded
Open this post in threaded view
|

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

Boudewijn Rempt-2
On Tuesday 21 July 2009, Evgeny Egorochkin wrote:

> On Monday 20 July 2009 22:15:34 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...)
> > * anything that wants to finds installed stuff in some pre-ordained path
> > or file system structure.
> > * and for this particular issue, anything that adds size on disk or in
> > memory for something I am not using.
>
> Wouldn't this issue be resolved if we had a number of smaller dependencies
> in place of kdelibs. So if you don't use some functionality, there's a
> chance you won't drag it along with your app?

Yes, that would help a lot.

--
Boudewijn Rempt | http://www.valdyas.org

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 Alexander Neundorf
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

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
Em Quarta-feira 22 Julho 2009, às 08:29:28, Boudewijn Rempt escreveu:

> On Tuesday 21 July 2009, Evgeny Egorochkin wrote:
> > On Monday 20 July 2009 22:15:34 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...)
> > > * anything that wants to finds installed stuff in some pre-ordained
> > > path or file system structure.
> > > * and for this particular issue, anything that adds size on disk or in
> > > memory for something I am not using.
> >
> > Wouldn't this issue be resolved if we had a number of smaller
> > dependencies in place of kdelibs. So if you don't use some functionality,
> > there's a chance you won't drag it along with your app?
>
> Yes, that would help a lot.
kdelibs is already split into smaller dependencies that you could opt out of.

Everyone links to kdecore, kdeui and KIO, though. Don't blame kdelibs for your
designing of your library and application with them.

Also, in the KDE 4 design process, we agreed that any and all KDE applications
requires the kdebase-runtime package to be installed. So you need not only the
libraries, but the programs from there as well.

Let's face it: we designed KDE to work in KDE.

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