Hi Paolo, > I can't evaluate the complexity of such an implementation but the > infrastructure for text resources is already there: > would it be so difficult adding binary resources?
As I see it, the string resource API solves two problems: Abstracting from the concrete location of a resource, and localizing the resource. There are contexts where only the first of those - access to the resource - is needed. So, I would like to separate the two things. Once we have the possibility to obtain any resource within an extension, then we could put another API on top of that which deals with localization. Also, we could then enhance the "export as extension" implementation to properly use the new resource location mechanisms. > (Where "solution" reminds me that I am >> not even sure I have an understanding of the problem. I don't even think >> that the problem statement can be worded in a way that it applies to all >> three above cases.) > > IMHO you can express the idea in that way: > > "adding the capability of embedding images into UNO controls" (only for > controls that can display images, of course) Okay, that is general enough to cover all possible eco systems of dialog/controls. Still, you yourself said that the problem is more general, it is about resources in extensions. And that's a problem that low level that I want to provide some low level API - an UCP seems like a very good solution to me - which solves this basic problem. On top of that, other problems can be solved. > An approach "extension centric" will force the developer to modify > control properties after creating and installing the extension or, even > worse, to provide code for loading images into controls at runtime, that > should be the problem that you intended to solve. We already said that ideally, this is the task of some "extension development IDE". No developer should need to bother with this ... > "Consistency" from the user POV would be: > I design a dialog into a document embedding some images. > Then, I copy/paste the dialog (or even the single image control) into > another library (e.g. into a different document or into a shared > library) and images are still there, just like other properties. I fully agree, everything else is a bug. But I don't see how this contradicts the suggestion to store the "embedded image" in the document. That's an implementation detail which you as user shouldn't bother with. We developers need to bother with it, and we need to find a solution for dialogs/images in a non-document Basic library, or an extension. But from a user's POV, the behavior should be exactly as you described it. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Impress http://graphics.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
