Re: Re: [dev] Can we use AWT in our product?
Hi Juergen Thank you for your help and suggestion. The product we are to develop will use C++ for developing language. It's purely new, also we lack experiences for cross-platform. So we prefer to use AWT. What we are consider is whether AWT is allowed to use in a commercial software. Can you give us some advises about corresponding legal issue? Thanks again! Best Wishes. -邮件原件- 发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 发送时间: 2008年5月23日 13:07 收件人: dev@openoffice.org 主题: Re: [dev] Can we use AWT in our product? LiZhan(李湛) wrote: Hi everyone, we are planning to develop several new commercial products for our company, and we need a cross-platform GUI lib used as their base GUI module. So can we use AWT(certainly with GSL and VCL) of OpenOffice.org in our program? well you can use it but i don't think that it wouldn't be the best descision. We use VCL because it is historical and it would be a lot of work to exchange it. A lot of things are missing like a layout manager, a graphical GUI editor, ... But if you plan new applications from scratch there are might be better cross platform toolkits available. It depends also on the programming language you want to use. I personally would consider to use Java. It's platform independent and the tools support is great. Take a look on the GUI editor of NetBeans for example. You can use our component model to use Java as GUI frontend and use C++ core components via UNO. It would be an interesting use case. Just my 2 cents Juergen Does every module in OpenOffice.org follow the LGPL? Hope for your reply, thank you! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] xTextDocument clone
Hi Dinesh, Dinesh Chothe wrote: I am doing like this for creating text documents object, com.sun.star.text.XTextDocument xTextDocument =(com.sun.star.text.XTextDocument)UnoRuntime.queryInterface( com.sun.star.text.XTextDocument.class, m_xFrame.getController().getModel()); com.sun.star.text.XText xText = xTextDocument.getText(); Now I am processing this xText object and some contents from it. Then I wanted to use search() and replace() methods such that searching string from newer xTextDocument and replace on older xTextDocument. For this how do I create clone of xTextDocument? or any alternative way for doing this? I don't understand why you need to clone the document to do searching and replacing but anyway, cloning is not possible, at least at the moment. 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] Can we use AWT in our product?
Hi Lizhan! Well I am not a lawyer but well it´s LGPL so principally you could use it as long as you stick to the LGPL license terms. For example you must make sure that anyone can get the source code of the libraries you use which can be easily done by providing just a link to the OpenOffice.org website as long as you didn´t need to modify anything. If you need to modify and fork the libraries and you must publish those modifications also under the terms of the LGPL license. You must make sure that anyone can exchange eg. the vcl library in your product(s) by one compiled by him/herself, etc. etc. http://about.openoffice.org/index.html#licenses http://www.openoffice.org/licenses/lgpl_license.html Note though that this is currently not offered as a real toolkit which can be downloaded separate from other OpenOffice.org source code, so the work to extract the necessary things and to create an environment where only the AWT/VCL stuff is being compiled than is up to you. If you plan to do that work anyway it would be considered good OpenSource practice to contribute these changes back to the OpenOffice.org community than. Maybe this could lead to a situation where someday in the future there would be a separate downloadable VCL-Toolkit from the OpenOffice.org website as an additional thing to the OpenOffice.org program, no matter how good or bad such toolkit might be compared to other available cross-platform toolkits. With the same license restrictions you might also consider Juergens suggestion and use java for the GUI together with the OpenOffice.org UNO component technology (and corresponding OpenOffice.org libraries which also use the LGPL license) to call the C++ components you develop via UNO). Doing this would give you the advantage of being able to use GUI Editors like the one netbeans offers which is something not available for VCL while still developing your core components in C++. More information on UNO can be found in the Developers Guide which has just moved to the Wiki http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide But you probably already found this. Just my 2 cents. Bernd Eilers LiZhan(李湛) wrote: Hi Juergen Thank you for your help and suggestion. The product we are to develop will use C++ for developing language. It's purely new, also we lack experiences for cross-platform. So we prefer to use AWT. What we are consider is whether AWT is allowed to use in a commercial software. Can you give us some advises about corresponding legal issue? Thanks again! Best Wishes. -邮件原件- 发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 发送时间: 2008年5月23日 13:07 收件人: dev@openoffice.org 主题: Re: [dev] Can we use AWT in our product? LiZhan(李湛) wrote: Hi everyone, we are planning to develop several new commercial products for our company, and we need a cross-platform GUI lib used as their base GUI module. So can we use AWT(certainly with GSL and VCL) of OpenOffice.org in our program? well you can use it but i don't think that it wouldn't be the best descision. We use VCL because it is historical and it would be a lot of work to exchange it. A lot of things are missing like a layout manager, a graphical GUI editor, ... But if you plan new applications from scratch there are might be better cross platform toolkits available. It depends also on the programming language you want to use. I personally would consider to use Java. It's platform independent and the tools support is great. Take a look on the GUI editor of NetBeans for example. You can use our component model to use Java as GUI frontend and use C++ core components via UNO. It would be an interesting use case. Just my 2 cents Juergen Does every module in OpenOffice.org follow the LGPL? Hope for your reply, thank you! - 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: Re: [dev] Can we use AWT in our product?
On Fri, 2008-05-23 at 14:44 +0800, LiZhan(李湛) wrote: Hi Juergen Thank you for your help and suggestion. The product we are to develop will use C++ for developing language. It's purely new, also we lack experiences for cross-platform. So we prefer to use AWT. I would be you, I'd just abandon the idea of using AWT. As Jürgen mentionned, AWT/VCL is not really meant to be used outside of OpenOffice.org. If you really want to use a cross-platform toolkit, use something like Qt, wxWidgets or Gtk. Hub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Where to find cvs tag for the three-layer patch? FIXED
Juergen Schmidt writes:
[For the archives]
Try simply
UNO_TYPES=file:.../ure/share/misc/types.rdb
file:///.../basis3.0/program/offapi.rdb
UNO_SERVICES=file:.../ure/share/misc/services.rdb
file:///.../basis3.0/program/services.rdb
It should still work and i hope that is enough.
Yes, this is it. I put this into a new testrc file and removed
using unorc for defaultBootstrap_InitialComponentContext().
I also needed BRAND_BASE_DIR and OOO_BASE_DIR to be set. The old
CFG_INIFILE and BaseInstallation need no longer be set.
The full testrc:
OOO_INSTALL_PREFIX_URL=file://${OOO_INSTALL_PREFIX}
OOO_BASIS_URL=${OOO_INSTALL_PREFIX_URL}/openoffice.org/basis3.0
OOO_BASIS_BIN_URL=${OOO_INSTALL_PREFIX_URL}/openoffice.org/basis3.0/program
OOO_URE_URL=${OOO_INSTALL_PREFIX_URL}/openoffice.org/ure
#
#CFG_INIFILE=${OOO_BASIS_BIN_URL}/configmgrrc
#BaseInstallation=${OOO_BASIS_URL}
BRAND_BASE_DIR=${OOO_INSTALL_PREFIX_URL}/openoffice.org3
OOO_BASE_DIR=${OOO_BASIS_URL}
#
UNO_TYPES=${OOO_URE_URL}/share/misc/types.rdb
${OOO_BASIS_BIN_URL}/offapi.rdb
UNO_SERVICES=${OOO_URE_URL}/share/misc/services.rdb
${OOO_BASIS_BIN_URL}/services.rdb
only needs OOO_INSTALL_PREFIX to be set.
So thanks a lot, it works now!
Greetings,
Jan.
--
Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Can we use AWT in our product?
Hi Juergen, after recent discussions with other open source people, it seems that perception of OOo is not optimal in the FLOSS world. If I understood correctly, we may be able to improve that, if we spin-off parts of our technology, e.g. as we did / are doing with Uno. So, even if VCL and the Uno AWT are not optimal, it would at least benefit OOo and may improve out perception. Further I would say, that we are not going to get rid of VCL / Uno AWT in the foreseeable future, meaning that we keep maintaining both. Biggest problem I see is, that VCL / AWT are not independently available but just as being a part of OOo. So, from my point of view, LiZhan is very welcome to use VCL / AWT, but should be aware that some work is needed to make it available independently. Regards Kay Juergen Schmidt wrote: LiZhan(李湛) wrote: Hi everyone, we are planning to develop several new commercial products for our company, and we need a cross-platform GUI lib used as their base GUI module. So can we use AWT(certainly with GSL and VCL) of OpenOffice.org in our program? well you can use it but i don't think that it wouldn't be the best descision. We use VCL because it is historical and it would be a lot of work to exchange it. A lot of things are missing like a layout manager, a graphical GUI editor, ... But if you plan new applications from scratch there are might be better cross platform toolkits available. It depends also on the programming language you want to use. I personally would consider to use Java. It's platform independent and the tools support is great. Take a look on the GUI editor of NetBeans for example. You can use our component model to use Java as GUI frontend and use C++ core components via UNO. It would be an interesting use case. Just my 2 cents Juergen Does every module in OpenOffice.org follow the LGPL? Hope for your reply, thank you! - 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] VCL UI Rework
On Wed, 2008-05-14 at 13:15 +0200, Christian Lippka wrote: Michael Meeks wrote: There was some resistance to nominating this for 3.0 because ChristianL wanted to re-do the translation work to use Java Properties instead of the new transex tool we wrote that translated complete XML files per-lang. Ah ! - finally I see your reply while looking for something else in the archives ;-) [ a CC is most appreciated when using the collab-lists ]. This is bogus, I discussed with Jan that in my opinion it is a cleaner solution to use the Java Properties file for translation as I think the current way of doing it does not fit with the OOo translation database and tooling. I wanted to look into it but never said this would be a stopper for this cws. Oh; sorry - presumably I'm confused: but AFAIR there was a concern about the translation mechanism that held things up. I too like the Java properties (a bit) now I think about them - but, OTOH - I didn't like them a while back I can't remember why ;-) sadly that is all the state I kept. Nevertheless - I think Java Properties is the direction we want to go in now. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCL UI Rework
Hi Jurgen, On Fri, 2008-05-16 at 10:12 +0200, Juergen Schmidt wrote: whatever we will use in the future it will be important that we will have a GUI editor to make the design of new dialogs much more easier than today. Yep; absolutely - it's in the spec. and we have a quarter-functioning one already ;-) Ideally a replacement for the basic dialog editor and make it more general for internal development as well as extension development (includes Basic as it does today). Sure - ideally :-) I think it is important to concentrate on one format everywhere and consolidate the different formats that we have today over time. Well - I read the xmlscript code at some considerable length, and also the toolkit/ 'model' code too - and we tried to work with that to start with: we came to the conclusion after burning quite a while, that writing something simple clean was much easier with a containment hierarchy did something new. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCL UI Rework
Hi Michael, On Fri, 2008-05-16 at 10:12 +0200, Juergen Schmidt wrote: whatever we will use in the future it will be important that we will have a GUI editor to make the design of new dialogs much more easier than today. Yep; absolutely - it's in the spec. and we have a quarter-functioning one already ;-) Ideally a replacement for the basic dialog editor and make it more general for internal development as well as extension development (includes Basic as it does today). Sure - ideally :-) ... cut ... A big request: please allow using scripts from any of the OOo supported scripting languages. TIA, ---rony
[dev] Development at a Glance - Weekly Update CW21
Hi, here is the weekly update for calendar week 21: http://blogs.sun.com/GullFOSS/entry/development_at_a_glance_weekly47 Regards, Dieter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Development at a Glance - Weekly Update CW21
correction: http://blogs.sun.com/GullFOSS/entry/development_at_a_glance_weekly48 Regards, Dieter Dieter Loeschky wrote: Hi, here is the weekly update for calendar week 21: http://blogs.sun.com/GullFOSS/entry/development_at_a_glance_weekly47 Regards, Dieter - 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]
