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

List:       koffice
Subject:    Re: koffice applnk
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-06-01 11:47:11
[Download RAW message or body]

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 ?


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]