Re: [dev] Please make an installer for OOo 2.0
The hack to extract all RPMs should be able to work for you but I wanted to point this out because it's saved me a few times I really needed root. Do you have sudo access? If so try sudo -s, if that's blocked try sudo /bin/bash (or whatever your shell is) if that is also blocked you can always drop your own shell in your home dir and run it. If sudo access is really locked down it might not work on the boxes you mention but it's useful to know for those times it will. - Brian On 11/3/05 4:56 AM, Feve Feve [EMAIL PROTECTED] wrote: Please make an installer for OOo 2.0 The linux rpm:s or Solaris pkg:s will not do. At my office i'm allowed to install on our application server but i'm not allowd to have root access. The consequence... i cannot install OOo 2.0 BR /F - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Additions to the Mac dmg download (X11 fix and Spotlight)
On 10/27/05 6:27 AM, Stephan Schaefer [EMAIL PROTECTED] wrote: Daniel Aleksandersen wrote: Regular users don't need this window. Therefor I wrote a little AppleScript witch disables the black window and I though that this was something that a lot of other Mac-users could use too! Therefor I suggest that the dmg download of OpenOffice.org 2.0 includes this little app of mine witch disables the black window. It's just a little something that you'll have to run once and that's it. The AppleScript is as simple as the one you see below, but could be a really useful tool to include in the download for a better user experience for first time users. do shell script perl -p -e 's/xterm /# xterm /' /private/etc/X11/xinit/xinitrc ~/.xinitrc This could be compiled to a little app. You're right, the xterm window might be annoying, but potentially overwriting an existing .xinitrc in the user's home must be avoided. Additionally, you must tell the user what you're doing and providing a way to revert it - doing automatic changes to the system will definitely trigger discussions. As it was the case for the automatic font conversion that people don't like. I want to backup that opinion as well. Especially since some people, like myself have .xinitrc startup a couple of xterms along with a few other things when X11 starts. That is a configuration with X11 and an application install definitely shouldn't touch it automatically, the most I would do is point to the utility in the distribution, potentially prompt if you want the installer to run it. Another little thing that could really improve the whole OpenOffice experience for Mac users would be to include the NeoLight Spotlight indexer ( http://www.apple.com/downloads/macosx/spotlight/neolightneoofficespotlightimp orter.html ) with the download. This makes sense, but only if it can be put into CVS in order to have it automatically packed whenever an installation set is built. Everything that has to be manually packed will definitely get lost over time. So license issues have to be checked first. The last improvement suggestion would be to compress and wrap up the whole dmg a little neater and have some instructions there too. A suggestion below. http://img486.imageshack.us/img486/70/ooosuggestion2cp.png This looks very professional, but brings up another important issue that is not fixed yet: string localization for the Mac launch application and custom packaging process. How did the strings find their way into your image ? The OOo localization process must be used here - hard coded strings in some scripts are not an option. Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Restricting portions of config to admins only?
On 4/5/05 8:38 AM, Joerg Barfurth [EMAIL PROTECTED] wrote: deleted You can restrict access to individual settings by providing a configuration data (.xcu) file and using the protection attributes (oor:finalized and oor:mandatory) in that file to mark individual settings or entire subtrees as protected from further (e.g. user) modification. If you deploy your component with its configuration data as a shared UNO package, this data is imported into the basic OOo installation structure and should generally end up in a file that is not user-writable. You can't currently manipulate the access control attributes via the API. Manipulating protected data via the administrative API should leave the protection in place. It's been a few weeks but I wanted to catch up on this again. Can you expand on what you are referring to when you state protected attributes can be modified via the administrative API? I'm adding the configuration data via an .xcu file now so I'm going to experiment with the finalized/mandatory settings. I need to provide an administrative UI to allow edits by admins however I'm not clear on how I can separate the two. Thanks. - Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Save as PDF?
You have some similar options on WIndows if you wrap things together into a plugin. There are a number of libraries out there that would give you the pieces to need to put this functionality together much easier then pulling OOo's code apart to adapt it for Mozilla. A related note, I've printed to PDF in Firefox on OSX (native) and Windows ( http://sourceforge.net/projects/pdfcreator ) for some time now. - Brian On 4/5/05 12:49 PM, Ryan Singer [EMAIL PROTECTED] wrote: And on windows? On Apr 5, 2005 9:45 AM, Daniel Carrera [EMAIL PROTECTED] wrote: If you are just interested in Linux, you are much better off writing a plugin that prints to postscript and then runs 'ps2pdf'. No need to reinvent the wheel. Especially when it's a big and complicated wheel. Cheers, Daniel. On Tue, Apr 05, 2005 at 08:11:01AM -0700, Ryan Singer wrote: There is some interest in making a save as pdf feature in future versions of Mozilla on the PC and on linux, and one of my friends at the mozilla foundation was wondering if he could talk to a OOo developer about where to start with that. Any of you interested in helping? Just reply to me off-list and I'll forward you along. -- _ Ryan Singer -- Daniel Carrera | I don't want it perfect, Join OOoAuthors today! | I want it Tuesday. http://oooauthors.org | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Restricting portions of config to admins only?
I wanted to see if anyone had any input on this. I've seen some good data on how to make a custom schema for configuration data for my component but no way to restrict access to it. I'm implementing some custom configuration properties for my component that should only be changed by administrators. At the file level this could be enforced if the configuration was managed as separate files outside of OOo but if I extend the standard configuration through the API and store my own settings I haven't seen anything on how I could restrict access. Does anyone know how I can restrict access within the API or if a file on disk could be isolated and protected at the file system level? - Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Adding Menu command to File menu Creating toolbar dropdowns.
These are a couple of tough ones I haven't been able to crack. I've tried to do both as an Addon.xcu through a component and directly through BASIC (as prototype, ending in Java) but I haven't had any luck. I'm trying to add a command programmatically on startup with a Job addon to the File menu. I've tried a number of different things all without any luck so I was wondering if anyone has any ideas. I can create my own menus and toolbar icons without problems but haven't figured any hack to get things into the existing menus. I also want to create a toolbar which contains a list of dropdown items like the Apply style dropdown or similar but from a configuration file. I imagine given that I want to it to be dynamic with a job addon at each run I can't use an xcu file to do it but I haven't figured out how to do it from BASIC or java either. I'd appreciate any help anyone could offer.. - Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] URL Dispatching from Component.
I've looked at a number of examples that dispatch URLs into Ooo but I seem to be missing a piece I need to do what I want to do. I have a feeling I'm missing some interface relationships. I have a component which is a protocol handler that currently has an XComponentContext so I can get a number of interfaces from that however all of the examples which is a XURLTransformer to dispatch a URL back use a xmultiServiceFactory and I've tried a few things but can't seem to get what I need. My goal is to call the Digital Signature slot to bring up the dialog. Can anyone pass along a pointer or two? - Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] URL Dispatching from Component.
I spent some more time with the developer docs and realized why I was so confused. It was a stupid thing on my part but I was crossing up the terms remote and local as they applied to the factories. I was thinking Local was OOo itself and remote was my component, I needed to reverse that and things started working. - Brian On 3/25/05 7:02 AM, Brian Raymond [EMAIL PROTECTED] wrote: I've looked at a number of examples that dispatch URLs into Ooo but I seem to be missing a piece I need to do what I want to do. I have a feeling I'm missing some interface relationships. I have a component which is a protocol handler that currently has an XComponentContext so I can get a number of interfaces from that however all of the examples which is a XURLTransformer to dispatch a URL back use a xmultiServiceFactory and I've tried a few things but can't seem to get what I need. My goal is to call the Digital Signature slot to bring up the dialog. Can anyone pass along a pointer or two? - Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo 2.0 Netbeans Templates?
Juergen, Thanks for the help, I'll keep an eye out for those. In the meantime I got my script working. It turns out it should have been working all along but I had a single line of white space in the manifest.xml I have Ant dynamically build. Unopkg.exe would succeed in adding the package to Ooo but wouldn't actually register anything I had inside which is why I thought I had to be doing something wrong. I think that's a bug in unopkg and was going to submit it when I sat down at my workstation again. This is my first UNO component so it's a learning curve for me but I'm having some fun. Currently I'm trying to figure out how to call slots from my java component. Initially I'm just focusing on calling uno:About but my goal is to spawn the Digital Signature dialog. - Brian On 3/21/05 2:33 AM, Jürgen Schmidt [EMAIL PROTECTED] wrote: Hi Raymond, a closer IDE (NetBeans, Eclipse integrstion) is still on our todo list. The SDK contains two ant build scripts (scripting framework examples) which of course will probably change in the future but they still work and can be used as a start point. More ant scripts will be prepared asap and i will provide them as a separate download on api.openoffice.org and in future versions of the SDK. I can nevertheless provide an ant script for a UNO component example if necessary. But normally i would like to change and extend it to make it more general that it can be proper used a template. Juergen Raymond, Brian C. CONTR J9C887 wrote: I noticed in the developer's guide for 2.0 a mention of templates like there were in the 1.1 SDK. They aren't currently included in the SDK so I wanted to check to see if anyone has anything they are currently using that might be a help? I'm most interested in the Ant build script because the process has changed some with the xml manifest and such. Thanks.. - Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
