Re: [dev] embedding BLOBs in ODT (and accessing them via UNO)
On 2/21/07, Matthias B. <[EMAIL PROTECTED]> wrote: What we would like to do is to put an extra binary file into the ODT file (which after all is just a ZIP archive) and to read this file in our custom component. Isn't the idea of meta-data in ODF 1.2 intended for these type of applications ? Do I understand correctly that this would mean that such local "application specific" data is part of the XML context, but with specific local tags that are not part of the standard ? Or is the use of a simple file addition to the ZIP format the more elegant solution ? Peter -- Peter Vandenabeele peter AT vandenabeele DOT com http://www.vandenabeele.com http://www.linkedin.com/in/petervandenabeele - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Registry: default icon set change to crystal not working
Hi, I have two Linux systems with openoffice 2.0.3 and 2.1.0. My goal is to change my icon set to crystal as a default system value, so I added the property Misc/SymbolStyle to any of the following locations: /usr/lib/openoffice/share/registry/data/org/openoffice/Office/Common.xcu /usr/lib/openoffice/share/registry/modules/org/openoffice/Office/Common But that only works in 2.0.3. In OpenOffice 2.1.0 it does not work at all. When I check the cache file (org.openoffice.Office.Common.dat) in 2.1.0, I can see that SymbolStyle is always set to "auto" (its default value), no matter if I set it in the data or module directories. It seems to be ignoring my system configuration files. The only way to make it work on 2.1.0 is to add this configuration to the user's Common.xcu file, but I really would like to have a system setting. Am I missing something here? Do you know any difference between 2.0 and 2.1 concerning registry that would make this difference? I will be happy to provide additional information about this case. Thanks in advance, Rodrigo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] DisposedException when connecting to OpenOffice
Jan Pavelka wrote: com.sun.star.lang.DisposedException: java.io.IOException: com.sun.star.io.IOException: EOF reached - socket,host=localhost,port=6000,localHost=localhost,localPort=35109,peer Host=localhost,peerPort=6000 at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispa tcher.invoke(java_remote_bridge.java:237) at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispa tcher.run(java_remote_bridge.java:144) Such an exception is often indicative of an soffice crash. (At a quick glance, your code and setup seems reasonable, so I have no idea why there would be an soffice crash, though.) -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] embedding BLOBs in ODT (and accessing them via UNO)
Mathias Bauer wrote: > Matthias B. wrote: > >> We have a custom OOo component and we'd like to store additional data >> inside a document that this component can access. So far we've encoded >> the data as text and then stored it in notes, but this is quite >> hackish. What we would like to do is to put an extra binary file into >> the ODT file (which after all is just a ZIP archive) and to read this >> file in our custom component. Does UNO have interfaces for accessing >> arbitrary data stored in the document's ODT file? > > Yes. You must put your stream into a folder that you assign a MediaType to. > Here's some (untested) C++ code that illustrates this: (snip) I forgot to mention: you must do this before the document is saved, e.g. in a listener callback that waits for the document events "OnSave", "OnSaveAs" and "OnCopyTo". But you also can do this at any other time before the user asks for saving, the document will then appear as modified. The inserted content is part of the document storage then (and is accessible for reading via storage API), but it will not appear in the file until the root storage is committed. But in our framework only the document itself is allowed to do this. This usually happens when the user asks to save the document. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCL performance , feature improvements for Sommer of Code?
Hi, this mail goes to dev@gsl.openoffice.org and [EMAIL PROTECTED] Please follow up on the gsl list. Philipp Lohmann - Sun Germany wrote: > Clemens Eisserer wrote: >> What do you think about writing out a summer-of-code slot this year >> for enhancing VCL. >> VCL itself is a great toolkit and I guess because of >> not-existing-manpower it will be used for another couple of years, but >> I think it lacks some features of modern toolkits. > > Ah, a diplomat :-) > >> Some areas which could be improved: >> - Performance. Sometimes slow, sometimes bad feeling. E.g. menus in >> OpenOffice, Support for doublebuffering > > Both valid. The menu thing may extend to framework, though. > >> - Layout Managers. Implement Layout-Managers (already existing?) and >> adopt important dialogs to use them. > > A long term wish of mine. There even were two attempts at writing > Layouting code, one by mmeeks, one by cmc. Both had already progressed > to a demo dialog. However there was no resolution about which way to go > finally. I think we deadly need something like that. Currently extensions are restricted to non-resizable dialogs and IMHO that is one of the biggest barries to a better usability of extensions. I think we need to be able to "dock" extension GUI elements like we can dock our navigator. This will need a layouter as the strategy of our "internal" elements (overwriting a virtual "resize" method) does not apply to "external" ones. Perhaps it's time to revive one of the pilots? AFAIK Christian Lippka also invested some time for it. > As pavel mentioned we should continue any discussion about this in [EMAIL > PROTECTED] Done. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [gsl-dev] Re: [dev] VCL performance , feature improvements for Sommer of Code?
On Thu, 2007-02-22 at 09:11 +0100, Mathias Bauer wrote: > Hi, > > this mail goes to dev@gsl.openoffice.org and [EMAIL PROTECTED] Please > follow up on the gsl list. > > Philipp Lohmann - Sun Germany wrote: > > > Clemens Eisserer wrote: > >> What do you think about writing out a summer-of-code slot this year > >> for enhancing VCL. > >> VCL itself is a great toolkit and I guess because of > >> not-existing-manpower it will be used for another couple of years, but > >> I think it lacks some features of modern toolkits. > > > > Ah, a diplomat :-) > > > >> Some areas which could be improved: > >> - Performance. Sometimes slow, sometimes bad feeling. E.g. menus in > >> OpenOffice, Support for doublebuffering > > > > Both valid. The menu thing may extend to framework, though. > > > >> - Layout Managers. Implement Layout-Managers (already existing?) and > >> adopt important dialogs to use them. > > > > A long term wish of mine. There even were two attempts at writing > > Layouting code, one by mmeeks, one by cmc. Both had already progressed > > to a demo dialog. However there was no resolution about which way to go > > finally. > > I think we deadly need something like that. Currently extensions are > restricted to non-resizable dialogs and IMHO that is one of the biggest > barries to a better usability of extensions. I think we need to be able > to "dock" extension GUI elements like we can dock our navigator. This > will need a layouter as the strategy of our "internal" elements > (overwriting a virtual "resize" method) does not apply to "external" ones. > > Perhaps it's time to revive one of the pilots? AFAIK Christian Lippka > also invested some time for it. I'm still rather a fan of my springs approach, though sadly my original implementation was utter rubbish. What I thought might be convenient with the springs idea was that... a) There is a java SpringLayout things in the awt so springs are fairly familiar b) It's possible to incrementally change dialogs and leave old one working like they always did while adding springs to new ones, I was (and still am) a bit frightened of the more extensive rework of dialog ideas where stuff like valid values are tested for in javascript which becomes part of the dialog description. c) And it seemed plausible to add a SpringLayout api to our uno one along the lines of the java one so that extensions could describe their dialogs' layout I reworked my implementation of springs in java and submitted it to libgcj as an implemenation of the sun java equivalent. So the work went *somewhere* at least, I always meant to re-work that final java one back into c++ and take up the "show it can work for the more complicated tab dialog layout" case challenge. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Reasons why OpenOffice encounters error
Well, hard to say what happens without knowing what you do... As a wild guess, is there something like this in your code: frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); Then replace it. This code may stop the JavaVM and this can crash the office. Do you get a stack trace when the office crashes? HTH, Steffen mellannie rachelle reyes wrote: HI im mellanne again, we are using JCreator for our coding in JAVA...the openoffice can read our code and execute what is needed but after execution it will automatically start its recovery of the file, it says that it encountered an error that is why OOo crashes... thank you very much!!! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] CWS Handling: Binary Incompatible Changes
Change in CWS Handling == Summary: When you are doing binary incompatible changes in your CWS, please mark those modules 'incompatible' in EIS. Detailed Description: - *Background*: For all current code lines Hamburg RE normally does compatible master workspace builds (see http://wiki.services.openoffice.org/wiki/Compatible_Builds ). Code changes in childworkspaces are by default expected to be compatible. During integrations we of course are checking whether that's true and switch to partly incompatible builds if needed, but do not rely on us: sometimes we miss something. Therefore there always has been a rule to announce incompatible changes to RE. Also, whenever several people are working together on a common childworkspace they have to know when someone does a binary incompatible change. This of course can be done by email or personal communication, but sometimes a more formal support would be helpfull. *Change*: EIS now can handle this information effectivly. On the Edit page for childworkspaces added modules can be flagged 'incompatible'. You can see this information in EIS and query it by 'cwsquery incompatible' (on SRC680 m204, OOF680 m8, or newer milestones). RE tooling also will use that information. You do not have to care about dependencies (list of modules which have to be rebuilt from scratch), just flag the module(s) changed incompatibly. If there are several of them, mark the lowest one in a depency chain or simply all of them. *New Policy*: Mark modules where you have done binary incompatible changes. References: --- What are binary compatible builds? What changes are binary incompatible? See http://wiki.services.openoffice.org/wiki/Compatible_Builds About EIS's new features: http://blogs.sun.com/GullFOSS/entry/eis_incompatible_changes_tinderbox_termite - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] CWS Handling: Binary Incompatible Changes
Rüdiger Timm wrote: *New Policy*: Mark modules where you have done binary incompatible changes. What about those infamous cases as adding an idl file to udkapi and thus having to rebuild offapi, offuh, ridljar---do we just continue to keep these dependencies implicitly hard-coded in Hamburg RE? -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] CWS Handling: Binary Incompatible Changes
Stephan Bergmann wrote: Rüdiger Timm wrote: *New Policy*: Mark modules where you have done binary incompatible changes. What about those infamous cases as adding an idl file to udkapi and thus having to rebuild offapi, offuh, ridljar---do we just continue to keep these dependencies implicitly hard-coded in Hamburg RE? I would opt to stick with that. I do not see a necessity to rebuilt everything above offapi, including binfilter, helpcontent2, and officecfg, when someone just adds a new idl file or changes some documentation. Rüdiger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] embedding BLOBs in ODT (and accessing them via UNO)
Peter Vandenabeele wrote: > On 2/21/07, Matthias B. <[EMAIL PROTECTED]> wrote: >> What we would like to do is to put an extra binary file into >> the ODT file (which after all is just a ZIP archive) and to read this >> file in our custom component. > > Isn't the idea of meta-data in ODF 1.2 intended for these type of > applications ? > Do I understand correctly that this would mean that such local "application > specific" data is part of the XML context, but with specific local tags that > are > not part of the standard ? > > Or is the use of a simple file addition to the ZIP format the more elegant > solution ? The idea of embedded content doesn't stop where XML based data ends. At times it might be desired to add some data that a component, e.g. an extension assigns to the document to enable a workflow based on it. This is not an ODF but an OOo thing. What exactly this could be should be answered by people like Matthias B. We had that ability to embed external data for a long time as it was requested by users, customers and software developers and it still has its merits. ODF metadata as I understood always should be bound to some elements in the document, but that isn't necessarily true for the "BLOBs" we are talking about. OTOH if someone wanted to attach some data to parts of the document I agree that he should check whether going the metadata way might be more appropriate (once it is ready to use). Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
