[dev] Is there a graphical development tool for developing, building and debugging OOo?
Hi everyone! It seems that all tools for developing, building or debugging OOo are in text mode. They are hard to study, and hard to use. So I just wonder whether there are graphics tools for doing these things, just like the Visual Studio for windows development. If there are, where can I get them? Thank you very much. Best Wishes~
[dev] 答复: Re: [dev] Can we use AWT in our product?
Hi Hubert Thank you for your advise! We will consider it carefully. We want to find a GUI toolkit that is implemented by light-weight UI controls like VCL. So that Its looks the same in different OSs. The wxWidget is implemented by heavy-weight controls as I known, I don’t know whether the Qt or Gtk do the same. Maybe I have to get some knowledge of them, I'm not familiar with them yet. Best Wishes~ -邮件原件- 发件人: Hubert Figuiere [mailto:[EMAIL PROTECTED] 发送时间: 2008年5月23日 21:13 收件人: dev@openoffice.org 主题: 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]
[dev] 答复: [dev] Can we use AWT in our product?
Hi, Bernd Thank you for your reply! It's very helpful for us. We are very interesting about VCL and making it separated from OOo like URE did. But as you said, a lot of work to do. So we have to consider the VCL solution for us very carefully, although in my opinion, I would like to do this so much. Thank you again. Best Wishes~ -邮件原件- 发件人: Bernd Eilers [mailto:[EMAIL PROTECTED] 发送时间: 2008年5月23日 21:07 收件人: dev@openoffice.org 主题: 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?
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]
[dev] Can we use AWT in our product?
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? Does every module in OpenOffice.org follow the LGPL? Hope for your reply, thank you!
Re: [dev] I thought that it was a bug
hehe, I understand you now.
I am a new uno developer, and was not familiar with cvs very well. ;)
-邮件原件-
发件人: Stephan Bergmann [mailto:[EMAIL PROTECTED]
发送时间: 2008年5月13日 22:43
收件人: dev@openoffice.org
主题: Re: [dev] I thought that it was a bug
I understood you very well. That is why I wrote: "Please file an
issue." :)
-Stephan
LiZhan(李湛) wrote:
> sorry, I thought that u might misunderstand me.
> I mean that: In cppu/inc/uno/lbnames.h:1.20, the TMP_CPPU_ENV should not be
> undefined.
> Because that will cause I get a wrong string "TMP_CPPU_ENV" when I reference
> CPPU_CURRENT_LANGUAGE_BINDING_NAME macro in my uno component written in VC9
> like that:
>
> __declspec(dllexport) void SAL_CALL
> component_getImplementationEnvironment(
> sal_Char const ** ppEnvTypeName, uno_Environment ** ppEnv )
> {
> *ppEnvTypeName = CPPU_CURRENT_LANGUAGE_BINDING_NAME;
> }
> Now, the pointer *ppEnvTypeName points to the string" TMP_CPPU_ENV " not
> "msci" as expected.
> Then it will fail, when I load the component through uno.exe.
>
> -邮件原件-
> 发件人: Stephan Bergmann [mailto:[EMAIL PROTECTED]
> 发送时间: 2008年5月13日 19:12
> 收件人: dev@openoffice.org
> 主题: Re: [dev] I thought that it was a bug
>
> LiZhan(李湛) wrote:
>> In openoffice.org_2.4_sdk\include\uno\lbnames.h
> [...]
>> #undef TMP_CPPU_ENV //it should be commeted, otherwise it would cause
>> CPPU_CURRENT_LANGUAGE_BINDING_NAME macro generate TMP_CPPU_ENV, In
>> Visual C++ 2008, not expected as msci. Because the TMP_CPPU_ENV was
>> undefined when reference the macro
>> CPPU_CURRENT_LANGUAGE_BINDING_NAME.
>
> Yes, cppu/inc/uno/lbnames.h:1.14.8.1 "missing undef" was obviously a
> mistake. Please file an issue. (The reason this was not noticed before
> is probably that in an OOo build CPPU_ENV is set to the correct value
> via solenv/inc/target.mk:1.207 l. 1450 and/or
> solenv/inc/tg_compv.mk:1.22 l. 145, anyway.)
>
> -Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] I thought that it was a bug
sorry, I thought that u might misunderstand me.
I mean that: In cppu/inc/uno/lbnames.h:1.20, the TMP_CPPU_ENV should not be
undefined.
Because that will cause I get a wrong string "TMP_CPPU_ENV" when I reference
CPPU_CURRENT_LANGUAGE_BINDING_NAME macro in my uno component written in VC9
like that:
__declspec(dllexport) void SAL_CALL
component_getImplementationEnvironment(
sal_Char const ** ppEnvTypeName, uno_Environment ** ppEnv )
{
*ppEnvTypeName = CPPU_CURRENT_LANGUAGE_BINDING_NAME;
}
Now, the pointer *ppEnvTypeName points to the string" TMP_CPPU_ENV " not "msci"
as expected.
Then it will fail, when I load the component through uno.exe.
-邮件原件-
发件人: Stephan Bergmann [mailto:[EMAIL PROTECTED]
发送时间: 2008年5月13日 19:12
收件人: dev@openoffice.org
主题: Re: [dev] I thought that it was a bug
LiZhan(李湛) wrote:
> In openoffice.org_2.4_sdk\include\uno\lbnames.h
[...]
> #undef TMP_CPPU_ENV //it should be commeted, otherwise it would cause
> CPPU_CURRENT_LANGUAGE_BINDING_NAME macro generate TMP_CPPU_ENV, In
> Visual C++ 2008, not expected as msci. Because the TMP_CPPU_ENV was
> undefined when reference the macro
> CPPU_CURRENT_LANGUAGE_BINDING_NAME.
Yes, cppu/inc/uno/lbnames.h:1.14.8.1 "missing undef" was obviously a
mistake. Please file an issue. (The reason this was not noticed before
is probably that in an OOo build CPPU_ENV is set to the correct value
via solenv/inc/target.mk:1.207 l. 1450 and/or
solenv/inc/tg_compv.mk:1.22 l. 145, anyway.)
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] I thought that it was a bug
In openoffice.org_2.4_sdk\include\uno\lbnames.h #if (! defined (CPPU_ENV) && defined (TMP_CPPU_ENV)) #define CPPU_ENV TMP_CPPU_ENV #endif #ifdef CPPU_ENV #define CPPU_STRINGIFY_EX( x ) #x #define CPPU_STRINGIFY( x ) CPPU_STRINGIFY_EX( x ) /** Name for C++ compiler/ platform, e.g. "gcc3", "msci" */ #define CPPU_CURRENT_LANGUAGE_BINDING_NAME CPPU_STRINGIFY( CPPU_ENV ) #else #error "No supported C++ compiler environment." provoking error here, because PP ignores #error #endif /* CPPU_ENV */ #undef TMP_CPPU_ENV //it should be commeted, otherwise it would cause CPPU_CURRENT_LANGUAGE_BINDING_NAME macro generate TMP_CPPU_ENV, In Visual C++ 2008, not expected as msci. Because the TMP_CPPU_ENV was undefined when reference the macro CPPU_CURRENT_LANGUAGE_BINDING_NAME. #endif /* __cplusplus */
