From koffice-devel Fri Apr 27 07:35:55 2001 From: Thomas Zander Date: Fri, 27 Apr 2001 07:35:55 +0000 To: koffice-devel Subject: Re: Dynamic plugin-based variables for KWord X-MARC-Message: https://marc.info/?l=koffice-devel&m=98835697027681 > 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. Hmm, this would mean that when a user receives the document and that user does not have the required plugin, he can't use/print the document. A rendered (preview) string would be nice to have in the xml at that point. Like photoshop does with text, it stores a rendered version and warns on opening and on editing of the text that required fonts are not available. So you can't edit that part, but you can print it. > 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). Adding a MissingCustumItem class can then render the preview text found in the XML when the current plugin is not found. > Example uses: > > - embedding HTML anchors in a Kword file (argument string is URL, "live" > value is the descriptive part) > > - serial letters > > - KCite (I think :-)) This would probably need 2 references to one kcite-entry. One is the formatted text and one is the long explanation. I don't know if it is wanted to ask the user to insert these both manually. In other words; a small profile per plugin would be nice to see where those things are defined. (Auto-insert at bottom, update plugin at XXX, etc.) But that can always be done later ;) Great idea ;) -- Thomas Zander zander@earthling.net The only thing worse than failure is the fear of trying something new _______________________________________________ Koffice-devel mailing list Koffice-devel@master.kde.org http://master.kde.org/mailman/listinfo/koffice-devel