Frank Schoenheit, Sun Microsystems Germany wrote:
>> Would should think about a further macro that expands to the extension
>> root directory.
>
> If noone vetoes this for some good reasons ;), I'll give the UCP a try.
No veto, but IMHO that's breaking the butterfly on the wheel. Jürgen's
propo
Hi Juergen,
> Well, i assume you have to know the extension identifier anyway. The
> PackageInformationProvider singleton is your friend to retrieve the
> extension root directory. From there you can reference everything in the
> extension hierarchy ...
As mentioned elsewhere in this thread ;)
On 3/24/10 2:47 PM, Frank Schoenheit, Sun Microsystems Germany wrote:
Hi Juergen,
For dialgs coming as a xdl file (dialog editor export) we have already
extended the toolklit to accept relative paths to the xdl file.
Didn't know that.
That
makes it quite easy to reference any images in an e
Hi Juergen,
> And if we extend the functionality of images in dialogs in some way we
> should think about a convention for accessibility. Something like
> myimage.png and myimage_hc.png for the high contrast counterpart.
No, this should be solved without the graphic provider, if at all.
Finall
Hi Juergen,
> For dialgs coming as a xdl file (dialog editor export) we have already
> extended the toolklit to accept relative paths to the xdl file.
Didn't know that.
> That
> makes it quite easy to reference any images in an extension package.
As long as you have an xdl file, i.e. a dialog
On 3/24/10 1:40 PM, Juergen Schmidt wrote:
On 3/24/10 12:16 PM, Frank Schoenheit, Sun Microsystems Germany wrote:
Hi Noel,
So, Frank for your ucp solution which I would guess will somehow
somewhere re-use the GraphicObject stuff
No, the idea is to have a provider for *arbitrary* content with
On 3/24/10 12:16 PM, Frank Schoenheit, Sun Microsystems Germany wrote:
Hi Noel,
So, Frank for your ucp solution which I would guess will somehow
somewhere re-use the GraphicObject stuff
No, the idea is to have a provider for *arbitrary* content within a
deployed extension. That is, an URL lik
Hi Noel,
> So, Frank for your ucp solution which I would guess will somehow
> somewhere re-use the GraphicObject stuff
No, the idea is to have a provider for *arbitrary* content within a
deployed extension. That is, an URL like
"vnd.sun.star.extension://" will provide a
content which effectively
Noel Power wrote:
Frank Schoenheit, Sun Microsystems Germany wrote:
[...]
So, Frank for your ucp solution which I would guess will somehow
somewhere re-use the GraphicObject stuff, assuming that is the case
we should perhaps agree a common location ( such as the root folder
e.g. just as i
Frank Schoenheit, Sun Microsystems Germany wrote:
Hi Paolo,
[...]
> "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 o
> Would should think about a further macro that expands to the extension
> root directory.
If noone vetoes this for some good reasons ;), I'll give the UCP a try.
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http:
On 03/22/10 19:45, Mathias Bauer wrote:
Sure? IIRC there was a way to have "%origin%" as a placeholder in
entries of xcu files that will be expanded at deployment time or can be
resolved at runtime to give you that path. I used that technique in
several extensions, without being forced to any suc
On 3/22/10 7:45 PM, Mathias Bauer wrote:
Frank Schoenheit, Sun Microsystems Germany wrote:
Hi Paolo,
Why not the %origin% placeholder?
I just noticed that the graphic provider can handle demacrofyed urls
like this one:
vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/sJYsUf_/MyExtens
Frank Schoenheit, Sun Microsystems Germany wrote:
> Hi Paolo,
>
>> Why not the %origin% placeholder?
>> I just noticed that the graphic provider can handle demacrofyed urls
>> like this one:
>> vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/sJYsUf_/MyExtension.oxt/icons/lightbulb.jpg
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, a
Hi Frank,
Frank Schoenheit, Sun Microsystems Germany ha scritto:
[...]
Because the problem I originally raised has nothing to do with dialogs.
OK, the problem is "binary resources for extensions" I recognize that.
BUT, some versions ago, when the problem was "text resources for
extensions" the
Hi Noel,
are you sure that you are subscribed correct? Please check it! At least
your Novell address seems to be not subscribed.
http://api.openoffice.org/servlets/ProjectMailingListList
Juergen
On 3/18/10 12:02 PM, Noel Power wrote:
Hi Frank
Frank Schoenheit, Sun Microsystems Germany wrote
Hi Frank
Frank Schoenheit, Sun Microsystems Germany wrote:
Hi Noel,
guilty, currently for 'form' controls you can now 'uncheck' the 'link'
option when choosing the graphic, doing that the image will be embedded
in the document.
as for dialogs this currently is not enabled, however in the cw
Hi Noel,
> guilty, currently for 'form' controls you can now 'uncheck' the 'link'
> option when choosing the graphic, doing that the image will be embedded
> in the document.
> as for dialogs this currently is not enabled, however in the cws
> 'container_controls'
> http://eis.services.openoff
Hi Frank, Paolo
Frank Schoenheit, Sun Microsystems Germany wrote:
Hi Paolo,
But nowadays, dialogs in documents can embed their images, can't they? I
remember Noel Power having implemented this a while ago. Admittedly, the
only thing I am sure of is that this works for form controls, but IIRC
Hi Paolo,
>> But nowadays, dialogs in documents can embed their images, can't they? I
>> remember Noel Power having implemented this a while ago. Admittedly, the
>> only thing I am sure of is that this works for form controls, but IIRC,
>> he also did this for dialogs in documents ...
>
> I must
Hi Frank,
Frank Schoenheit, Sun Microsystems Germany ha scritto:
[...]
I see two problems:
1) this approach does not solve the same problem for dialogs included in
documents.
But nowadays, dialogs in documents can embed their images, can't they? I
remember Noel Power having implemented this a
Hi Stephan,
> Maybe a URI schema like
> "vnd.sun.star.extension:///" might
> generally be useful. (One could probably implement a UCP that handles
> it
Ah, you're absolutely right, there is no reason at all to limit this to
images! An UCP sounds like some more work, but it looks like the much
Hi Paolo,
> Why not the %origin% placeholder?
> I just noticed that the graphic provider can handle demacrofyed urls
> like this one:
> vnd.sun.star.expand:$UNO_USER_PACKAGES_CACHE/uno_packages/sJYsUf_/MyExtension.oxt/icons/lightbulb.jpg
because you would need to know, at time of creation of you
Hi Frank,
Frank Schoenheit, Sun Microsystems Germany ha scritto:
Hi,
is there a way to deploy images in an extension, which can be loaded
without calling code in that extension? That is, ideally I would like
the extension to deploy a configuration entry containing a URL, where
the OOo can pass
On 03/17/10 12:10, Frank Schoenheit, Sun Microsystems Germany wrote:
is there a way to deploy images in an extension, which can be loaded
without calling code in that extension? That is, ideally I would like
the extension to deploy a configuration entry containing a URL, where
the OOo can pass th
On 2010-03-17 12:10, Frank Schoenheit, Sun Microsystems Germany wrote:
Hi,
is there a way to deploy images in an extension, which can be loaded
without calling code in that extension? That is, ideally I would like
the extension to deploy a configuration entry containing a URL, where
the OOo can
Hi,
is there a way to deploy images in an extension, which can be loaded
without calling code in that extension? That is, ideally I would like
the extension to deploy a configuration entry containing a URL, where
the OOo can pass this URL to the graphic provider, which is able to load
the image wi
28 matches
Mail list logo
