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

List:       kfm-devel
Subject:    Re: Template-Menu
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-02-28 23:21:55
[Download RAW message or body]

On Mon, Feb 28, 2000 at 11:48:33PM +0100, Christoph Pickart wrote:
> Am Mon, 28 Feb 2000 schrieb David Faure:
> > My idea would be to put in the kdesktop directory ALL sources, including
> > the html file and the text file... but of course a user can set it
> > the way you did. I just wouldn't create any .sources by default.
> 
> The .sources was just an example as I didn't know any temlates on your computer
> to use :). Templates like the html file should either be created by the user
> or provided by an application when it gets installed. 

Yes, that's right. An empty HTML file is no use if you don't have
an HTML editor around. I'd ship an empty text file though.

> > Ok, so if we have the links, with translated names in Templates/,
> > and they point to the global files.... The links should NOT use
> > $KDEDIR (this is deprecated since a very long time. Think about
> > the FHS, and about KDEDIRS...). But since the links could be set up
> > by kdesktop on first startup, they could easily point to the actual
> > templates... as long as nobody changes his KDEDIR(S) after that. Hmm, ok.
> 
> This was for the same reason as above. But for the sake of flexibility it wouldn't be
> so bad to have dynamical path. e.g. we have a network where the KDEDIR is not always the
> same, but your home directory is the same.

You don't get that part.
KDEDIR is dead. Look at how RH or debian package KDE, or simply
kdelib's configure options.
You can put binaries in /usr/bin and share stuff in /usr/local/share
(ok, bad example, but you get the point)

KDE still honours KDEDIR when it is set, but an script or a config file
doesn't have enough logic to do it correctly, so it shouldn't use $KDEDIR
at all.

BUT: kdesktop could use KDESHAREDIR or whatever, when creating the links,
and set that variable when reading the desktop file.

ktalkd does it, kpanel did it, kicker doesn't but it should :)

> > Next thing: you've put support for Type=Application in the _link_ ?
> > This makes no sense to me. A link is a link...
> > Looks like you tried to launch the app when doing New/Document.
> > Are you sure you want to do that ?
> > 1 - when doing it from a document, it should use KRun (i.e. do
> > just like a left click on the document, find the associated application)
> > 2 - Type=Application is the definition of an application, but not of
> > a link to a document at the same time. Your patch launches an application,
> > but with no document at all...
> 
> This was just an idea... I thought of integrating ohter appications like
> StarOffice. StarOffice can be startet with the template of a dokument,
> an html document e.g. This is done by the command "soffice html.url".
> Another example would be korganizer starting with a new appointment.
> So there would have to be a .desktop file for the application because it has
> to be launched with arguments other than in the kicker menu. 
> But I have to admit that this is not thought to the end...

Then I'd drop this for now :)

Starting an app on the newly created file is as easy as simple-clicking
on it, so I don't see the need for this.

> > Other than that, I still like the idea, because it makes it possible
> > to ship templates for empty text file and empty html file, with an 
> > appropriate (translatable) description in the .desktop link.
> > 
> > So the first part of the patch is roughly ok (the Type=Link one)
> > Most of the work is also to provide correct templates (and create the links
> > correctly in kdesktop's startup code).
> > 
> > Ah oh, and you lost support for the existing templates... Hmmm.. Not sure
> > whether we can still honour the existing .dessktop files. (At least
> > those with Type=Link, no problem for the others). Well, kdesktop
> > will overwrite them, then.
> 
> Yes. that's because I thought of creating the type "Type=Template".
"that's why", I suppose you mean.

Well I still don't like Type=Template (because the good thing about Link
is that people can create Links, with the Link Template... having a
Template Template becomes ... hairy!).

> > And if we parse a system templates dir, then we also have to support
> > a way for the user to 'hide' some of those (like we do in the K menu,
> > with Hidden=true). Well, that could be done, but it's another story :)
> > You'll do that next :-)
> 
> O.K., sir. But I really am no hacker. I have to learn a bit more of KDE2. 

Well, this is the perfect opportunity to do so :)

Do you feel like improving this, from what was said here ?

The knewmenu code only needs to be simplified
(be careful with KURL<->QString conversions, btw)
(once you've got a KURL, never go back to a QString)

but most of the work to be done is in kdesktop now.

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