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

List:       kde-core-devel
Subject:    Re: KServiceTypeProfile broken?
From:       David Faure <faure () kde ! org>
Date:       1999-11-03 20:49:06
[Download RAW message or body]

On Wed, Nov 03, 1999 at 03:34:03PM -0500, pbrown@redhat.com wrote:
> On Wed, 3 Nov 1999, David Faure wrote:
> 
> > So filetypes uses profilerc ?
> > How can it talk about a preferred service then ?
> > (I refer to my comment on kde-cvs)
> > 
> > Unfortunately I have no idea about your problem,
> > since I don't know much of kuserprofile. Torben wrote it
> > and Simon hacked into it.
> > 
> > Hmm... I implemented preferredService though. It returns
> > the first one of what ::offers() returns, since that
> > was the code I found in KRun.
> > (The sorting is done this way. See KServiceOffer::operator< )
> > 
> > Can you print the list returned by ::offers() ? This might help.
> 
> OK this isn't making any sense.  There is too much overlap going on here.
No, I just think you misunderstood something.

> We need ONE place to determine what the mime types (file types, service
> types, whatever the hell we want to call them) are on the system.  As well
> as their associated attributes.  
There is.

> If the correct place to determine the "preferred" service for a mimetype
> is not via KServiceTypeProfile::preferredService, then where is it?
Yes, yes, preferredService is the place for that, but note that
it's just a convenience method, mainly for KRun, so that it actually
_runs_ the service it should.

The real answer to "what are the services associated to this
servicetype/mimetype" is a _sorted_ list of services, where
the first one is the preferred one.
I already told you the reasons for that : mainly because of upgrade problems.

> This method should do the looksup in profilerc for me, _if_ we are going to be
> using that.
It does. Or it should.
That's the way it's intended at least.
I might have coded it wrong.

> I think that too many people here are thinking from the
> _programmer's model_, which is where you implement something _as it
> actually exists on the system_, and not as it might be intuitively viewed
> by a user.
This is the major point.
Is it possible to hide those "preference" numbers to the user ?
Possibly, using a list with up and down buttons.

But having a "preferred" service per servicetype is wrong, once again.
There is one, but only as the result of comparing the preferences.
Otherwise if you have service S as preferred for mimetype M, what happens
when you upgrade M (the DefaultApp field gets erased, that's why it's
deprecated now) and install S2 that also says "I'm the preferred one for M".

>  The distinction between the offers() list and what is in
> profilerc is _completely implementation dependent_.
It shouldn't.

> The user doesn't give
> a shit where the preferences are stored, they just want to be able to set
> them all in one, concise, easy location.
Sure, hence the idea of moving this functionality to filetypes.

> Yes, offers() returns three things:  XMMS, X11 Amp, and mpg123.  XMMS is
> first.  But profilerc clearly says that X11 Amp is preferred.  So this is
> what preferredService should return.
This is just a bug in the sorting code then.

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