[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