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

List:       koffice-devel
Subject:    RE: Dynamic plugin-based variables for KWord
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2001-04-26 21:41:42
[Download RAW message or body]

It is very good that variables/fields are coming in KWord.

Nevertheless, I have a few comments.

1. Result
May be I have not understood the point number 4, but the result too must be 
present in a KWord file.
A few reasons:
- the plug-in might not available in the currently used KOffice 
version/port/environment.
- export to "foreign" file formats that do not have fields at all (for 
example ASCII and HTML.)
- the exact field type might not be exportable in the "foreign" file format 
(could be the case in AbiWord or in Rich Text Format.)
- the KWord file might be read by a non-KDE application (for example a 
viewer.)
In all those cases, it would be useful that at least resulting text could 
be shown/exported/...

2. Empty Result
Do not forget that the result might be empty! KWord should work (and not 
crash) in this case.

3. Security
Be careful that those plug-ins cannot become Trojan horses, in particular 
the live ones.

4. Most Wanted Plug-Ins For Filter Status Files
For being able to write/maintain the filter status files in KWord itself, 
these plug-ins would be welcomed:
- hyperlinks to URLs (with the text shown that is different from the URL)
- anchor points ( like #import and #export in the status files). They do 
not need to work in KWord; they have just to be there so that the HTML 
export filter can put them back at the right places.

Have a nice day/evening/night!
-----Original Message-----
From:	shaheed [SMTP:srhaque@iee.org]
Sent:	Friday, April 27, 2001 12:20 AM
To:	koffice-devel@max.tat.physik.uni-tuebingen.de
Subject:	RFC: Dynamic plugin-based variables for KWord

I have been thinking for about the general problem of "variables" ("fields" 
in MsWord), and I think that we could invent some kind of a dynamic,
plugin-based variable concept that would, I think, cover this and other 
needs.

What I have in mind is something like this:

1. It is not a frame, but inline with the text.

2. It behaves like a single character as far as line-wrapping etc is
concerned (i.e. QRT's CustomItems).

3. The height is constrained to within the current line, the width is
determined by a plugin (a KPart::Plugin => PluginCustomItem).

4. Associated with the variable is the name of the plugin, an instance
identifier, and an argument string. Kword stores these two items in its 
XML,
and no more.

5. At document load time, all plugins are loaded. The plugins can initalise 
themselves as required, and add themselves to an appropriate menu item.

6. For each variable, the appropriate plugin is called at an entry point 
with
the argument which causes it to create its contents. This probably involves 
a
factory method of some kind (a bit like an anchor but returning a
PluginCustomItem).

7. The plugin is a shared context across all its child variables. That way, 
it can, for example, present a list of all its children in a dialog for
mass-editing etc.

The plugin design will have to allow for the plugin-computed "live" display 
value, a "dead" value (e.g., if plugin not found) etc.

Example uses:

- embedding HTML anchors in a Kword file (argument string is URL, "live"
value is the descriptive part)

- serial letters

- KCite (I think :-))

- later on, evolving towards complete form-filling functionality

Thoughts?
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

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