[dev] On Modularization ...
OOo Folks, by now OOo has been regarded as the only real alternative office suite, sometimes hard to build, often admired for its feature completeness, somewhat beaten because of the memory footprint, understood to have one of the most classical graphical user interfaces ever, loved to recover MS documents, and so on ... Many words may be used for OOo, though small is not with them :-) OOo is a huge project, with lots of code and a more or less monolithic architecture. (Even :-) the ESC understands that size does not only has advantages (though it sometimes matters :-). (see http://wiki.services.openoffice.org/wiki/ESC_dashboard) It seems a hero (or five) is needed ... we (Cynthia, Xiuzhi, LiuTao, Ingo and I) want to move out to fill this position and therefore need your (mental) support ... ... we are not (yet) many copies, but we also have a plan, and we do look human etc. :-) The Goals are: - Adapt the OOo source to enable (more) custom-tailor products. - Support custom-tailor products in the build system by - checking out what is needed only, - building what is needed only, - re-using intermediate or final deliverables. - Enable pre-build intermediates and their usage. And this is what we want to do first: - Create a "build helper", responsible for - getting the source, - getting prerequisites and pre-builds, - configuring the sources, taking care of dependencies ..., - and (optionally) building it. - Add missing/useful configuration switches (e.g. for headless support). - Re-factor according to needs (e.g. writer only etc.). This "build helper" may be compared to the Linux kernels menuconfig / xconfig, first configure it extensively, ideally in a graphical way, than build it. Later on we may - rework SCP to configure the sources more dynamically, - provide pre-build intermediates to reduce build times for many, - disentangle the OOo applications, and - do even more ... We would like to create a(nother) (incubator) project as the umbrella for our enterprise, which we would like to call "Modularization" See http://wiki.services.openoffice.org/wiki/Modularization for a first sketch. It may be important to mention, that we want to keep things SIMPLE. Please give feedback or show interest!, this is needed according to our rules. May the force be with you ... argh - wrong movie :-) Kay - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] On Modularization ...
Hi Kay, Xiuzhi, all, Kay Ramme wrote: > OOo Folks, > > [...] > Many words may be used for OOo, though small is not with them :-) > OOo is a huge project, with lots of code and a more or less monolithic > architecture. (Even :-) the ESC understands that size does not only has > advantages (though it sometimes matters :-). > > (see http://wiki.services.openoffice.org/wiki/ESC_dashboard) > > It seems a hero (or five) is needed ... we (Cynthia, Xiuzhi, LiuTao, > Ingo and I) want to move out to fill this position and therefore need > your (mental) support ... Yes, please count me in. As the above mentioned Dashboard shows, I am supposed to be somehow involved. I am sure, we'll find some place where I can contribute. > [...] > We would like to create a(nother) (incubator) project as the umbrella > for our enterprise, which we would like to call > > "Modularization" > > See http://wiki.services.openoffice.org/wiki/Modularization for a first > sketch. > > It may be important to mention, that we want to keep things SIMPLE. > Please give feedback or show interest!, this is needed according to our > rules. +1, you have my support. > May the force be with you ... argh - wrong movie :-) > > Kay Best regards, Matthias - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [project leads] On Modularization ...
Hi, Le 30 avr. 09 à 10:29, Kay Ramme a écrit : And this is what we want to do first: - Create a "build helper", responsible for - getting the source, - getting prerequisites and pre-builds, - configuring the sources, taking care of dependencies ..., - and (optionally) building it. - Add missing/useful configuration switches (e.g. for headless support). - Re-factor according to needs (e.g. writer only etc.). This "build helper" may be compared to the Linux kernels menuconfig / xconfig, first configure it extensively, ideally in a graphical way, than build it. Glad to see the idea of "menuconfig like" I proposed several times (on IRC, discussing), and long time ago, has finaly found some echo ... :-) For the rest, I already thought on that for the 7-12 version of OOo for children I'm working on, but I think simplify the code in the sense you proposed before to improve performance, and fix bugs we have since stone age, or even know better how to load more efficiently all the libs, and so on is maybe not the best. But I can be wrong. Though, all the best for your project :) Have a nice day. Eric Bachard -- qɔᴉɹə
Re: [dev] Making Jdialog Modal in Java Extension
Hii Marcin, thanks a lot. In our case its not a simple swing
dialog, we are providing one
JFrame dialog which consists of
radioButtons,check-Boxes,some buttons etc.
By using this dialog we take user inputs and use these
inputs in OO dispatch method.
We have already developed this all part using swing and
its working fine expect "modal".
So now converting this all swing part to native will be
relly more cumbersome.
Would there be any other simple trick to make it modal?
2009/4/28 Marcin Miłkowski
> Hi Dinesh,
>
> if this is just an information dialog, try with native OOo controls - it's
> quite cumbersome to make OOo dialog really modal. I don't know how we solved
> this in LanguageTool (the code was long removed as we're not using a Swing
> dialog to check text anyway) but this was some dirty trick. It's easier to
> get an information dialog using XMessageBox like this:
>
> ...
>
>final XMessageBoxFactory messageBoxFactory = (XMessageBoxFactory)
> UnoRuntime
>.queryInterface(XMessageBoxFactory.class,
> parentWindowPeer.getToolkit());
>
>final Rectangle messageBoxRectangle = new Rectangle();
>
>final XMessageBox box = messageBoxFactory
>.createMessageBox(
>winPeer,
>messageBoxRectangle,
>"infobox",
>0,
>"Window Title",
>"Some beautiful info");
>box.execute();
>
> ...
>
> You get parentWindowPeer like this:
>
> final XModel model = (XModel) UnoRuntime.queryInterface(XModel.class,
> getxComponent());
> final XWindow parentWindow = model.getCurrentController().getFrame()
> .getContainerWindow();
> final XWindowPeer parentWindowPeer = (XWindowPeer) UnoRuntime
> .queryInterface(XWindowPeer.class, parentWindow);
>
>
> My getxComponent() looks like this:
>
> private XComponent getxComponent() {
>try {
> final XMultiComponentFactory xMCF = xContext.getServiceManager();
> final Object desktop = xMCF.createInstanceWithContext(
> "com.sun.star.frame.Desktop", xContext);
> final XDesktop xDesktop = (XDesktop) UnoRuntime.queryInterface(
> XDesktop.class, desktop);
> final XComponent xComponent = xDesktop.getCurrentComponent();
> return xComponent;
>} catch (final Throwable t) {
> showError(t);
> return null;
>}
> }
>
> and you should already get XComponentContext-type variable (here: xContext)
> when initializing your class in OOo in Main().
>
> Regards
> Marcin
>
> Dinesh Chothe pisze:
>
> Hello, I have been making one extension using java. In this I
>> want to simply populate simple dialog with some message on menu items
>> click
>> event.
>> I am able to get populate dialog but not getting it as
>> Modal.
>> Because dont know how to provide parent Dialog's object.
>>JDialog d = *new* JDialog(parent);
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
> For additional commands, e-mail: dev-h...@openoffice.org
>
>
--
Thanks and Regards,
Dinesh
Re: [dev] print option
shiva prasad wrote: > Hi, > Can any one explain the flow, when we click the print option > on openoffice.org "writer" till it prints on the printer, code level. As you seem to ask for the code that actually prints something, I assume that "print option" shall mean that you want to see the code that is executed if the "print" button ic clicked, right? There's quite a lot of code involved. The print request first is handled in sfx2/source/view/viewprn.cxx as part of the Dispatch Framework. Here parameters and options are collected and then passed to the currently active view of the document by calling the virtual method SfxViewShell::DoPrint that itself sooner or later ends up in the also virtual method SfxViewShell::Print. These methods are overwritten in the particular application, in case of Writer its code in sw/source/ui/uiview. The application will send its output to an instance of the vcl class "Printer". In all cases I know, the code to handle that is in a core document class that will be called from the particular SfxViewShell instance of the application. At best you can follow the flow of operation in a debugger. In Writer you should compile the following code with debug information: sfx2/source/view sw/source/ui/uiview sw/source/ui/app sw/source/core/view sw/source/core/doc The code in vcl that sends the ooutput to the printer is not mentioned here, it's also platform dependent. IIRC having vcl/source/gdi and the "gdi" folder in the platform dependent part of VCL compiled with debug should be enough, but I'm not completely sure. You will not need all files in the mentioned folders to be compiled with debug for printing, but it's easier to prepare them all instead of finding out which one of them might not be needed. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] On Modularization ...
Caolán McNamara wrote: On Thu, 2009-04-30 at 10:29 +0200, Kay Ramme wrote: This "build helper" may be compared to the Linux kernels menuconfig / xconfig, first configure it extensively, ideally in a graphical way, than build it. I'm not particularly against all this stuff, but it seems like a lot of work for very little gain. I mean "./configure; make" should be the goal. All the rest of the fiddly --with-this, --with-that, --the-other" shouldn't really be encouraged to be used unless necessary. +1 FWIW, for me the ideal build-modularization goal is something along the modular X model, where a similar single build-system that created a gadzillion programs and libraries was split up where each target could be checked out individually and built separately from scratch linking against previously installed headers/libraries from previously built targets. e.g. to build vcl "standalone" you can nearly do that, checkout just vcl, use the sdk configuration mechanism of setsdkenv_unix, and build against headers from the existing sdk headers + headers from comphelper, i18npool, psprint (gone now), svtools, tools & vos (should go away) and link against the existing libraries from the matching ure packages and matching installed OOo. I think that there's better prototypes in ooo-build, especially to address splitting scp2 up into the individual projects, etc. to make a more serious stab at it. On a related note it would be a good thing to get simple vcl demo programs (like in vcl/workben) functional again without a complete OOo installation. One of the many things I should do but don't really have the time for. Just my 2 cents, pl -- Sanity is just a bad excuse for a lack of imagination. -- Author unknown Registered Office: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Commercial register of the Local Court of Munich: HRB 161028 Managing Directors: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Chairman of the Supervisory Board: Martin Haering - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [project leads] On Modularization ...
Kay, Le Thu, 30 Apr 2009 10:29:47 +0200, Kay Ramme a écrit : > > OOo Folks, > > by now OOo has been regarded as the only real alternative office > suite, sometimes hard to build, often admired for its feature > completeness, somewhat beaten because of the memory footprint, > understood to have one of the most classical graphical user > interfaces ever, loved to recover MS documents, and so on ... > > Many words may be used for OOo, though small is not with them :-) > OOo is a huge project, with lots of code and a more or less monolithic > architecture. (Even :-) the ESC understands that size does not only > has advantages (though it sometimes matters :-). > > (see http://wiki.services.openoffice.org/wiki/ESC_dashboard) > > It seems a hero (or five) is needed ... we (Cynthia, Xiuzhi, LiuTao, > Ingo and I) want to move out to fill this position and therefore need > your (mental) support ... > > ... we are not (yet) many copies, but we also have a plan, and we do > look human etc. :-) > > The Goals are: > - Adapt the OOo source to enable (more) custom-tailor products. > - Support custom-tailor products in the build system by > - checking out what is needed only, > - building what is needed only, > - re-using intermediate or final deliverables. > - Enable pre-build intermediates and their usage. > > And this is what we want to do first: > - Create a "build helper", responsible for > - getting the source, > - getting prerequisites and pre-builds, > - configuring the sources, taking care of dependencies ..., > - and (optionally) building it. > - Add missing/useful configuration switches (e.g. for headless > support). > - Re-factor according to needs (e.g. writer only etc.). > > This "build helper" may be compared to the Linux kernels menuconfig / > xconfig, first configure it extensively, ideally in a graphical way, > than build it. > > Later on we may > - rework SCP to configure the sources more dynamically, > - provide pre-build intermediates to reduce build times for many, > - disentangle the OOo applications, and > - do even more ... > > We would like to create a(nother) (incubator) project as the umbrella > for our enterprise, which we would like to call > > "Modularization" > > See http://wiki.services.openoffice.org/wiki/Modularization for a > first sketch. > > It may be important to mention, that we want to keep things SIMPLE. > Please give feedback or show interest!, this is needed according to > our rules. > > > May the force be with you ... argh - wrong movie :-) I have read the wiki pages, and while I'm all for this kind of vision, I am not sure if I understood this correctly: modularization for you seems to essentially takes place at the building level, and not so much an application level. This would mean, for instance, that we could have several "sub-versions of OOo", but this would be different from having an office suite with "modular" applications (with less common dependencies, etc.). Am I getting this right or am I making things too complex? Anyway; you have my interest :-) Best, Charles. > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [project leads] On Modularization ...
Hi Christian, Christian Lippka - Sun Microsystems GmbH - Hamburg wrote: For me the perfect "modularization" would mean that an application is just a set of configuration files that use a set of "office building blocks" and define the user interface. Yep, same thoughts here :-) Beside that, the plan from Kay&all makes sense for me, esp. starting at the build level. Good to hear. Just my 2c, Christian PS: I also like to propose a theme song for this epic endeavor :-) http://www.youtube.com/watch?v=WXY_3kXRpWA Seems that at least I need some more practice for the acrobatics :-) Best Kay - To unsubscribe, e-mail: project_leads-unsubscr...@openoffice.org For additional commands, e-mail: project_leads-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: [project leads] On Modularization ...
Kay, Christian, Le Thu, 30 Apr 2009 11:43:02 +0200, Kay Ramme a écrit : > > Hi Charles, > > Charles-H. Schulz wrote: > > > > I have read the wiki pages, and while I'm all for this kind of > > vision, I am not sure if I understood this correctly: > > modularization for you seems to essentially takes place at the > > building level, and not so much an application level. This would > > mean, for instance, that we could have several "sub-versions of > > OOo", but this would be different from having an office suite with > > "modular" applications (with less common dependencies, etc.). Am I > > getting this right or am I making things too complex? > You get it right, though you are missing the pre-build thing ... > > First goal is to ease building OOo and variants in a static way, by > developing a "build helper" and by extending/adapting the configure > script as well as the code. > > If you have taking a look at what "configure" currently offers wrt > Mozilla, you see that you actually can re-use pre-build binaries. To > improve and simplify the overall build experience, we would like to > generalize this approach to other parts of OOo as well. Some obvious > candidates for this are the build-system and Uno, as developers > typically don't change them so much, thus having them pre-build would > reduce build times etc. > > To make things simple, we just would like to achieve the above in a > static way, e.g. during "configure". If it proves viable, we > certainly would like to convert this approach to be more dynamic, > e.g. offering the different pre-build modules as extensions (or > similar) ... > > Let's just start with something simple, things tend to become complex > over time anyway :-) They do indeed. I just wanted to clarify where this initiative was going and you have my support. Best, Charles. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [project leads] On Modularization ...
Hi Charles, Charles-H. Schulz wrote: [...] but this would be different from having an office suite with "modular" applications (with less common dependencies, etc.). Am I getting this right or am I making things too complex? personally I think this is a myth in office modularization. Sure users wants an office with a small footprint. Also many want only the applications they are interested in. But at the same time they want - Their shapes in calc behave exactly the same as shapes in impress - Their formulas in writer behave exactly the same as formulas in calc - Their text in impress behave exactly the same way as text in writer So the common feature set of all applications from my personal experience is already most of the functionality there is. For me the perfect "modularization" would mean that an application is just a set of configuration files that use a set of "office building blocks" and define the user interface. Beside that, the plan from Kay&all makes sense for me, esp. starting at the build level. Just my 2c, Christian PS: I also like to propose a theme song for this epic endeavor :-) http://www.youtube.com/watch?v=WXY_3kXRpWA - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] On Modularization ...
On Thu, 2009-04-30 at 10:29 +0200, Kay Ramme wrote: > - Add missing/useful configuration switches (e.g. for headless support). FWIW vcl headless support is always just built at the moment, so not sure of its role an example of a missing/useful configuration switch. > This "build helper" may be compared to the Linux kernels menuconfig / > xconfig, first configure it extensively, ideally in a graphical way, > than build it. I'm not particularly against all this stuff, but it seems like a lot of work for very little gain. I mean "./configure; make" should be the goal. All the rest of the fiddly --with-this, --with-that, --the-other" shouldn't really be encouraged to be used unless necessary. > Later on we may > - rework SCP to configure the sources more dynamically, > - provide pre-build intermediates to reduce build times for many, > - disentangle the OOo applications, and > - do even more ... FWIW, for me the ideal build-modularization goal is something along the modular X model, where a similar single build-system that created a gadzillion programs and libraries was split up where each target could be checked out individually and built separately from scratch linking against previously installed headers/libraries from previously built targets. e.g. to build vcl "standalone" you can nearly do that, checkout just vcl, use the sdk configuration mechanism of setsdkenv_unix, and build against headers from the existing sdk headers + headers from comphelper, i18npool, psprint (gone now), svtools, tools & vos (should go away) and link against the existing libraries from the matching ure packages and matching installed OOo. I think that there's better prototypes in ooo-build, especially to address splitting scp2 up into the individual projects, etc. to make a more serious stab at it. i.e. the use case is: linux developer has OOo installed, sees a little bug, grabs the distro source package for the little piece of OOo which has the bug, rebuilds it in 40 nano-seconds because he doesn't have to rebuild the rest of it. Fixes bug, is delighted with himself, becomes amazing OOo contributor. I know that I'd never have ever build X because of the long build-time of the old tree, I just wasn't that interested. But with the modular stuff, I can grab my distros libICE or whatever and see if those valgrind warnings really are bugs or not rather than just whacking them with a supressions file. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Making Jdialog Modal in Java Extension
Hi Dinesh,
Am 30.04.2009 12:03, schrieb Dinesh Chothe:
Hii Marcin, thanks a lot. In our case its not a simple swing
dialog, we are providing one
JFrame dialog which consists of
radioButtons,check-Boxes,some buttons etc.
By using this dialog we take user inputs and use these
inputs in OO dispatch method.
We have already developed this all part using swing and
its working fine expect "modal".
So now converting this all swing part to native will be
relly more cumbersome.
Would there be any other simple trick to make it modal?
2009/4/28 Marcin Miłkowski
a (dirty) workaround is to create a modal UNO-AWT dialog in a new thread
before showing the Swing dialog and to set a flag.
If the Swing dialog ends, then the UNO-AWT dialog must end.
e.g.:
XToolkit xToolkit = (XToolkit) UnoRuntime.queryInterface(XToolkit.class,
MCF.createInstanceWithContext(
"com.sun.star.awt.Toolkit", context));
Object dialog =
xMCF.createInstanceWithContext("com.sun.star.awt.UnoControlDialog",
Context);
Object model =
xMCF.createInstanceWithContext("com.sun.star.awt.UnoControlDialogModel",
context);
XControlModel xControlModel = (XControlModel)
UnoRuntime.queryInterface(XControlModel.class, model);
XControl xControl = (XControl) UnoRuntime.queryInterface(
XControl.class, dialog);
xDialog = (XDialog) UnoRuntime.queryInterface(XDialog.class, dialog);
xControl.setModel(xControlModel);
XWindowPeer xWindowPeer = null;
WindowDescriptor desc = new com.sun.star.awt.WindowDescriptor();
desc.Type = com.sun.star.awt.WindowClass.MODALTOP;
xWindowPeer = xToolkit.createWindow(desc);
xControl.createPeer(xToolkit, xWindowPeer);
xDialog.execute();
Regards
Peter
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] On Modularization ...
Caolan, Caolán McNamara wrote: On Thu, 2009-04-30 at 10:29 +0200, Kay Ramme wrote: - Add missing/useful configuration switches (e.g. for headless support). FWIW vcl headless support is always just built at the moment, so not sure of its role an example of a missing/useful configuration switch. ... may be not the best example, agreed ... This "build helper" may be compared to the Linux kernels menuconfig / xconfig, first configure it extensively, ideally in a graphical way, than build it. I'm not particularly against all this stuff, but it seems like a lot of work for very little gain. I mean "./configure; make" should be the goal. All the rest of the fiddly --with-this, --with-that, --the-other" shouldn't really be encouraged to be used unless necessary. I should have been more precise - what I mean is not only to add more enable/disable switches, but to add/change switches to support something as build/pre-build/disabled. Later on we may - rework SCP to configure the sources more dynamically, - provide pre-build intermediates to reduce build times for many, - disentangle the OOo applications, and - do even more ... FWIW, for me the ideal build-modularization goal is something along the modular X model, where a similar single build-system that created a gadzillion programs and libraries was split up where each target could be checked out individually and built separately from scratch linking against previously installed headers/libraries from previously built targets. This is amongst the things behind this effort, utilize the "build helper" to select the parts you want to develop on, only things dependent on these may need to be build, everything else may be pre-build / abandoned. e.g. to build vcl "standalone" you can nearly do that, checkout just vcl, use the sdk configuration mechanism of setsdkenv_unix, and build against headers from the existing sdk headers + headers from comphelper, i18npool, psprint (gone now), svtools, tools & vos (should go away) and link against the existing libraries from the matching ure packages and matching installed OOo. I think that there's better prototypes in ooo-build, especially to address splitting scp2 up into the individual projects, etc. to make a more serious stab at it. To simplify things, I'd like to select what needs to be build at configuration time (comparable to the Moz stuff). Obviously this is very static, later on we may be able to introduce some more dynamics, e.g. pre-build packages etc. i.e. the use case is: linux developer has OOo installed, sees a little bug, grabs the distro source package for the little piece of OOo which has the bug, rebuilds it in 40 nano-seconds because he doesn't have to rebuild the rest of it. Fixes bug, is delighted with himself, becomes amazing OOo contributor. This is what I want! I know that I'd never have ever build X because of the long build-time of the old tree, I just wasn't that interested. But with the modular stuff, I can grab my distros libICE or whatever and see if those valgrind warnings really are bugs or not rather than just whacking them with a supressions file. Just let's start simple, let's take care of prerequisites, 3rd party stuff etc. followed by more in an iterative fashion ... Only what has been identified as a "module" (AKA can been "configured"), may become something pre-build respectively an "extension" or be left out, to enable focusing on the relevant parts. C. Best regards Kay - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [project leads] On Modularization ...
Hi Charles, Charles-H. Schulz wrote: I have read the wiki pages, and while I'm all for this kind of vision, I am not sure if I understood this correctly: modularization for you seems to essentially takes place at the building level, and not so much an application level. This would mean, for instance, that we could have several "sub-versions of OOo", but this would be different from having an office suite with "modular" applications (with less common dependencies, etc.). Am I getting this right or am I making things too complex? You get it right, though you are missing the pre-build thing ... First goal is to ease building OOo and variants in a static way, by developing a "build helper" and by extending/adapting the configure script as well as the code. If you have taking a look at what "configure" currently offers wrt Mozilla, you see that you actually can re-use pre-build binaries. To improve and simplify the overall build experience, we would like to generalize this approach to other parts of OOo as well. Some obvious candidates for this are the build-system and Uno, as developers typically don't change them so much, thus having them pre-build would reduce build times etc. To make things simple, we just would like to achieve the above in a static way, e.g. during "configure". If it proves viable, we certainly would like to convert this approach to be more dynamic, e.g. offering the different pre-build modules as extensions (or similar) ... Let's just start with something simple, things tend to become complex over time anyway :-) Anyway; you have my interest :-) Good to hear! Best, Charles. Kay - To unsubscribe, e-mail: project_leads-unsubscr...@openoffice.org For additional commands, e-mail: project_leads-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] On Modularization ...
On Thu, 2009-04-30 at 14:07 +0200, Kay Ramme - Sun Germany - Hamburg wrote: > I should have been more precise - what I mean is not only to add more > enable/disable switches, but to add/change switches to support something > as build/pre-build/disabled. > utilize the "build helper" to select the parts you want to develop on, > only things dependent on these may need to be build, everything else > may be pre-build / abandoned. The above sounds a little like the current single hierarchical build tree with a single toplevel configure script but with a bunch of --enable-prebuild-vcl --enable-prebuild-i18npool etc options and an understandable requirement for a build-helper at that stage (assuming we're talking about per module of per module-bundle pre-build/solvers) If you're thinking about build-helpers, then e.g. jhbuild route might be worth a look http://library.gnome.org/devel/jhbuild/unstable/introduction.html.en and follow an alternative route where each project/module group is a toplevel project with a little configure.in for "find the compiler"/"tell me where the sdk is"/"where should I make install to". Conceptually each *always* uses the headers of, and links against the libraries of prebuilt dependencies, and if there's a need for a build-helper then its a separate toplevel tool which takes care of the case of someone wanting to build the entirety from scratch. C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] On Modularization ...
Caolán McNamara wrote: On Thu, 2009-04-30 at 14:07 +0200, Kay Ramme - Sun Germany - Hamburg wrote: I should have been more precise - what I mean is not only to add more enable/disable switches, but to add/change switches to support something as build/pre-build/disabled. utilize the "build helper" to select the parts you want to develop on, only things dependent on these may need to be build, everything else may be pre-build / abandoned. The above sounds a little like the current single hierarchical build tree with a single toplevel configure script but with a bunch of --enable-prebuild-vcl --enable-prebuild-i18npool etc options and an understandable requirement for a build-helper at that stage (assuming we're talking about per module of per module-bundle pre-build/solvers) More or less, yes. The advantage being the you may build only what you need, so it is not only "--enable-prebuild-writer", but also "--disable-writer" ... If you're thinking about build-helpers, then e.g. jhbuild route might be worth a look http://library.gnome.org/devel/jhbuild/unstable/introduction.html.en and follow an alternative route where each project/module group is a toplevel project with a little configure.in for "find the compiler"/"tell me where the sdk is"/"where should I make install to". Conceptually each *always* uses the headers of, and links against the libraries of prebuilt dependencies, and if there's a need for a build-helper then its a separate toplevel tool which takes care of the case of someone wanting to build the entirety from scratch. I think not in particular the entirety but the parts. The entirety is _already_ buildable ... From the intro page jhbuild sounds what I mean, unfortunately already the second page makes it more difficult to install than I would like it to see ... nice that it already integrates with build bots :-) C. Kay - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] On Modularization ...
On Thu, 2009-04-30 at 16:34 +0200, Kay Ramme - Sun Germany - Hamburg wrote: > > The above sounds a little like the current single hierarchical build > > tree with a single toplevel configure script but with a bunch of > > --enable-prebuild-vcl --enable-prebuild-i18npool etc > > options and an understandable requirement for a build-helper at that > > stage (assuming we're talking about per module of per module-bundle > > pre-build/solvers) > More or less, yes. The advantage being the you may build only what you > need, so it is not only "--enable-prebuild-writer", but also > "--disable-writer" ... I personally wouldn't be too much a fan of that. Its not really what I'd like to use, but more akin to the linux kernel configuration system where everything still lives in one tarball. I'd much prefer to be able to download/checkout (like libICE in modular X) just the vcl source, unpack it, run configure inside it and make it. Installing and building (or downloading the binaries of) if necessary ure.tar.gz, etc. beforehand, rather than effectively downloading/checking out the full openoffice.org.tar.gz and then using ./configure --with-prebuild-ure --disable-all-except-vcl. Hammering OOo closer to emulating the "typical" project model like gnome/modulear X would be nice for a good few reasons, mostly that all our distro mechanisms are effectively designed around the standalone tarball that configure and build against pre-installed dependencies ;-) C. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
