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

List:       koffice
Subject:    Re: koffice applnk
From:       weis () stud ! uni-frankfurt ! de
Date:       1999-06-02 2:14:40
[Download RAW message or body]

Hi,

On Tue, 1 Jun 1999, Simon Hausmann wrote:

> On Tue, 1 Jun 1999 weis@stud.uni-frankfurt.de wrote:
> 
> > Hi,
> > 
> > On Mon, 31 May 1999, Simon Hausmann wrote:
> > 
> > > On Mon, 31 May 1999, Michael Koch wrote:
> > > 
> > > > >But before I commit the stuff I'd like to ask:
> > > > >
> > > > >Is it ok to install all the .desktop files of the apps (not the
> > > > >filters/plugins/tools, I will finish this later) into applnk/KOffice/* ?
> > > > >
> > > > >If you don't like this, then we have two other possibilities:
> > > > >
> > > > >2) install all of them into the service directory (ugly IMO)
> > > > >
> > > > >3) continue installing them in apps/koffice/partlnk and hack kded to scan
> > > > >   this directory, too (even more ugly IMO)
> > > > >
> > > > >Opinions?
> > > > 
> > > > I think that your first solution is rigth. 
> > > > 
> > > > Where will the filters/plugins/tools installed ? 
> > > 
> > > We have to distinguish now:
> > > 
> > > Filters: Here we could go the clean way IMHO :)
> > >         Clean way means: create a special kde-wide directory for
> > >         servicetypes (we'll need it anyway I think)
> > >         Then we put a filter servicetype description into that directory,
> > >         so that KRegistry (in kded) can find it.
> > >         Filter .desktop files then go into the services directory.
> > >         When we query for filters the trader returns us the wanted filter
> > >         service and we can access the special filter properties (which are
> > >         read from the .desktop file because they're defined in the
> > >         corresponding servicetype description .desktop file) , just like
> > >         "ExportDescription" for example.
> > > 
> > >         The other way is described below, together with the plugins
> > > 
> > > Tools (DataTools) : Here we could go a similar way, also by using a
> > >                     special koffice datatool servicetype .desktop file. in
> > >                     order to be able to access the special properties.
> > > 
> > > Plugins : These are "more dynamic" ;) .desktop files, which means we can't
> > >           describe them in a servicetype .desktop file, because essential
> > >           information is kept in extra groups. And unfortunately we can't
> > >           declare groups in properties.
> > >           Example:
> > >           ...
> > >           MenuEntries=Start,Stop,Play
> > >           ...
> > >           [Start]
> > >           Icon=
> > >           Slot=
> > >           Name=
> > >           [Stop]
> > >           ...
> > > 
> > >           We need to be able to access all these fields through
> > >           properties, but this is impossible.
> > > 
> > >           Three solutions come to my mind:
> > >           1) extend the properties stuff, but I guess this becomes a
> > >              pretty difficult thing (and did you know that I'm lazy? ;)
> > >              But perhaps someone else has an idea how to do this and wants
> > >              to implement it? Perhaps the creator itself (Torben) ? :-)
> > >           2) continue installing them in the servicesdir and try to find
> > >              the corresponding .desktop file from the KService data the
> > >              trader returns us, so we can "read" the rest. But I don't
> > >              like this way, because I believe it's a bad hack.
> > >           3) The solution I currently prefer
> > >              We continue installing the stuff in the koffice directory and
> > >              keep the koScanPlugins code mostly as is.
> > >              When registering the servers at the IMR we have to be careful
> > >              not to forget to remove the entries when exiting, because
> > >              we're actually using the global IMR from kded, and we should
> > >              clean up our mess when quitting, IMO ;-)
> > >              I think the best place for such a cleanup might be the shell,
> > >              since it's session global (session=one app plus embedded
> > >              documents).
> > >              But I think we have to be careful with this, because it might
> > >              happen that at the same time another koffice app starts and
> > >              this might arise problems when the other app now tries to
> > >              clean up these IMR entries.
> > >              Or perhaps we shouldn't cleanup, to avoid such problems?
> > > 
> > > Ideas/Suggestions/Opinions?
> > > Did I forget something?
> > > Torben?
> > 
> > Solution number 3 looks like a big hack to me.
> > 
> > Lets be a pig :-) We put all entries in one list
> > 
> > MenuEntries=Start,icon,slot, ...,NextButton,icon2,slot2, ....
> > 
> > and so on. Looks ugly but can be stored in a property
> > and can be described by a service type as a list of strings.
> 
> Yes, I like this idea. Better be a pig than a big hacker ;-)
> 
> And what about the servicetype directory?
> We need one anyway, but how can we name it?
> .../share/servicetypes ?

Sounds ok for me.

Bye
Torben

> 
> Ciao,
>   Simon
> 
> --
> Simon Hausmann       <hausmann@kde.org>
> http://www.kde.org/  <tronical@gmx.net>
> 
> 
> 

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

Configure | About | News | Add a list | Sponsored by KoreLogic