[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KServiceTypeProfile
From:       David Faure <faure () kde ! org>
Date:       1999-11-04 19:41:56
[Download RAW message or body]

On Thu, Nov 04, 1999 at 02:33:53PM -0500, pbrown@redhat.com wrote:
> On Thu, 4 Nov 1999, David Faure wrote:
> 
> > On Thu, Nov 04, 1999 at 12:26:27PM -0500, pbrown@redhat.com wrote:
> > > I haven't heard anything in response to my earlier (merge) suggestion.
> > > Torben?  David?
> > 
> > I'm not sure about this. Can you elaborate how you think this should be ?
> > >From what I can see, merging would only make KServiceType very complex.
> > I don't see what we gain by merging...
> 
> What do we lose? 
Time
If both solution are equal, the current one should be kept simply
because it's the current one. :)
If they aren't equal, then of course, changing it makes sense.

> KServiceTypeProfile is so thin right now.  All it takes
> care of is preferred services.  This should be part of the KServiceType,
> don't you think?

Just had another look a KServiceTypeProfile.
It makes sense that it's separate in terms of implementation (the profile
involves parsing another file, profilerc, and also because it's something
on top of both KService and KServiceType).

And it would make sense to merge in terms of simplifying the number
of classes (but that doesn't make the API simpler per se).

No strong feeling here. I find both ways pretty much equal, hence
my preference for not changing the design.
(But fixing the bug you noted and implementing the default behaviour
when no profile is available, would be great, of course !)

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]