Re: [dev] Building OpenOffice.org with GNU make
Congratulations to the proof of concept. Really happy to see this starting. As mentioned somewhere else, I am a GNU make fan :-) Kay bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: Hi Lists, The Build Environment Effort Team(1) has implemented a proof-of-concept on how to build OpenOffice.org using GNU make. The rationale for this is explained in this blogpost on GullFOSS: http://blogs.sun.com/GullFOSS/entry/building_openoffice_org_with_gnu The Build Environment Effort Team is carefully optimistic that updating the build system in this way would benefit the development of OpenOffice.org. Your questions, opinions and ideas about this topic at welcome. You are invited to discuss a possible move to GNU make and its implications on the mailing list d...@tools.openoffice.org. I will try to answer questions ASAP. Best Regards, Bjoern Michaelsen (1) http://wiki.services.openoffice.org/wiki/Build_Environment_Effort - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Building Mac OS X version on Linux?
Hi Kristjan, cross compiling OOo is not easy. Even cross compiling for the same OS and a different arch is difficult. A while ago I did manage to build OOo for Linux/ARM on a Linux/x64 box in a reasonable amount of time. It took a me a while to get that running, and I was not able to achieve that without emulating the hardware. Especially in the early phase of the build some tools and other stuff gets compiled which is later on needed for building again - this makes it hard to avoid any emulation. If there is something as the userland qemu for Mac OS X binaries, you may want to apply my approach (http://blogs.sun.com/GullFOSS/entry/arm_again). Regards Kay Kristján Bjarni Guðmundsson wrote: I have been wondering if it is possible to build OpenOffice.org Mac OS X version on the Linux platform? By using a cross compiler. Has anyone tried anything like this before or is this just something that is impossible to do? - 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 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. Understood and (mostly) agreed ... let's just see where this heads, IMHO the important point is, that we have something to start with :-) 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 ;-) Understood, though I am not sure if this is really wished with OOo being cross platform ... 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
[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
[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 Kayall 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] 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 ...
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] error while loading shared libraries: libpthread.so.0: cannot enable executable stack as shared object requires: Invalid argument
Chuangjiang, did you actually succeed in building OOo in scratchbox respectively user mode qemu? How to did you workaround the ld.so origin problem (./sysdeps/unix/sysv/linux/dl-origin.c: ...)) just by disabling the assertion :-) = Thanks for your help Kay jiangchuang wrote: Dear everyone: I'm building OOH680_m12 in the Scratchbox environment. Now I've got the following error message. /home/arm/ooo_OOH680_m12_src/icu/unxlngr.pro/misc/build/icu/source/bin/pkgdata: error while loading shared libraries: libpthread.so.0: cannot enable executable stack as shared object requires: Invalid argument Could you give me any advice? TIA. Best Regards. Chuangjiang - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] error while loading shared libraries: libpthread.so.0: cannot enable executable stack as shared object requires: Invalid argument
Sorry for bothering ... found the issue, just needed to fix qemu :-) Kay Kay Ramme - Sun Germany - Hamburg wrote: Chuangjiang, did you actually succeed in building OOo in scratchbox respectively user mode qemu? How to did you workaround the ld.so origin problem (./sysdeps/unix/sysv/linux/dl-origin.c: ...)) just by disabling the assertion :-) = Thanks for your help Kay jiangchuang wrote: Dear everyone: I'm building OOH680_m12 in the Scratchbox environment. Now I've got the following error message. /home/arm/ooo_OOH680_m12_src/icu/unxlngr.pro/misc/build/icu/source/bin/pkgdata: error while loading shared libraries: libpthread.so.0: cannot enable executable stack as shared object requires: Invalid argument Could you give me any advice? TIA. Best Regards. Chuangjiang - 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] Re: [discuss] [EMAIL PROTECTED] - Becoming an (Incubator) Project
Hi Martin, Martin Hollmichel wrote: all, Let me do some additional comments regarding our current project setup since this is a project which not necessarily has to do with OpenOffice.org core technology or native lang projects. I tend to disagree here ... but lets see ... Currently the Incubator category has been set up to provide some space to test new ideas (see: http://projects.openoffice.org/incubator.html The Incubator category exists to provide a space for community members to test ideas. These ideas can be coding or not. OK It seems to be the expectation that the projects in Incubator should find their final destination either in Accepted Projects (http://projects.openoffice.org/accepted.html) or in Native-Lang Projects (http://projects.openoffice.org/native-lang.html) or find their end sooner or later in /dev/null. Since the [EMAIL PROTECTED] project does not meet the criteria for being an accepted project (... projects that include core technical projects as well as key user information projects.) nor the criteria of a native lang project it seems not be that easy for me to just vote +1 without this lengthy comment. That means, that you do in principal vote with a +1, doesn't it? In my daydreams, I see the [EMAIL PROTECTED] becoming the OOo suites complement on the server. Thus I hope it to certainly become a core technical project. I think we need to revisit these guidelines and may invent a new category like OOo related projects. Candidates for this project might be the [EMAIL PROTECTED] but also the Extensions or the Education project. To encourage the creation of such projects I would like to see the conditions for those project at a low level. At the same time this also would mean that these project are also not in the scope of the Community Council Charter (http://council.openoffice.org/CouncilProposal.html). Ah, I may understand what you are talking about now ... it is about the CCs relationship e.g. with [EMAIL PROTECTED] right? For example, if the CC needs to coordinate releases of [EMAIL PROTECTED] or extensions etc. right? At this time many OpenOffice.org related projects are hosted anywhere (e.g. more than 100 on sourceforge) but not within the OpenOffice.org domain. I think it would help the overall OpenOffice.org project if we would introduce such new category for these projects. I agree that we should encourage any OOo related project to be hosted on OOo. So, I am not sure yet if we really need a new category, I have to admit, that I am even not sure we need any categories at all ... yes I know, I am slow ;-) The current infrastructure on collab.net has some limitations (single database Issuetracker instance for all project) which makes the introduction of an independent category difficult but I guess this is just a technical problem and should be solvable in the one or other way. but under the current guidelines of the project I'm fine with voting for the [EMAIL PROTECTED] project becoming a regular incubator project of OpenOffice.org, Ahhh, I hoped so :-) thanks! Martin Kay Kay Ramme - Sun Germany - Hamburg wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [discuss] [EMAIL PROTECTED] - Becoming an (Incubator) Project
Hi Mathias, Mathias Bauer wrote: I think the [EMAIL PROTECTED] project at least in its current state is still bound to OOo as it is the central building block. As long as this is not becoming a subject to change it makes a lot of sense to keep it in the OOo project. But YMMV. it is currently bound to the OOo suite, as the suite is used to actually do all editing etc., though this is not necessarily the case, e.g. it could use AbiWord or any other application capable of dealing with ODF and WebDAV. It is bound to the OOo site, as I am bound to the OOo site and as long as people think that it is a valuable addition :-) I know it may sound ?foolhardy?, but I think that we may need to extend the scope of the OOo site somewhat, to be able to stay competitive in the market and in the Open Source movement. If you remember our mission statement, To create, as a community, the leading international office suite that will run on all major platforms and provide access to all functionality and data through open-component based APIs and an XML-based file format. you see, that our defined goal basically only is about developing a classical desktop application. As the world moves forward, we can see that the WWW and HTML (and is flavors) as well as Ajax etc. are becoming more and more important. In my little world this threatens ODF and OOo and any other classical document format and application suite. Luckily we have the chance to integrate into the WWW world, as OOo already supports WebDAV etc. and as ODF is quite expressive, though there are some (glue) pieces left ... namely something on the server, e.g. the [EMAIL PROTECTED] :-) Ciao, Mathias Best regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [project leads] [EMAIL PROTECTED] - Becoming an (Incubator) Project
Hi again OOo Folks, actually I thought I just would express my desire making the [EMAIL PROTECTED] effort an incubator project, and to you ask later on to vote on it, after we have had some time to discuss and sort out any pitfalls, problems etc. It seems, that the majority of you instead preferred to directly vote :-) By now I have many votes, only +1s, as well as a constructive question regarding URLs etc. from Andrea Pescetti (which I hope I have answered satisfiable). Thus I am going to talk to Louis soon and to ask him, if he can actually create the incubator project with good conscience. Thank you all for your support Kay Kay Ramme - Sun Germany - Hamburg wrote: Hi OOo Folks, one or the other may already have heard of a pet project of mine, namely the [EMAIL PROTECTED]. One important milestone for this effort is becoming an Incubator Project. Hereby I officially like to announce, that I am heading for [EMAIL PROTECTED] becoming an Incubator Project. That means that later on I am going to ask you to show your interest and to vote for [EMAIL PROTECTED], this is required as of our policies, please find the details in http://www.openoffice.org/about_us/protocols_proposing.html If you think that this desire is no valid, or otherwise flawed, please reply (either publicly or privately, at your convenience). To get your interest and hopefully your support, I would like to give the motivation: The [EMAIL PROTECTED] project aims to develop companion products for ODF and OpenOffice.org to extend their reach into the WWW. The first planned product is an ODF Wiki, allowing to edit server side ODF documents WYSIWYG with the OpenOffice.org application suite, providing HTML and ODF access via HTTP respectively WebDAV, actually making the WWW as easy editable as classical documents, such as text documents, spreadsheets, presentations or drawings. I already created some pages in the OOo Wiki around [EMAIL PROTECTED], where you can find all the details, including a screencast and installation instructions for the prototype, please have a look at http://wiki.services.openoffice.org/wiki/ODF%40WWW Thanks for listening and support Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [Sc|Sw|Sm|etc...]DLL::Exit
Hi Mathias, Caolan, IMHO right approach for _all_ library (de-)initialization is to use the library c'tors / d'tors (AKA _init / _exit, DLLMAIN etc.). This would also avoid the problems we are every once a while facing regarding shutdown ... Kay Mathias Bauer wrote: Caolán McNamara wrote: -- Sun Microsystems GmbH Kay Ramme Sachsenfeld 4 Senior Technical Architect 20097 Hamburg Phone: (+49 40) 23646 982 Germany Fax: (+49 40) 23646 550 http://www.sun.com/staroffice mailto:[EMAIL PROTECTED] http://www.sun.com/openoffice http://udk.openoffice.org Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] [EMAIL PROTECTED] - Becoming an (Incubator) Project
Hi OOo Folks, one or the other may already have heard of a pet project of mine, namely the [EMAIL PROTECTED]. One important milestone for this effort is becoming an Incubator Project. Hereby I officially like to announce, that I am heading for [EMAIL PROTECTED] becoming an Incubator Project. That means that later on I am going to ask you to show your interest and to vote for [EMAIL PROTECTED], this is required as of our policies, please find the details in http://www.openoffice.org/about_us/protocols_proposing.html If you think that this desire is no valid, or otherwise flawed, please reply (either publicly or privately, at your convenience). To get your interest and hopefully your support, I would like to give the motivation: The [EMAIL PROTECTED] project aims to develop companion products for ODF and OpenOffice.org to extend their reach into the WWW. The first planned product is an ODF Wiki, allowing to edit server side ODF documents WYSIWYG with the OpenOffice.org application suite, providing HTML and ODF access via HTTP respectively WebDAV, actually making the WWW as easy editable as classical documents, such as text documents, spreadsheets, presentations or drawings. I already created some pages in the OOo Wiki around [EMAIL PROTECTED], where you can find all the details, including a screencast and installation instructions for the prototype, please have a look at http://wiki.services.openoffice.org/wiki/ODF%40WWW Thanks for listening and support Kay -- Sun Microsystems GmbH Kay Ramme Sachsenfeld 4 Senior Technical Architect 20097 Hamburg Phone: (+49 40) 23646 982 Germany Fax: (+49 40) 23646 550 http://www.sun.com/staroffice mailto:[EMAIL PROTECTED] http://www.sun.com/openoffice http://udk.openoffice.org Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [Sc|Sw|Sm|etc...]DLL::Exit
Hi Mathias, Mathias Bauer wrote: Kay Ramme - Sun Germany - Hamburg wrote: Hi Mathias, Caolan, IMHO right approach for _all_ library (de-)initialization is to use the library c'tors / d'tors (AKA _init / _exit, DLLMAIN etc.). This would also avoid the problems we are every once a while facing regarding shutdown ... When will they be called? I assume when the library is unloaded by the Actually the library d'tors are called before unloading. system. This would be far too late for the code we call in the Exit() methods. Why? At least not in principle. From former times we still have this some things must be available all the time approach that still hurts us here. The code called in the Exit() method relies on being able to execute any code in the corresponding DLL and this OTOH might access objects that already have been destroyed when the library gets unloaded. If a library is unloaded, you can not call it anyway. But the library d'tor only gets called immediately before unloading the library, the moment the libraries ref-count drops to zero. So, if your library is linked against another library, it is _guaranteed_, that the d'tor of your library gets called before the other one. As I wrote already, every deinit scenarios based on low level operations may work fine with libraries not being bound to a large C++ framework, but not for libraries like sw, sd and so on. I believe there are pitfalls with sw, sd etc. I agree that this would be desirable - but until then it's a long way to go and some other more important stations on this way need to be visited first. I actually did not say that this approach needs to be applied immediately, or at all. Just wanted to make you aware of it. AFAIK it is a proven approach and makes life for developers easier ... yes, I know, that is not necessarily what we want ;-) Perhaps I should join the currently ongoing talk about your visions fashion to explain my roadmap on this way. ;-) Just go ahead, what's your roadmap vision etc.? Ciao, Mathias Best regards Kay -- Sun Microsystems GmbH Kay Ramme Sachsenfeld 4 Senior Technical Architect 20097 Hamburg Phone: (+49 40) 23646 982 Germany Fax: (+49 40) 23646 550 http://www.sun.com/staroffice mailto:[EMAIL PROTECTED] http://www.sun.com/openoffice http://udk.openoffice.org Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] [Sc|Sw|Sm|etc...]DLL::Exit
Hi Mathias, Mathias Bauer wrote: Not linked against - it's different. As an example, many Writer code will fail if the desktop service or some others have been destroyed already. Where's the guarantee that the desktop will still exist when the Writer dll gets unloaded? When will it be unloaded at all? I could dive into that, but it is probably not worth it right now ... ;-) Perhaps I should join the currently ongoing talk about your visions fashion to explain my roadmap on this way. ;-) Just go ahead, what's your roadmap vision etc.? This will take some time ... Come on, just give some hints :-) Sometime in future at GullFOSS! I am looking forward to reading your posting :-) Ciao, Mathias Kay -- Sun Microsystems GmbH Kay Ramme Sachsenfeld 4 Senior Technical Architect 20097 Hamburg Phone: (+49 40) 23646 982 Germany Fax: (+49 40) 23646 550 http://www.sun.com/staroffice mailto:[EMAIL PROTECTED] http://www.sun.com/openoffice http://udk.openoffice.org Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OSL_ASSERTs in rtl_cache_create()
David, Matthias likely is able to help you (on To:). Regards Kay David Tardon wrote: Hi, can someone explain to me (and anyone else interested) reason for OSL_ASSERT's in sal/rtl/source/alloc_cache.c at lines 925 and 926 (DEV300_m31)? Their presence disables OOo to compile with --enable-dbgutil on x86_64. The problem is that on x86_64 during initialization of gp_cache_arena in rtl_cache_once_init(), rtl_arena_activate() calls rtl_cache_create(), which calls rtl_cache_activate(). Now, at line 924, cache-m_slab_size is calculated to be 8192 on x86_64, so it takes the 'if' branch (on i386 it takes the 'else' branch, where there is no OSL_ASSERT present; so no problem) and ends here, because gp_cache_slab_cache and gp_cache_bufctl_cache haven't been initialized yet. As gp_cache_arena is used during _their_ initialization, it's not possible to simply move initialization blocks in rtl_cache_once_init(). David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sun Microsystems GmbH Kay Ramme Sachsenfeld 4 Senior Technical Architect 20097 Hamburg Phone: (+49 40) 23646 982 Germany Fax: (+49 40) 23646 550 http://www.sun.com/staroffice mailto:[EMAIL PROTECTED] http://www.sun.com/openoffice http://udk.openoffice.org Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Pinneberg status update
Charles, Charles-H. Schulz wrote: Hello Kay, http://wiki.services.openoffice.org/wiki/User_Experience/Grand_Concept I didn't but I'm reading it; I don't have his emaila address though. It seems to be discoleo-at-gmx.net , which is funny :-) . I did put him on CC: I just contacted Louis about creating an incubator project for the [EMAIL PROTECTED] stuff, if others agree on this being a good thing, we may want to use these mailing lists etc. for communication ... +1 from my side. Good to hear :-) I will put a mail together target to [EMAIL PROTECTED], asking for interest etc. This is required as for proposing new incubator projects, see http://www.openoffice.org/about_us/protocols_proposing.html Next IRC meeting: 19th of october, 5pm CET, Freenode, [EMAIL PROTECTED] . In my calendar this is a Sunday (though not necessarily sunny ;-), and I just noticed that I am on vacation this date anyway ;-) Hmm. How about the 22nd? I am back from vacation the 28th of October, which is a Tuesday. I am leaving again the next week, heading for China ;-) Best Charles. Best regards Kay -- Sun Microsystems GmbH Kay Ramme Sachsenfeld 4 Senior Technical Architect 20097 Hamburg Phone: (+49 40) 23646 982 Germany Fax: (+49 40) 23646 550 http://www.sun.com/staroffice mailto:[EMAIL PROTECTED] http://www.sun.com/openoffice http://udk.openoffice.org Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Java 1.5 now minimal requirement ? (Re: [dev] RFC: java 1.5
Hi Mathias, Mathias Bauer wrote: Kay Ramme - Sun Germany - Hamburg wrote: IMHO the only reason that 1.3.1 still is the baseline is that nobody took care of raising it. And by now nobody has raised any objections Well, both is not true. Please go back to the beginning of this thread. ??? Who took care of raising it? And who did object? This issue listed in the first mail is one reason I am taking care of it ... Or do I misunderstand what you said? Ciao, Mathias Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [tools-jdk] The OOo Java Baseline ...
By now I did not receive a single objection regarding the switch to Java 1.5 ... I understand that as agreement. So, I am going to update the Java policy page soon, to reflect that by now Java 1.5, and not Java 1.3.1 anymore, is the official OOo baseline. Thanks for your support Kay Kay Ramme wrote: Hi OOo porters, I am mailing you because I just recently started a discussion on [EMAIL PROTECTED] regarding the OOo Java baseline. As Sun has open sourced Java about 1 1/2 years ago to the OpenJDK project, and as this OpenJDK recently become fully functional, I proposed to switch to the OpenJDK as OOos Java baseline, as soon as it becomes available on all of OOos platforms. Please see http://tools.openoffice.org/servlets/ReadMsg?list=jdkmsgNo=230 While discussing that, I talked to Svante Schubert, who observed various issues in OOos current Java libraries, some of them are checked in in binary form, some being functional redundant etc. (please see Svantes mail http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=22824). Plan is, to clean that up before releasing OOo 3.0. In detail Svante plans to replace the current Xalan XSLT processor with Saxon. Problem is, that this requires at least Java 1.5, while the current baseline still is the 1.3 (see http://tools.openoffice.org/policies/java_usage.html). I created an overview of OOo, its platforms and the availability of OpenJDK respectively something similar. Please see http://wiki.services.openoffice.org/wiki/OpenJDK Unfortunately I have not any information on your platforms yet, so I don't know, if raising the baseline to 1.5 would be compatible with your platforms. Please comment on a switch to OpenJDK in general, and if it can be suitable for you. Please also comment on raising the baseline to Java 1.5 for OOo 3.0, ideally you would change the Wiki page according to the Java used/available ... :-) Thanks in advance Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Java 1.5 now minimal requirement ? (Re: [dev] RFC: java 1.5
Stephan, Stephan Bergmann wrote: Kay Ramme - Sun Germany - Hamburg wrote: Hi Rony, I did start the discussions regarding Java version, OpenJDK, baseline etc. on [EMAIL PROTECTED] Sorry for not announcing it here. Reason for [EMAIL PROTECTED] is, that all stakeholders from the last agreement originally were on that alias. Still, I would consider it an error if current OOo versions built for widespread distribution (e.g., Sun Hamburg built DEV300 m23) are built in a way that they do not work with at least Java 1.3.1 at runtime. I am currently checking if raising the baseline to 1.5 is fine, this is a prerequisite for what Svante is currently doing. IMHO the only reason that 1.3.1 still is the baseline is that nobody took care of raising it. And by now nobody has raised any objections ... Please let's continue discussions on [EMAIL PROTECTED] -Stephan Kay -- Sun Microsystems GmbH Kay Ramme Sachsenfeld 4 Senior Technical Architect 20097 Hamburg Phone: (+49 40) 23646 982 Germany Fax: (+49 40) 23646 550 http://www.sun.com/staroffice mailto:[EMAIL PROTECTED] http://www.sun.com/openoffice http://udk.openoffice.org Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Java 1.5 now minimal requirement ? (Re: [dev] RFC: java 1.5
Hi Rony, I did start the discussions regarding Java version, OpenJDK, baseline etc. on [EMAIL PROTECTED] Sorry for not announcing it here. Reason for [EMAIL PROTECTED] is, that all stakeholders from the last agreement originally were on that alias. Regards Kay Rony G. Flatscher wrote: Hi there, -- Sun Microsystems GmbH Kay Ramme Sachsenfeld 4 Senior Technical Architect 20097 Hamburg Phone: (+49 40) 23646 982 Germany Fax: (+49 40) 23646 550 http://www.sun.com/staroffice mailto:[EMAIL PROTECTED] http://www.sun.com/openoffice http://udk.openoffice.org Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Java 1.5 now minimal requirement ? (Re: [dev] RFC: java 1.5
Rony, Rony G. Flatscher wrote: Hi Kay, I did start the discussions regarding Java version, OpenJDK, baseline etc. on [EMAIL PROTECTED] Sorry for not announcing it here. Reason for [EMAIL PROTECTED] is, that all stakeholders from the last agreement originally were on that alias. Thank you very much for this clarification! Is [EMAIL PROTECTED] an OOo mailing list that one should subscribe to to learn as early as possible about Java related changes (configuration, class loader schemes,etc.)? exactly, full name is: [EMAIL PROTECTED] ---rony Hope that helps Kay -- Sun Microsystems GmbH Kay Ramme Sachsenfeld 4 Senior Technical Architect 20097 Hamburg Phone: (+49 40) 23646 982 Germany Fax: (+49 40) 23646 550 http://www.sun.com/staroffice mailto:[EMAIL PROTECTED] http://www.sun.com/openoffice http://udk.openoffice.org Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht München: HRB 161028 Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Bömer Vorsitzender des Aufsichtsrates: Martin Häring - 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]
[dev] Linux BKL vs. VCL Solar Mutex
Hi, just stumbled over some recent changes regarding the Linux Big Kernel Lock, see http://thread.gmane.org/gmane.linux.kernel/680445 Which reminds me of the VCL Solar Mutex (see http://wiki.services.openoffice.org/wiki/Terms/Solar_Mutex). I need to come back to this one day ... ;-) Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCL UI Rework
Hi Eric, eric.bachard wrote: FYI, after what I have seen during GoOOCon (Prague), I decided to test layoutdialogs cws on Mac OS X and so far it looks promising. (only tested zoom and another dialog box though ) Good to hear, so it seems I have to take a look myself as well :-) The other alternative I'm aware does only concern Mac OS X, using libRenaissance ( automagic layouting on the fly, using .xml files created from .src with Kohey python script). I'm in touch with Nicola Pero, from GNUstep project for that. I found it, going to take a look at it later, thanks for the hint. See also http://wiki.services.openoffice.org/wiki/Chrome_Again http://wiki.services.openoffice.org/wiki/UI_Layout Reading all that above, I got some questions : What are the plans ? Who can contribute ? Reading Chrome Again wiki page, the work is really advanced, but is it just a draft ? I have to admit, I don't know ;-) What I hear is, that many users and developers seem to be unsatisfied with OOo's GUI respectively with it's progress, some even seem to be disappointed with OOo 3 because of that. What I see is, that others (XAML, XUL, ...) are in principal heading for a scalable approach (not pixel but vector based, using e.g. cm or inch as the measure), noticing all those high resolution / high pixel density displays, this obviously makes sense. Not to forget, that there is a general trend, and I have to admit, I personally like that, towards transparency and animations. I think what I basically want to say is, that there is some pressure to principally re-work OOo's GUI to stay attractive and to be future proof. What I am currently doing is, to look around, to listen and to ask questions what people think what needs to be done, and what they are currently working on. Last but not least, I know there is something in progress about more MVC in OpenOffice.org, mainly in vcl, but I can't remember where it is for now ( I'll try to retrieve it asap :-) ) I fear, that this more far away than we would like it to be ... Regards, Eric Bachard Always a pleasure to talk to you Kay P.S. : the Mac OS X screenshots are outdated :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCL UI Rework
Hi Jörg, Jörg Wartenberg wrote: For me an other aspect of the user interface is much much more important, consistency of the UI over the whole office and with the operating system. Some of which is simpler while other parts are more difficult, but lets see ... If you look today on the user interface of the different OOo applications, they look very different. Especially Impress looks totally different with it's 3 pane UI layout. Furthermore the functionality of the slide sorter pane is more or less identical with the Navigator. Why are there two tools in one UI for the same task? Also the Task Pane could be merged with the Stylist. Ask the developers respectively the UX team ... seems it is more fun to develop similar functionality multiple times than to focus on one implementation ... An other example are the many different ways, OOo uses too highlight a selected object. Sometime selected text is inverted, sometimes the systems highlight color is used and Draw has a totally different way of painting some green squares around the selected objects. I think I know what you mean and how it feels like. Or what about the light bulb window, that sometimes pops up over the lower right corner of the main window. Do you know any system that uses such help windows? I have to admit, that I basically never open any help systems, the first thing I do if I can't find a functionality etc. is to google it ... ;-) But again you have point, nobody else seems to be using a light bulb, does anybody now where this origins from? I know, that removing such quirks makes not so much fun, as implementing some cool animations. But in my opinion, this is the point that makes a good user interface. And please, always remind that OOo is a productivity tool and not a video game. Yes, OOo shouldn't have any competing but similar GUI parts / implementations. Addressing this is more or less a matter of how easy it is to change the GUI in general. Both needs to be fixed/improved and I am going to add that to the list. On the other hand, I believe that many people judge an application by looking at the GUI, how fast it seems to be, how pretty it is and how they are able to adapt it to their needs. Best Regards Jörg Thanks for your comments and pointing out the consistency issue. The platform integration thing is more difficult though should be solvable. Regards Kay - 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 porting to DirectFB
Hi Monali, Mona wrote: Hi all, I am working on porting openoffice ( version 2.3.1) applications ( writer, calc, impress) to work with DirectFb on Unix platform . I am new to large code base of OOo . It would really be very helpful if you validate my understanding on the following . Let's see ... 1) OOo has GTK plugin. However since the GTK plugin is now based on X11Classes which are based on Sal Classes , I would need to replace all the low level X calls in these X11 classes into equivalent GDK calls . I am looking at approach where i have the GtkPlugin classes still deriving from X11 classes . However if OOo code is configured for DirectFB backend ( maybe a --enable-directfb) i would change the X11 classes to talk to GDK rather than X. Am i right here ? Sounds correct, Philipp likely has more to say. I may be more appropriate to just create a new VCL backend. 2)Since there is VCL layer for all graphics, i assume that all above applications will be ported to directFB backend if i port the VCL GTK Plugin to DirectFb backend . Is this so simple ? Should be. 2.b) Has someone tried something similar with OOo? You mean porting it to directFB? I don't think so, but it has a least been ported to - X11 - Win32 - Max OS X / Cocoa - Java AWT (NeoOfficeJ) 2.c) How much effort would be involved in this activity ? Doing the basic porting of VCL should be doable in months ... 3) I also assume that i would need no changes in the UNO layer and awt toolkit . I am interested in using writer , calc and impress packages to act as viewers i.e support for read-only . Would i need to port layers other than VCL that also talk to X e.g dtrans. Depends, dtrans deals with clipboard and DD, don't know if these are in principle available while using directFB. 4) I have NOT understood how the sw, sc and sd modules interact with the framework layer (svx,sfx). Where do i find details of these framework modules.I have read this - http://www.openoffice.org/white_papers/tech_overview/tech_overview.html#3* You may want to start further reading in the Wiki: http://wiki.services.openoffice.org/wiki/Framework or in the dev. guide: http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Office_Development 5) What are the graphics calls at the application layer ? Below the application layer is Framework,Infrastructure and SAL layer. Graphics calls are done directly calling VCL or in newer code calling the XCanvas (which supports e.g. DirectX etc., but also as a VCL back-end again). Which layer maps graphic calls from OOo appliucations (like sw) calls to the VCL layer ? AFAIK, this is either done directly or through framework or SVX. 6) Is there any way to incrementally test this approach ? Starting to port VCL should be sufficient, there are also some test applications in vcl/workbench, which should give you are first understanding of what needs to be done. 7) Is there any simple application that follow the same approach as writer(sw) and which can be used to test the flow of from application layer through framework layer to VCL layer. I have seen few demo applications in vcl/workben. Any more suggestions ? The framework people may give some more hints where they have hidden their test applications ... :-) Regards, Monali. What's the motivation behind you project? Obviously you would like to run OOo on X11 free systems, which are AFAIK mostly small appliances like set-top-boxes etc. Are we going to see a set-top-box with OOo installed? Or are you targeting small devices? Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] RFC: java 1.5
Stephan Bergmann wrote: Malte Timmermann wrote: My point of view: Most people agree that OOo mustn't loose (meta) data when Java is not available, but plug ins for working with meta data can rely on Java. Changing OOo's Java base line from 1.4 to 1.5 is fine for most people then. AFAIK the current Java baseline is 1.3.1. That is correct, the (still) valid consensus regarding Java can be found here: http://tools.openoffice.org/policies/java_usage.html respectively the background: http://tools.openoffice.org/servlets/ReadMsg?list=jdkmsgNo=90 -Stephan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [project leads] Promoting the User Experience project
Lutz Hoeger wrote: Please give me your thoughts on this (which might be as simple as '+1' ... ;-) ) +1 Thank You. Lutz Hoeger project lead [EMAIL PROTECTED] Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] We need your help
Hi Tobias, Tobias Mann wrote: The entire Nokia N800 and N810 need a version of Open Office for The Operating System Tablet OS 2007 and 2008. We have Been working hard to port a version for it but because of the Nokia's In ability to run OOo. based applications we haven't gotten any ware. The Nokia can Run applications written in python up to version 2.5 . It is preferred that it be written in a version of python lower than 2.5. The Nokia Has a 320 MHz CPU and 128 MB of RAM. There is a total of 256 MB of on board memory. This means that The version of OpenOffice has to be smaller than about 100 MB but preferably 30mb or smaller. We would really appreciate if you would help us with this problem. splitting OOo into smaller pieces is somewhere on our agenda. If I understand correctly, you already started with the port. Does that mean that you already can build OOo (partly) for the N800 ? May be it is already showing up on the screen? Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VOS removal
Hi Jan, Jan Holesovsky wrote: Hi, VOS is a deprecated module (library), and all its functionality is handled in SAL these days. Indeed, VOS is now in fact just a wrapper over SAL's functions/classes. Mostly yes. I wonder: Is anybody against removing it for good? I'm now in VCL, going quite quickly, but in case somebody is against it, please tell me... I would be surprised if anybody is against removing it. Please go ahead replacing VOS with SAL, though there are places where there is no SAL counterpart yet (e.g. IMutex as mentioned by Philipp, or the VOS timer). Regards, Jan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Proposed Thread / Process Lifecycle
Took a while, but just added the SAL based implementation to http://wiki.services.openoffice.org/wiki/User:Kr/A_Thread%27s_Life There seem to be some issues with SAL threads though, slightly different semantics of UNIX vs. Windows implementations, some missing functionality, some inherent races, but let me nail that down first, before complaining some false positives :-) Kay Kay Ramme - Sun Germany - Hamburg wrote: Joerg, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Proposed Thread / Process Lifecycle
Joerg, Kay Ramme - Sun Germany - Hamburg wrote: Certainly, going to rewrite the example suitable for use by shared libraries / components soon. Done with POSIX and pthreads, please have a look at: http://wiki.services.openoffice.org/wiki/User:Kr/A_Thread%27s_Life#Executable_and_Library_using_pthreads Implementation for SAL threads is coming soon (there seem to be some oddities wrt SAL threads ;-) ... Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Proposed Thread / Process Lifecycle
Jöerg, Jörg Budischewski wrote: Hi, but your approach then won't solve the crash in regcomp with the pyuno bridge and its daemon thread. The regcomp atexit join_daemons atexit handler would be called too late as the static objects within the pyuno bridge (and potentially within the whole office) would get destructed before. this was only an example for illustration purposes of the concept ... sorry that I did not make that clear ;-) The only safe way is too terminate these daemon threads before main() exits ... Certainly, going to rewrite the example suitable for use by shared libraries / components soon. Bye, Joerg Kay Kay Ramme - Sun Germany - Hamburg wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Proposed Thread / Process Lifecycle
Hi Philipp, Philipp Lohmann wrote: Hi, the example given uses pthreads. While this may show the idea, could you please instead replace it with an axample using osl threads from sal ? yep certainly, I am one the way already :-) Just my 2 cents, pl Kay Kay Ramme - Sun Germany - Hamburg wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Proposed Thread / Process Lifecycle
Hi Joerg, Joerg Budischewski wrote: Hi Kay, hmm, your proposal looks more like a concept rather than an API proposal . exactly! Everybody may implement it as appropriate, the point being that all daemon threads eventually get joined, e.g when de-initializing a shared library. Will there be an API somewhere in sal for this ? If yes, I would rather see the API docs before actually putting comments. See above. I may make some helper functions available in SAL later on, certainly along the lines of the example code. Only critical point is the proper synchronization of the activies (AKA non-daemon threads), as only the last one is allowed to call exit. I can't see how your concept should work work for daemon threads, when shared libraries are dynamically loaded. From man atexit --snip-- The atexit() function registers the given function to be called at normal program termination, either via exit(3) or via return from the program's main(). Functions so registered are called in the reverse order of their registration; no arguments are passed. --snap-- Dynamically using a shared library leads to registered atexit handlers being called when dlcloseing. See man atexit: Linux Notes Since glibc 2.2.3, atexit() (and on_exit(3)) can be used within a shared library to establish functions that are called when the shared library is unloaded. Though I don't know about other platforms. But atexit used by dynamically opened libraries may be a problem anyway. .. AFAIK, the static destructors of objects in shared libraries are called by atexit functions, arent they ? So your daemon_join_ would be called too late. They are called at atexit time only in case of process termination, otherwise they are called indirectly by dlclose, so this is not a problem. I'd rather prefer an explicit daemon_join in main() to avoid those kind of problems ... That would be wrong for daemons, as daemons are implementation details, being implemented as needed. Something similar is needed for activities (please see my example code), to properly synchronize calling exit. Bye, Joerg Thanks for your help :-) Kay Kay Ramme - Sun Germany - Hamburg wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Proposed Thread / Process Lifecycle
Tor, Tor Lillqvist wrote: . AFAIK, the static destructors of objects in shared libraries are called by atexit functions, arent they ? The semantics of functions registered with atexit() when dynamically loaded shared libraries are involved is completely system-dependent and a big mess. atexit() is close to unusable because what it actually does, exactly, is so underspecified. Im my not so humble opinion atexit() should be banned. I seriously doubt any C++ implementation directly uses the C atexit() function to handle destruction of static objects. you are reading my thoughts, especially wrt atexit vs. C++ (see http://wiki.services.openoffice.org/wiki/Uno/Cpp/Tutorials/Global_References for some analysis :-) --tml Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Proposed Thread / Process Lifecycle
Hi again, if no one objects, this is going to become the standards policy regarding thread life cycles soon. First thing I am going to change accordingly is the pyuno bridge ... Kay Kay Ramme - Sun Germany - Hamburg wrote: Hi OOo developers, once a while we face the situation, that it is unclear how a long a thread should live, if it should be cancellable, and when the containing process is going to terminate (e.g. http://udk.openoffice.org/issues/show_bug.cgi?id=80300). Therefor I wrote a short proposal about controlling the life time, supplemented by some example code to illustrate the behavior. If you are interested, please have a look at http://wiki.services.openoffice.org/wiki/User:Kr/A_Thread%27s_Life and comment on the discussion page. Ideally the proposal becomes a specification, being mandatory for thread implementors. Thanks for your help and feedback Kay - 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]
[dev] Proposed Thread / Process Lifecycle
Hi OOo developers, once a while we face the situation, that it is unclear how a long a thread should live, if it should be cancellable, and when the containing process is going to terminate (e.g. http://udk.openoffice.org/issues/show_bug.cgi?id=80300). Therefor I wrote a short proposal about controlling the life time, supplemented by some example code to illustrate the behavior. If you are interested, please have a look at http://wiki.services.openoffice.org/wiki/User:Kr/A_Thread%27s_Life and comment on the discussion page. Ideally the proposal becomes a specification, being mandatory for thread implementors. Thanks for your help and feedback Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Ollie, sorry for not replying earlier. Oliver Braun wrote: Kay Ramme - Sun Germany - Hamburg wrote: Some of the reasons for the namespace problems we are facing are IMHO simply non optimal placings, e.g. com::sun::uno::Reference would have belonged into cppu (cppu::Reference or may be simply uno::Reference. As probably most people agree with, the whole com::sun::star namespace became obsolete when open sourcing StarOffice and should have been renamed to OOo (or similar), and I am sure there are more aspects one currently would like to see being reflected in the namespaces, but ... we want to stay API and ABI compatible, more or less rendering these thoughts useless ;-) What about new interfaces / services ? Would it be feasible to create uno:: aliases for com::sun::star::uno:: and com::sun::star::lang and start using org::openoffice namespace for new interface/service definitions ? In general I think it would be feasible, but please see below ... Or even better, move the basic types to ::uno and make aliases for those in the old namespace(s) ?! To preserve API (build) compatibility, right? Other aliases (e.g. for beans etc.) might need to get added over time, but at least we could start the transition. I take the opportunity to comment on compatibility ;-) though we are going to have a BOF at the OOo Conf 2007 regarding this topic, lead by Juergen. Wikipedia differentiates between forward and backward compatibility (http://en.wikipedia.org/wiki/Computer_compatibility), the compatibility we are here talking about is backward compatibility. There are two types of compatibility, - ABI (Application Binary Interface) compatibility - meaning that a program compiled for one binary environment is able to run on another binary environment, as long as these environments are binary (or ABI) compatible. - API (Application Programming Interface) compatibility - meaning that the source code of a program compilable for one API environment may be compiled for another API environment (without change) as long as these environments are API compatible. ABI compatibility is in general harder to achieve (you must know the very detail regarding how parameters are passed, how symbols are mangled etc. etc.) and offers less opportunity for improvement (e.g. you can not change a function from being outline to inline). ABI compatibility is what proprietary software vendors classical provide / require through their lines of operating systems, applications etc. API compatibility is superior wrt optimization, simplification, flexibility etc., but requires the source code to be recompiled. API compatibility is what most / many open source products provide only, leading to the situation that it is some times hard for commercial (without the source) vendors to provide binary (ABI compatibility requiring) products e.g. for different Linux distributions. This is what the LSB (Linux Standards Base) deals with. Compatibility in general is about the cost of adaption. Staying compatible reduces the cost of ISVs etc. to adapt their products to later environments, while it increases the costs of the environment provider, as he/she explicitly needs to take steps to preserve backward compatibility. With OOo we currently provide ABI and API compatibility. The compatible interfaces OOo offers are AFAIK: - Various Uno language bindings - Binary Uno - C++ Uno - Java Uno - CLI Uno - Python Uno - Remote Uno - ... - OOo BASIC - OOo API - Configuration Items - Some deployment parameters (e.g. UserInstallation) (http://wiki.services.openoffice.org/wiki/Uno/Binary/Spec/Bootstrapping) - Other: Document compatibility (e.g. ODF, .DOC), ... As we stay compatible on all these interfaces, we carry the costs of doing so, allowing ISVs and others to reduce their costs of adaption to a minimum. At least until now we thought this to be necessary, to get new ISVs interested and to keep already supporting ISVs Unfortunately it seems, and this is actually the reason for my long comment, that staying backwards compatible hinders us to clean up stuff, which really deserves it ... From a theoretical standpoint, compatibility could be ensured by leaving old things alone (may be after a reasonable life time) and only introducing new stuff, though in practice this seems to be unreasonable. Taking a look at Mozilla, it seems that they become incompatible once a while, at least with every major version (please correct if am wrong), and that this seems to acceptable for ISVs etc. The Linux kernel seems to become incompatible as so often, only keeping the system call interface stable, once a while leading to problems with binary only drivers e.g. from NVidia or ATI. So, the questions is, would it be acceptable for our ISVs etc. that we become incompatible e.g. with every major? That would give us the opportunity to clean up things (fix the namespaces), may be abandon things
Re: [dev] To OOo Builders ...
Just created another patch to make deliver.pl less verbose ... http://udk.openoffice.org/issues/show_bug.cgi?id=79798 Kay Ramme - Sun Germany - Hamburg wrote: Hi builders, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] To OOo Builders ...
Looked more into this ... and wrote some little patches to avoid dmake: Executing shell macro ..., please see http://udk.openoffice.org/issues/show_bug.cgi?id=79760 Some dmake questions in general: - Computed Names: Is there something similar to computed names as in GNU make? The only way I got macros indirectly expanded (e.g. $($(MYMACRO)) in a recipe was by calling some kind of function (e.g. $(strip $($(MYMACRO))) ), but likely I just missed that in the docs. - call Function: Is there something similar to the call function of GNU make? That would come quite handy when trying to simplify the makefiles somewhat ... - eval Function: Same question for the GNU make eval function, which I like to use once a while ... Some questions regarding our makefiles in particular: - It is unclear to me, what the error handling strategy is. On the one hand dmake (as most other makes) aborts execution if any command returns a non zero value and has not been explicitly marked to be ignored, on the other hand I see commands (e.g. @cat $(MISC)$/$(TARGET).$(@:b)_1.cmd ) whichs purpose seems solely to be to help diagnose errors. My expectation would be, that all output while building would just be for showing the progress, and to stop in case of an error, or at least to collect all errors and to report them at the end ... - There are various files in solenv/inc, some of them having more or less speaking names, while others are just differing by a prepanded underscore (e.g. _tg_app.mk vs. tg_app.mk ). What is the meaning of the underscore prefix? Is there an overview somewhere where I can find some explanations regarding the makefile system? Thanks for any help Kay Kay Ramme - Sun Germany - Hamburg wrote: Hi builders, while building OOo on multiple machines because of some map file issues ;-), I was wondering, if I am the only one being annoyed by the excessive verbosity of the build system ... actually slowing down build performance unnecessarily. If others have the same feeling, I am going to submit some patches to get the verbosity under control again ... Thanks for your opinions Kay - 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] Threading problems in Open Office
Hi Robert, Thullner, Robert wrote: Hello I have the following situation: I use OpenOffice to convert a MS Word File to PDF with Java. When my Java Program start the OO code from the main thread everything works well. If I start OO code from a different thread, Open Office cannot be started. Especially at this line of code my program stops working: Object context = xUrlResolver.resolve( sConnect ); in the Bootstrap Loader class of the package juh.jar So again, if I start OO from the main java thread, everything works fine If I start it from a different thread, than the main one, the program blocks at the above mentionen line. Is there any solution or workaround for this problem? Not sure if I understand the problem correctly, could you post stacktraces of all threads (e.g. by using jdb)? Thanks for any reply Robert Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] COM (Un)Initialize in SAL Threads
Hi Pierre-Andre, PA Galmes wrote: Hi Kay, On 7/11/07, Kay Ramme - Sun Germany - Hamburg [EMAIL PROTECTED] wrote: To make a long story short, I plan to remove the COM initialization from SAL threads, which unfortunately is an incompatible change. Certainly I am going to take care of our current implementations, to adapt them appropriately. Thanks for that interresting information. I still have a few questions about this. Sure :-) - What are the impacts of your changes? The impact is, and this actually is rendering the change incompatible, that components relying on COM initialization (either MTA or STA) need to be adapted to the change. But the point is, that you currently _can_ _not_ _generally_ _know_ if and how COM has been initialized in a thread calling your component, as you me be called by the main thread, a SAL thread or a native thread. In other words, initialization of COM is useless if not dangerous. - What are the improvements your changes will bring? Initialization of COM is useless, you can not rely on it anyway and it may hinder you to do OLE. Will it remove bugs? There may be bugs because of the different Apartment types used, e.g. wrong assumptions of the Apartment and so on. These kind of bugs are hart to spot and may be subtle. Will it ease further development? It is going to ease development on Windows, as you may use SAL threads to do OLE as well, currently most (all) places using OLE are working by luck only, or are using the Win32 API to create dedicated threads. Is it mandatory for OOo to become thread-safe? Not really, it just eases the usage of OLE, avoids bugs etc., please see above. - Will it impact third-parties developpers or only OOo internal devs? It may impact third-parties, as it is an incompatible change. But code impacted is IMHO buggy anyway, which is the reason that I think the change is justifiable. - Are there noticeable changes in the way we need to develop or use OOo OLE objects? No, not all, even contrary, there may be bugs wrt OOo OLE objects because of wrong initialized COM apartments, which are going to be fixed / avoided. Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] rtl::Reference vs. [com::sun::star::]uno::References
Guys, my originally mail was not meant to press anybody into any corset, but just to solve the noticed problems regarding the usage of using using rtl; :-) Some of the reasons for the namespace problems we are facing are IMHO simply non optimal placings, e.g. com::sun::uno::Reference would have belonged into cppu (cppu::Reference or may be simply uno::Reference. As probably most people agree with, the whole com::sun::star namespace became obsolete when open sourcing StarOffice and should have been renamed to OOo (or similar), and I am sure there are more aspects one currently would like to see being reflected in the namespaces, but ... we want to stay API and ABI compatible, more or less rendering these thoughts useless ;-) Personally I tend to use aliases as Andreas does, e.g. css for com::sun::star respectively cssu for com::sun::star::uno. Regards Kay Andreas Schlüns wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] COM (Un)Initialize in SAL Threads
Hi developers, as one or the other knows, OOo does not only run on Unix and relatives, but ... also on Windows :-), and it actually tries hard to integrate well. Some things on Windows are provided as COM/OLE services, which may not play nice with our current initialization of COM in SAL threads. Initializing COM or OLE makes COM / OLE implementations usable in the current thread, meaning that the initialization is bound to the calling thread. COM basically supports two threading models, called STA for Single Threaded Apartment respectively MTA for Muti Threaded Apartment. (The extended Uno threading model introduces something similar to Uno, (certainly :-) being more flexible, see http://wiki.services.openoffice.org/wiki/Uno/Effort/Binary/Extend_Threading-Model for details.) OLE sits on top of COM, but only supports STAs, initializing OLE implicitly initializes COM with the STA model. COM Initialization functions: - CoInitialize - CoInitializeEx - CoUninitializ OLE Initialization functions: - OleInitialize - OleUninitialize COM objects of different STAs may not be mixed with each other and may not be called by other threads (than the ones which did the retrieval respectively the initialization). Same holds true for OLE because OLE relying on COM (see above). STA and MTA objects may not be mixed as well. Taking a look at OOo wrt COM and OLE shows, that the VCL initializing thread (the main thread) does initialize COM as well (see vcl/win/source/app/salinst.cxx:485), in particular as STA. Looking into SAL we see, that every SAL thread initializes COM as MTA, before actually calling the worker function (see sal/osl/w32/thread.c:77). While it is more or less OK to let the main thread do some COM initialization (at least currently, more to come later :-), it is somewhat unpleasant for the SAL threads to also do so, - as a SAL thread not necessarily needs to do any COM stuff, - as it conflicts with any OLE usage, and - as it makes it easy to hurt object separation as outlined above, may be breaking apartment integrity. To make a long story short, I plan to remove the COM initialization from SAL threads, which unfortunately is an incompatible change. Certainly I am going to take care of our current implementations, to adapt them appropriately. This change is already aligned with Hennes and Ollie. Comments? Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] COM (Un)Initialize in SAL Threads
I forgot, there is already an issue for this: http://udk.openoffice.org/issues/show_bug.cgi?id=79326 Kay Kay Ramme - Sun Germany - Hamburg wrote: Hi developers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] rtl::Reference vs. [com::sun::star::]uno::References
Hi developers, Ause made me recently aware of the fact, that ambiguities regarding the RTL Reference type (sal/inc/rtl/ref.hxx - rtl::Reference) and the Uno Reference type (cppu/inc/com/sun/star/uno/Reference.h - com::sun::star::uno::Reference) are showing up more frequently, because of some (don't know yet which) changed headers now including the RTL Reference, precompiled headers (I actually have to admit, that I don't know the exact relationship yet) and multiple using declarations. E.g. #include myheader.hxx using rtl; using com::sun::star::uno; ... ReferenceXBla xBla; ... did compile as long as myheader.hxx did not include (neither directly nor indirectly) rtl/ref.hxx . Somehow adding rtl/ref.hxx now leads to ambiguities because of the unclear usage of Reference. I briefly talked to Malte, Matthias Huetsch and Michael Brauer about this, and we found various possible solutions leading to disambiguate resolution, from which we favored the following. We assume, that people using using rtl; mostly intend to use the RTL string and string buffer classes. Therefor we suggest to just be a little bit more precise regarding the things being usable from the RTL namespace, by making the using rtl; somewhat more precise: using rtl::OUString; using rtl::OUStringBuffer; respectively everything else :-) -Matthias, Malte, Michael: Hopefully I have summarized our suggestion correctly. Comments? Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] rtl::Reference vs. [com::sun::star::]uno::References
Hi developers, Ause made me recently aware of the fact, that ambiguities regarding the RTL Reference type (sal/inc/rtl/ref.hxx - rtl::Reference) and the Uno Reference type (cppu/inc/com/sun/star/uno/Reference.h - com::sun::star::uno::Reference) are showing up more frequently, because of some (don't know yet which) changed headers now including the RTL Reference, precompiled headers (I actually have to admit, that I don't know the exact relationship yet) and multiple using declarations. E.g. #include myheader.hxx using rtl; using com::sun::star::uno; ... ReferenceXBla xBla; ... did compile as long as myheader.hxx did not include (neither directly nor indirectly) rtl/ref.hxx . Somehow adding rtl/ref.hxx now leads to ambiguities because of the unclear usage of Reference. I briefly talked to Malte, Matthias Huetsch and Michael Brauer about this, and we found various possible solutions leading to disambiguate resolution, from which we favored the following. We assume, that people using using rtl; mostly intend to use the RTL string and string buffer classes. Therefor we suggest to just be a little bit more precise regarding the things being usable from the RTL namespace, by making the using rtl; somewhat more precise: using rtl::OUString; using rtl::OUStringBuffer; respectively everything else :-) -Matthias, Malte, Michael: Hopefully I have summarized our suggestion correctly. Comments? Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] To OOo Builders ...
Hi Stephan, Stephan Bergmann wrote: Undecided. For example, echoing of compiler command lines could be helpful when a CWS owner tries to track down why a tinderbox built broke, to see whether it is an issue of the tinderbox build environment or an issue of the CWS... It actually should be easy, to echo the command line, which lead to an error in case of an error ... -Stephan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] To OOo Builders ...
Hi builders, while building OOo on multiple machines because of some map file issues ;-), I was wondering, if I am the only one being annoyed by the excessive verbosity of the build system ... actually slowing down build performance unnecessarily. If others have the same feeling, I am going to submit some patches to get the verbosity under control again ... Thanks for your opinions Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] State of Jam
Stephan, Kohei, Kohei Yoshida wrote: On Wed, 2007-06-13 at 13:15 +0200, Stephan Bergmann wrote: Hi all, Is the Jam stuff in the OOo source tree (thought as a replacement for dmake) still relevant or is it dead code (that should go)? It is dead. More importantly, what happened to our grand --enable-jam project? I Last time I talked to Kai Backman, he noted that he is not going to continue any work on jam support. So long nobody else is doing it, it is dead ... loved that concept have used jam in the past and found it to be me too flexible and very fast at resolving dependencies. Kohei Kay - 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] UI for OpenOffice.org
Dennis, OOo is organized into so called accepted projects (please see http://projects.openoffice.org/index.html). You may find the project dealing with OOos GUI here: http://ux.openoffice.org respectively the appropriate mailing lists: http://ux.openoffice.org/servlets/ProjectMailingListList The project dealing with documentation in general can be found here: http://documentation.openoffice.org/ respectively the appropriate mailing lists: http://documentation.openoffice.org/servlets/ProjectMailingListList Hope that helps Kay Dennis Desormier wrote: I write to you with interest in contributing to clarification of the text of the user interface for OpenOffice.org. Over the years, I have used this software (in Mac X11, no less) quite a bit. I continually find that the Help Guide is strong. However, I often find myself wanting to rewrite the text in dialog boxes and preference panes so that it is more grammatical, orienting, and consistent. Of course, a stronger interface attracts more users‹and it makes documentation less necessary (and also less challenging work). A little about me... I recently left a role as Director of Training and Professional Development for a major education curriculum publisher in which I oversaw the writing of clear, concise, layout-oriented text using simple language, aimed at helping people get up and running with programs (software, online, and print curriculum, all academic subjects). I also have worked in web design and music publishing, focusing mostly on user interface and experience. Please let me know where I can next turn to contribute in this area of OOo development. Best, Dennis Desormier New York City, United States 646.505.8941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Windows: Help needed
Stephan, Stephan Bergmann wrote: Again: If I have two instances A and B of an application installed, and want to have a per-installation deployment variable C for that application stored in the registry, what would the involved registry keys have to look like for instance A to have C with value D and instance B to have C with value E? Good question, somehow the registry keys for A and B have to be different. Actually I don't know, how this is conceptually solved, e.g. what is going to happen if I install OOo two times. Probably the second installation just overwrites the keys of the first, if so, I think we don't need to solve something which is not solved by Windows itself. Anyway, putting some more thoughts into this, I think the perfect solution would be, to specify the to be used URE in the registry of the active (the last) installation, comparable to all other registry entries created for a particular OOo installation. The deployment parameters than just reference the registry entries, in case someone wants to change the URE for a particular installation he / she * may either change the registry entry for the active installation, or * directly the deployment parameter of a particular installation. -Stephan Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Windows: Help needed
Hi Stephan, Stephan Bergmann wrote: Kay Ramme - Sun Germany - Hamburg wrote: [...] Anyway, even using the mentioned registry entry does not seem to achieve what you want to achieve, as this registry entry is globally unique and does not belong to the office installation. So, what you actually want, is an OOo installation specific entry, which points to the to be used URE. No, not necessarily. (If OOo-wo-URE wants to store a pointer to its underlying URE, it need not use the registry at all.) Let me rephrase my thoughts: Sure :-) There are three steps involved. First, when OOo-wo-URE is installed, it needs an installed URE, so that needs to be found somehow (and HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE pointing at the machine's default URE might come in handy here). Second, OOo-wo-URE needs to Yes, agreed, that's what I meant. have this information (i.e., the location of its underlying URE) available at runtime. And third, it should be easy for the user to change that information, to at least be able to (a) at installation time combine the OOo-wo-URE with an arbitrary URE (not necessarily the machine's default URE), and (b) later on move around the installation locations of the OOo-wo-URE or its underlying URE, or both. My understanding of windows registry entries is, that they actually serve (or at least partly do so) the same purpose as the deployment parameters. In the sense, that if a user wants to change the URE to be used by a particular office installation, he/she would change a registry entry of that installation for that reason. Anyway, we certainly can say, that registry entries are just for finding particular installations, with the consequence, that we would only _reference_ the HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE somehow. If we do that centrally, like in bootstrap.ini, we would ensure that only a single place needs to be changed to switch from one URE to another. So, I am not sure yet, how to solve the binary stuff etc., may be Hennes customer loader thing can do look up through the appropriate bootstrap variable? Unfortunately this may lead to bootstrapping problems because of cycle dependencies (the office libraries needing to find the bootstrap parameters to resolve the boostrap parameters). By the way, if we put that whole thing from its head to its feed, basically registering the office services into a particular URE installation, the above problems seem to vanish ... ;-) AFAIK, the right place for a URE_BOOTSTRAP deployment variable is an OOo installation specific registry entry, and, as you already suggested, to introduce .ini files for all executables, so the latter may be avoided by seamless integration/support of windows registry entries into the deployment parameter approach. Not sure about OOo storing its deployment data in the registry. What would the keys look like? What about having two instances of OOo installed that are sufficiently similar from a code-base point of view (i.e., would probably both use the same keys), but nevertheless shall have different deployment data? You certainly would need different registry entries for different installations, while having one global entry pointing to the default installation. -Stephan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] The interface of OOo
Hi Stephan, Stephan Bergmann wrote: Hi all, What is the interface of OOo? More specifically, when OOo is installed on a computer, what are the files from that installation that are either: 1 Intended to be executed directly by a client (human or program) to accomplish a certain task. 2 Intended to be registered (typically during installation) with the operating system or some other external framework, to be executed by the operating system or external framework upon certain events. these are good questions, and I fear the answers are unclear and probably platform dependent. If we ever have the chance, we should clean this up. Originally, the user data directory (e.g. .openoffice) and the installations top level directory hold symbolic links (at least on Unix), to the files in the program directory, which were thought to be the public interface, so this is long ago and the links seem to have gone ... ;-) I just skipped through the OOo 2.2 rpms, for whatever reasons, there seem not to be any system integrations. At least for SO there are some, integrating SO into the desktop by placing various mime types, menus and icons at appropriate places, and by placing some links in /usr/bin . If we don't have any other clue, I suggest starting to actually define, what the file system interface is, by discussing your list and creating an appropriate spec may be in the wiki. Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Windows: Help needed
Hi Stephan,
moving out URE stuff of OOo windows installations indeed seems to be
more difficult than Unix (IMHO, as always :-). This seems to be more or
less rooted in the fact, that windows does not support (symbolic) links
on the on hand, while there is a mismatch between the binary world of
libraries, executables etc. and the registry. This simply is not thought
through well ... ;-)
Anyway, even using the mentioned registry entry does not seem to achieve
what you want to achieve, as this registry entry is globally unique and
does not belong to the office installation. So, what you actually want,
is an OOo installation specific entry, which points to the to be used URE.
AFAIK, the right place for a URE_BOOTSTRAP deployment variable is an OOo
installation specific registry entry, and, as you already suggested, to
introduce .ini files for all executables, so the latter may be avoided
by seamless integration/support of windows registry entries into the
deployment parameter approach.
Hope that helps
Kay
Stephan Bergmann wrote:
Hi all,
I am currently fiddling around with an OOo installation set from which
the URE has been extracted, see
http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE
for details.
On Unix/ELF, this already works reasonably well. I need a single
symbolic link from the base directory of the OOo-wo-URE installation to
the base directory of the URE installation. All the places where things
in OOo-wo-URE need to access things in URE are routed over this link:
- Executables and shared libraries in OOo-wo-URE find shared libraries
in URE they depend on via an RPATH (recorded in those executables and
shared libraries) that includes the link to the URE.
- The deployment variables URE_BIN_DIR (used in all other places in the
code where things in URE need to be accessed) and URE_BOOTSTRAP
(pointing at a fundamentalrc in OOo-wo-URE that contains essential
deployment variables to adapt the URE to the needs of OOo) are set in
the shell scripts soffice and unopkg (which should cover, via
indirections, most if not all of the executables that constitute the
interface of OOo, see
http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=19840).
However, I have problems imagining how I can do something similar on
Windows:
- An installed URE already announces its location in the Windows
registry at HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE. But, even if
all the code that needs to know this value can read it (e.g., we
introduce additional syntax so that the URE_BIN_DIR deployment variable
can be set to something like
${registry:HKEY_CLASSES_ROOT/Software/OpenOffice.org/URE:Path}), one
ugly problem would remain: It would not be easy at all to install two
different pairs of URE and OOo-wo-URE on the same machine (which is of
utmost importance at least for developers, and somewhat easily solved in
the Unix scenario above---all you have to do is adjust the one symbolic
link per installed URE/OOo-wo-URE pair).
- Assuming that OOo-wo-URE does know where the URE is located, how can
executables and DLLs in OOo-wo-URE access the DLLs in URE they depend
on? Extend the PATH? DLL hooks Hennes is currently working on (would
that scale)?
- Are there any clever places to set the URE_BOOTSTRAP deployment
variable so that all executables in the interface of OOo are
guaranteed to have it set (for themselves and any other processes they
spawn, i.e., ideally as an environment variable)? The last resort would
be to make sure that next to each such executable named foo there is a
foo.ini that contains a definition for URE_BOOTSTRAP.
Input more than welcome,
-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] The interface of OOo
Christian, Christian Lohmaier wrote: On Wed, May 09, 2007 at 06:09:48PM +0200, Kay Ramme - Sun Germany - Hamburg wrote: [...] I just skipped through the OOo 2.2 rpms, for whatever reasons, there seem not to be any system integrations. At least for SO there are some, integrating SO into the desktop by placing various mime types, menus and icons at appropriate places, and by placing some links in /usr/bin . You should look in the desktop-integration subdir.. :-) You are right, thanks for the hint ;-) ciao Christian Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] The interface of OOo
Christian, Christian Lohmaier wrote: On Wed, May 09, 2007 at 06:09:48PM +0200, Kay Ramme - Sun Germany - Hamburg wrote: [...] I just skipped through the OOo 2.2 rpms, for whatever reasons, there seem not to be any system integrations. At least for SO there are some, integrating SO into the desktop by placing various mime types, menus and icons at appropriate places, and by placing some links in /usr/bin . You should look in the desktop-integration subdir.. :-) You are right, thanks for the hint ;-) ciao Christian Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] uno cil bindings for linux
Hi Daniel, Daniel Morgan wrote: What is the status of the uno cil bindings for mono on linux? assuming you mean CLI, I suggest to talk to Michael Meeks (on CC:), who was taking care of that and who had a running prototype. Regards Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Sharing packages across products
Hi Ollie, Oliver Braun wrote: A few words on prefixes: we currently use /opt/openoffice.org2.2 as relocatable part of the packages, while usual prefixes (at least on Solaris) are /opt or / or /usr. Understood. For admins actually making use of relocations regulary, it is quite likely that (s)he initially ends up with e.g. /usr/local/program etc. when trying to relocate to /usr/local. which obviously is unfortunate, so we are going to try to fix this :-) Is there already an issue for that? While writing the above, another thought just came to my mind: if we would adjust the structure of OOo to fit nicely into /usr or /, we could easily transform unbundled packages to bundled ones and vice versa, even at install time ! I think I understand what you are saying, we and the distros could actually use the same packages. Despite of any technical reasons, I fear that the distros are probably not really interested, as they are going to build (and patch) there own stuff anyways. [...] Regards, Oliver Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to check whether nas is working?
Christian, Christian Lohmaier wrote: repost becasue I didn't recieve any answer... cc dev@openoffice.org this time. Hi *, How would I check whether nas support is working in an installation set? There's a compiletime option to disable or enable nas, but apart from its name (network audio support) I don't have a clue what it is used for and how to check whether it is really working in an installation. So could anybody give me some hints please? VCL has NAS support. I always stumble over it while building OOo (just because NAS enabled builds fail for me most of the time :-). Don't know if there is a (unit) test, so. ciao Christian Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Ruediger, Rüdiger Timm wrote: That's a joke, isn't it? From my point of view of course it has to be (according to your numeration) 1. 4. 5. 2. 3. Why would you copy additional stuff into binfilter? We did enormous efforts to get that monster stripped, and you plan to blow it up again. as you may know, we _love_ to blow up and to double the amount of code every year, this is one of our favorites, isn't it? :-) Seriously, the goal certainly is _not_ to unnecessarily increase code size. Ideally binfilters would be well formed Uno components, independently build and deployable. To eventually reach this goal, we need to make it independent of the rest of the office. Or let me phrase it the other way, if we are going to keep binfilters dependent on other C++ parts of the office, we could just have kept the original approach, to never change the application cores incompatible wrt to the old binary file format. Why? If someone does incompatible changes he must do all necessary adaptions in modules above. Regardless of the name of those modules. Why change code in 'sw' but leave 'binfilter/bf_sw' untouched? See above. Keeping binfilter dependent on other C++ code is -a- a maintenance issue, and -b- forbids certain kinds of changes, we want to do. OK, there may be rare cases where no one is able to adapt stone aged binfilter code with reasonable effort. But that is an evidence of incapacity and should be the strict exception. As said above, there are cases where binfilter would hinder the renewal of other code. This is and was the original reason to factor out the binfilters. This is the way we want to go. It was an error in the first place, to ever expose our internal binary formats. binfilters purpose is to correct this error! At least that's my understanding. Please correct me where I am wrong. I tried :-) Rüdiger Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Mathias, Mathias Bauer wrote: I think the problem is that you can't give a fixed order for 2,3 and 4. This must be checked for every single case. Perhaps Kay should point this out in the wiki. I disagree here. Actually the right order is 2,3,4: 3 certainly comes after two, as copying parts of a module is superior to copying the whole module. 4 is after three, as the _goal_ is to make binfilter independent. But IMHO it's clear that option 1 is by far the best and should be aimed for as often as possible and that option 5 should be considered only in desperate cases. Certainly. Copying just some pieces is IMHO OK as well. Especially as these pieces are the things which are going to be changed in the non binfilter code, otherwise there wouldn't be any need to copy. Ciao, Mathias Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Heiner, Jens-Heiner Rechtien wrote: Thorsten Behrens wrote: b) move _all_ modules below binfilter into that module, possibly after stripping them to the necessary minimum. Build it once, and tuck it into a safe place (comes close to a, but is smaller integrates with OOo3). Unrealistic, because rebuilding the binfilters might be necessary for all kind of reasons: compiler changes, base line changes, bug fixes, new platforms etc. Over long it would be part of the regular build again, now only bigger than ever before. Good point. We try to stay ABI compatible but fail once a while ... :-( Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] OOo Wiki: Categories Overview
Hi guys, it seems this is the best list to discuss OOo wiki topics. In my view, the wiki could be somewhat more organized. E.g. it seems that anybody has a different plan and list of categories. To get this more in order I created a page listing the categories we are using, adding short explanations. I also tried to outline how categories could (should?) be used. You may want to take a look at http://wiki.services.openoffice.org/wiki/Categories Feedback certainly welcome. Thanks for listening Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Ruediger, Rüdiger Timm wrote: Sorry, now I see your other mails. Looks loke a mail server problem. I saw the mails appearing in reverse order as well, did not expect you to answer sooo fast :-) Rüdiger Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Armin, Armin Le Grand wrote: I do, but what about the suggestion? Repeating here: Comparing the costs spent up to now by all and that will be spent until the goal is reached, i again have to suggest (as years ago) to do it once, by one person and for the next public release. The resulting binfilter module will be an UNO-API only module, independent of 'living' C++ code and can then rest on that version. I am _all_ for it. What's the amount of work left ? Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Extending the binfilter Module
FYI Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently had a discussions regarding how to deal with binfilter in case of incompatible changes of modules used by binfilter. We came up with the following recipe: For every request of an additional module for / change of binfilter the following steps are to be tried in the following order: 1. Check if the dependency could not be removed / avoided completely. - For the above change this means, to verify that basctl is indeed needed for loading / storing documents. 2. Copy the code which is needed only. - For the above change this means, that the serializers (import / export) may just be copied out of basctl to binfilter (respectively they may be just reimplemented if this is easier :-) . 3. Copy the whole module. - If the target module is reasonable small, the whole module may be copied to binfilter. For the above change this would mean to copy basctl to binfilter. 4. Adapt binfilter to the incompatible changes done in the dependent module. - For the above change this would mean, to adapt binfilter to the changes done in basctl. 5. Do not change the dependent module incompatible. - For the above change this would mean, not to change basctl incompatible. I created a module page for the binfilter module in the OOo wiki and copied the receipt to this page as well: http://wiki.services.openoffice.org/wiki/Framework/Modules/binfilter Hope that helps Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SISSL is *really* deprecated
Stephan, I also was already on my way writing a reply and an issue :-) Kay Pavel Janík wrote: Hi, the following files still reference the license SISSL (files from helpcontent2 are not included on purpose): basegfx/inc/basegfx/tools/debugplotter.hxx basegfx/source/tools/debugplotter.cxx binfilter/bf_sw/source/filter/excel/exlpar.hxx cppu/source/uno/IdentityMapping.cxx cppu/source/uno/IdentityMapping.hxx cppu/test/Environment.test.cxx cppu/test/IdentityMapping.test.cxx cppu/test/Mapping.test.cxx jurt/com/sun/star/lib/uno/environments/remote/Message.java jurt/com/sun/star/lib/uno/protocols/urp/PendingRequests.java jurt/com/sun/star/lib/uno/protocols/urp/UrpMessage.java offapi/com/sun/star/awt/XSimpleTabController.idl offapi/com/sun/star/awt/XTabListener.idl offapi/com/sun/star/ui/dialogs/DialogClosedEvent.idl offapi/com/sun/star/ui/dialogs/XAsynchronousExecutableDialog.idl offapi/com/sun/star/ui/dialogs/XDialogClosedListener.idl scp2/source/ooo/module_java.scp scp2/source/ooo/module_java.ulf so3/inc/so3/so3dllapi.h svtools/inc/dialogclosedlistener.hxx svtools/source/misc/dialogclosedlistener.cxx svx/inc/svx/sdr/contact/viewcontactofunocontrol.hxx svx/inc/svx/sdr/contact/viewobjectcontactofunocontrol.hxx sw/inc/IDocumentSettingAccess.hxx sw/inc/IDocumentTimerAccess.hxx vcl/unx/source/gdi/xrender_peer.cxx vcl/unx/source/gdi/xrender_peer.hxx SISSL is really deprecated, so please remove this license from your files. --Pavel Janík [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]
Re: [dev] Build from scrach breaker SRC680m196: i72372
Hi Matthias, Mathias Bauer wrote: Kay Ramme - Sun Germany - Hamburg wrote: Hi, I unfortunately oversaw a build dependency leading to http://so-web.germany.sun.com/iBIS/servlet/edit.ControlPanel?tid=i72372 Kay, you should use URLs that work outside of our office. :-) http://www.openoffice.org/issues/show_bug.cgi?id=72372 You are certainly right, I was somewhat in a hurry ... Ciao, Mathias Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Build from scrach breaker SRC680m196: i72372
Hi, I unfortunately oversaw a build dependency leading to http://so-web.germany.sun.com/iBIS/servlet/edit.ControlPanel?tid=i72372 a patch is attached. Sorry Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Unicode---Give us all of it!
Michael, Michael Meeks wrote: There's no chance then of switching to UTF-8 as an underlying string representation :-) and saving a measurable chunk of our string overhead ? this is certainly possible by introducing a new string (I mean exactly _one_ string), which IMHO should address some other points I investigated into (see http://wiki.services.openoffice.org/wiki/Uno/Binary/Analysis/String_Performance). This new string should also be opaque, so that internal data representation could use the most beneficial format available (which might be UTF8). Unfortunately, this would be incompatible and quite a big chunk of work. Interesting mail anyhow, Regards, Michael. Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Unicode---Give us all of it!
Stephan, from my point of view, we should have originally followed what the glibc does with wchar_t (see http://www.gnu.org/software/libc/manual/html_node/Extended-Char-Intro.html), unfortunately switching to this obviously is incompatible and a lot of work, so your suggestion sounds quite reasonable. Kay Stephan Bergmann wrote: Unicode---Give us all of it! Unicode encodes characters in a codespace that ranges from 0 to 0x10. Much of the OOo code base operates on UTF-16 code units that range from 0 to 0x: - C/C++ code based on sal_Unicode. - Java code based on Java char. - UNO based on UNO CHAR. It is obvious that a single UTF-16 code unit cannot represent all of Unicode. Thus, UTF-16 is designed in such a way that each Unicode character can be represented in UTF-16 as an ordered sequence of at most two code units: Characters in the ranges U+--D7FF and U+E000-- are represented by a single UTF-16 code unit (of the respective numeric value). Characters in the range U+1--10 are represented by two UTF-16 code units, a high surrogate in the range 0xD800--DBFF followed by a low surrogate in the range 0xDC00--DFFF. In turn, it should be obvious that treating single UTF-16 code units as representing Unicode characters does not work. However, since most actually used Unicode characters are in the range U+-- (and can hence faithfully be represented by a single UTF-16 code unit), this problem is not apparent in all situations. This will gradually change as Unicode characters in the range U+1--10 are used more and more frequently, especially in East Asian locales. And this should be motivation to enhance OOo so that all parts of it work flawlessly with all of Unicode. In Java 5, this problem has been addressed by augmenting functionality based on Java char single UTF-16 code units (e.g., String.charAt) with functionality based on Java int (0--0x10) Unicode encoded characters (e.g., String.codePointAt), and by using functionality based on java.lang.String UTF-16 code unit sequences. Similar solutions are needed for C/C++ code and UNO APIs. A related problem is that Unicode combining character sequences like U+0041 LATIN CAPITAL LETTER A followed by U+20E3 COMBINING ENCLOSING KEYCAP shall be treated as single characters in certain applications. (For example, if you can specify the bullet symbol that shall preceed each list item you enter in a word process, combining character sequences could be useful choices for such a symbol.) This indicates that an application's concept of character is often best represented by a programming environment's concept of string. C/C++ Code -- The approach here has two parts: Use sal_uInt32 to represent individual Unicode encoded characters and add any necessary base functionality to rtl::OUString (e.g., operating on the individual Unicode encoded characters represented by an instance of rtl::OUString). Find all the places in the code that need to be adapted. Java Code - No Java code within OOo that would need to be adapted has been identified. (Any necessary adaption would be complicated by the fact that OOo shall be compatible with Java 1.3.1, so that much of the functionality offered by Java 5 would not be available.) UNO APIs Replace (if unpublished) or supersede (if published) any API that uses CHAR with a corresponding API that uses STRING. Find attached a list of all occurences of CHAR within the API (types.rdb) of SRC680m193. How to proceede --- In a first step, I will try to identify and gather as many places in OOo that need to be adapted, but I need your help for that: IF YOU KNOW OF ANY PLACE IN OOo THAT NEEDS TO BE ADAPTED, PLEASE LET ME KNOW. Once all places have been identified, we can see how to address the task of adapting them accordingly. -Stephan com/sun/star/accessibility/XAccessibleText: char getCharacter([in] long nIndex) com/sun/star/awt/KeyEvent: char KeyChar com/sun/star/awt/KeyStroke: char KeyChar com/sun/star/awt/SimpleFontMetric: char FirstChar com/sun/star/awt/SimpleFontMetric: char LastChar com/sun/star/awt/XFont: sequenceshort getCharWidths([in] char nFirst, [in] char nLast) com/sun/star/awt/XFont: short getCharWidth([in] char c) com/sun/star/awt/XFont: void getKernPairs([out] sequencechar Chars1, [out] sequencechar Chars2, [out] sequenceshort Kerns) com/sun/star/awt/XTextEditField: void setEchoChar([in] char cEcho) com/sun/star/i18n/XExtendedInputSequenceChecker: long correctInputSequence([inout] string aText, [in] long nPos, [in] char cInputChar, [in] short nInputCheckMode) com/sun/star/i18n/XExtendedTransliteration: char transliterateChar2Char([in] char cChar) com/sun/star/i18n/XExtendedTransliteration: string transliterateChar2String([in] char cChar)
Re: [dev] Specification Process Possibilities ... - unit testing
Hi Thorsten, Thorsten Behrens wrote: Kay Ramme - Sun Germany - Hamburg [EMAIL PROTECTED] writes: Certainly, the final solution would run these tests during regular builds, just want to keep some work for later ... ;-) Hi Kay, yes, definitely. What about a staged approach to that: first include all unit tests in a regular build, but _only_ perform them with a magic env var set (like the debug=true stanza)? good idea, that would at least make it obvious how to trigger the tests ... Thus, issuing a 'build tests=true' builds with all unit tests enabled (and could later be made the default). Agreed on. Would you be so kind, to write me an RFE for the UDK project regarding this? Cheers, -- Thorsten Thanks Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Interested in contributing programming
Doug, Doug Descombaz wrote: Hi, I'm interested in contributing my programming skills to open office. I've been using it off and on for a few years and am a big fan. I've implemented Apache's POI on a few occassions. OOos code base is divided into so called accepted projects, see http://projects.openoffice.org/accepted.html IMHO, one of the most important projects is the UDK http://udk.openoffice.org respectively http://wiki.services.openoffice.org/wiki/Uno The UDK (Uno) project specifies and implements OOos component model. Despite to move and update the documentation from http://udk.openoffice.org into the wiki, there are various other todos, please see http://wiki.services.openoffice.org/wiki/Uno/Todo Just send me a note, if you are interested ... :-) Regards, Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] About contributing...
Hi FireS, FireS BurnsmuP wrote: I am not the greatest of programmers, but that is my area of relative expertise. I would like to suggest that (the collective of developers) try to make the program and its components more efficient, i.e. it would be nice if the suite were much smaller. This is the sole reason I previously chose MS Office over OOo. Could you be more concrete and give some examples? If there are problems with this, then I'm sorry I bothered you. If it would be possible to size down everything, I would like to try and help. Lets identify first what disturbs you most ... RSVP ~ FireS Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Wiki Extension: ParserFunctions
Stefan, Stefan Taxhet wrote: But I didn't take the time to read on and bother about '#'s and '#if's. could you do at least the fix regarding the 'if'? Otherwise it is unusable (and worthless :-( ). Greetings Stefan Thanks Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Wiki Extension: ParserFunctions
Hi again, sorry for bothering, but could we again add some extensions to the OOo wiki (http://wiki.services.openoffice.org/wiki/Main_Page) ? Especially I would like to use conditional expressions as described in http://meta.wikimedia.org/wiki/ParserFunctions respectively http://meta.wikimedia.org/wiki/ParserFunctions#Installation Thanks in advance Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] programming
Steven, my name is Kay Ramme, I am the owner of the UDK project of OpenOffice.org (OOo). OOos code base is divided into so called accepted projects, see http://projects.openoffice.org/accepted.html IMHO, one of the most important projects is the UDK :-) http://udk.openoffice.org respectively http://wiki.services.openoffice.org/wiki/Uno The UDK or UNO project specifies and implements OOos component model. steven Holmes wrote: Hello, My name is Steven Holmes and i am interested in helping program for open office. I have a degree in mathematics with a minor in computer science. I have used C++, java, and scheme, but will probably need to brush up on them again before programming. Thank you. Despite to move (and update) the documentation from http://udk.openoffice.org into the wiki, there are various other todos, please see http://wiki.services.openoffice.org/wiki/Uno/Todo Just send me a note, if you are interested ... :-) Steven Holmes Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] ustring - global hash (?)
Michael, would you mind to reiterate the potential / real savings and costs for me? Admitting that I have not understand your explanations the first time ... ;-) Thanks Kay Michael Meeks wrote: On Tue, 2006-08-29 at 16:55 +0200, Stephan Bergmann wrote: Yes, some (singleton) functionality rtl::OUString intern(rtl::OUString const arg) of course - for programmatic operations: rtl::OUString intern(const char *str); would prolly be a valuable variant; and since we'd need to hash that string anyway, we could dispense with some ugly macro evil to calculate the length, making some code potentially sweeter. t'would be nice, you make me almost want to implement a simple hash table in sal/ now :-) [ which I could re-use to make the string debugging more portable up-stream-able ]. Regards, Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] ustring - global hash (?)
Michael, Stephan, sorry for being so slow. Do I understand correctly, the suggestion is to introduce a (Java like) string internalization feature (every string value is exactly instantiated once)? Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] About join community of OO---RedFlag CH2000
Xiuzhi, xiuzhicheng wrote: hi all I am Xiuzhi Cheng ,RedFlag Chinese 2000 Software Co. A OpenSource Technology Department has been established this week and i am the manger of it.The aim of this department is to contribute towards openoffice.org. The original plan to set up our RedOffice Open source community is shelved now. We are eager for undertaking some tasks of OO development.Please give me some guide about how our development teams can join community of OpenOffice.org as soon as possible.thanks. OOos code base is divided into so called accepted projects, see http://projects.openoffice.org/accepted.html IMHO, one of the most important projects is the UDK http://udk.openoffice.org respectively http://wiki.services.openoffice.org/wiki/Uno The UDK or UNO project specifies and implements OOos component model. Despite to move and update the documentation from http://udk.openoffice.org into the wiki, there are various other todos, please see http://wiki.services.openoffice.org/wiki/Uno/Todo Best Regards. Xiuzhi. 2006-08-04 Just send me a note, if you are interested ... :-) Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] interested to contribute in openoffice.org
Anbu, mukhilarasu arasuanbu wrote: Hi, I am a developer having 3+ years of experience in various development projects and having development experience in OOAD, C++,Java2 and J2EE technologies. sounds good. I am very much interested to participate in openoffice.org project sounds good as well :-) guide me to start... OOos code base is divided into so called accepted projects, see http://projects.openoffice.org/accepted.html IMHO, one of the most important projects is the UDK http://udk.openoffice.org respectively http://wiki.services.openoffice.org/wiki/Uno The UDK or UNO project specifies and implements OOos component model. Despite to move and update the documentation from http://udk.openoffice.org into the wiki, there are various other todos, please see http://wiki.services.openoffice.org/wiki/Uno/Todo Just send me a note, if you are interested ... :-) Thanks Anbu Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning free code: the missing modules
Hi, please correct me, if I am wrong. I understand this as a 'C' inherited C++ oddity (no constructors for integral values), which leads to a warning if the first operation on the integral value is not classified as assignment. Obviously 'operator =' has not been classified as assignment at least not for the right operand. So, it seems that we have used the wrong operator here. Therefor I tend to agree to Frank, that we may want to fix this. Kay Frank Schönheit - Sun Microsystems Germany wrote: Nonetheless, I would not consider initializing b with something meaningful a mutilation. And be it just because months later, somebody will be tempted to re-use b some lines below. Ciao Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning free code: the missing modules
Stephan Bergmann wrote: Kay Ramme - Sun Germany - Hamburg wrote: Hi, please correct me, if I am wrong. I understand this as a 'C' inherited C++ oddity (no constructors for integral values), which leads to a warning if the first operation on the integral value is not classified as assignment. Obviously 'operator =' has not been classified as assignment at least not for the right operand. No, the compiler does not assume the user-supplied operator = has any assignment semantics. Rather, as the operator = is inline, GCC tries I thought that this is what I said ;-), however. So, it seems that we have used the wrong operator here. Therefor I tend to agree to Frank, that we may want to fix this. The choice of operator is indeed unfortunate. However, I do not agree that - T b; + T b = T(); is in general a fix that improves code quality. Certainly not in general, only for the places the warning gets emitted. And only for the reason, that we may have chosen the wrong operator. If I get it right, the compiler makers are more or less in a dilemma. -Stephan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Wiki Extension: DynamicPageList2
Michael, Leibowitz, Michael wrote: It is done. SUPER! And thanks -- Michael Leibowitz Software Engineer, Channel Platform Solutions Group Intel Corporation michael.leibowitz at intel.com +1 503 264 7621 Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Wiki Extension: DynamicPageList2
Michael, Leibowitz, Michael wrote: Sorry for the delay. I had trouble getting it together for the 28th. The wiki needs upgrading for the extension, as well as to prevent some XSS attacks. Because of this, I need to take it down for longer. I will do it the 30th. There is a notice on the wiki. Once again, I'm sorry about the delay. no problem and thanks for the update. -- Michael Leibowitz Software Engineer, Channel Platform Solutions Group Intel Corporation michael.leibowitz at intel.com +1 503 264 7621 Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Juergen, Jürgen Schmidt wrote: we are currently evaluating if we can open source the guide. But i would Can we help somehow? Juergen Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Jürgen, Jürgen Schmidt wrote: We also thought about a transformation into the wiki but it is not yet clear how we can extract the relevant info from the wiki to prepare a usable guide (e.g. PDF) as we can it currently. Although a wiki would have some advantages we currently prefer a different format. I am all for the wiki approach. The wiki allows to split the content according to the projects. It scales, is designed to be very simple to use as well as it is offering a place for discussion. On the other hand, I am certainly no expert in professional writing at all. Maybe you have some further ideas what would be the best way to maintain and work with such a huge document. Splitting in smaller parts is already planned ;-) (DevGuide 1-5 or something like that) But that wouldn't change the problem because even the split parts of the guide are parts of one big project. The pure size is IMHO the biggest problem, I suggest to split it into pieces according to the established OOo projects. This is the only way I can think of, to get it scaling. Juergen Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Adding my own tags into ODF-Format
Hi Tom, Tom Schindl wrote: Hi, I'm in the situation that I have to create complex reports using OpenOffice. I choose to use a templating lib named freemarker I would expect it to be a pleasure ;-) (www.freemarker.org) and leave OpenOffice as the designer. The problem is that after I have filled in my freemarker tags I can not open the document any more in OpenOffice because it doesn't match the file format. No my questions is, is it possible to teach OO new Tags? AFAIK, the problem is, that after adding your custom tags, your document is not longer ODF compliant. Basically, OOo does not know anything about your tags and does not know what to do with them. Let's take a small sample from ods: office:document-content ... xmlns:ftm=http://www.freemarker.org/XML; ... table:table table:name=Tabelle1 table:style-name=ta1 table:print=false office:forms form:automatic-focus=false form:apply-design-mode=false/ table:table-column table:style-name=co1 table:default-cell-style-name=Default/ ftm:if test=x=1 table:table-row table:style-name=ro1 table:table-cell office:value-type=string text:pHallo Welt/text:p /table:table-cell /table:table-row /ftm:if /table:table /office:document-content ... Is it somehow possible to learn OO to accept this new tag? If the above case is not possible is the next one possible how? I am not so much an ODF or XML expert, that I could tell which your tag is. Is it the ftm ? However, the only way I can think of tunneling it through (assuming that it is what you want to do) is as content, e.g. as text or values or somesuch. Thanks Tom Do not know if this helped Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Rene, Rene Engelhard wrote: http://qa.openoffice.org/issues/show_bug.cgi?id=37034 So, obviously the Dev.Guide is non-free. I wouldn't say that OOo is non-free because of this. In this sense, Debian can obviously redistribute the OOo SDK without the Dev.Guide only. That's what we do now but it still means repackaging the source since What needs to be done to simplify this process? That this stuff is free so I don't need to remove it? :) -Frank Peters, Juergen Schmidt: Could you please comment on any license plans regarding the Dev.Guide? I didn't see bad effects, but didn't dig deep into it. Even if there were issues I wouldn't be able to use gpc... It seems, that already have had a good experience with basegfx. Did you provide patches for removing gpc? Well, there's already -disable-gpc. That I can use. The gpc stuff thankfully isn't in-tree anyway so it doesn't matter that much. But I can now do a patch to remove gpc support completely, yes.. should be also removing stuff from configure and removing #ifdefs... Reducing code is IMHO always a good thing. So, lets see what Thorsten says. No, it's not. It's an issue for any serious admin. You don't want to have any user set the link youself, you want to add it globally and be done with it. That's the same case here, I could package it but let the users enable the plugin but that IMHO is bad. So, this is an OOo issue independent of any distros needs. Obviously it has not been regarded yet to be severe enough to get fixed. This has nothing to do with our discussion. It has. Because atm the mozilla plugin is useless for serious distributions/admins. Please treat this as a regular show stopper. If this is a serious problem for administrating Debian OOo, than it is for OOo OOo or StarOffice as well. well, it changes ABI... SAL is supposed to encapsulate all system dependent file operations, the comment in the issue states, that all necessary types are already 64 bit. Turning on LFS for SAL is, as far as I understand, not changing SALs ABI, as non system implemented function is passed through. So, I have to admit, that I do not which ABI you are talking about. Err. *If* you build with LFS, build *everything* with it... in any case, irc snippet, I didn't dig much into there, but: 12:59 asuffield _rene_: note that it's an ABI change 13:00 asuffield a few of the file-related structs change size and offsets 13:00 asuffield (plus off_t itself, of course) Even if structs may change size or anything, it does _not_ matter if they are not used. And even if they are used in a private way (not exposing it at the API), I can not see any problem. Is there somebody with a more deep understanding (-Tino, Hennes, Oliver, Heiner) listening and can comment? Pushing it upstream is nice and is done, but it might be that we need the fix now anyway for further testing of the debs, fixing a release-critical bug, preparing for the release, help the users suffering from the ug *now* etc. As said, the real code issues still seem to origin from your changes. No, I didn't change the plugin in any way (well, we do with michaels patch now, which doesn't work reliably either) It simply doesn't work if you eant to enable it globally. So, you mean that from your point of view this issue is release critical, while the rest of OOo does not think so? yes. That's why I neeeded to disable the plugin *completely*. No plugin at all in my packages. So it is not a stopper, you found an ugly but working solution! The license stuff is more ugly, but should be solvable one or the other way also. Some things even can't be gotten upstream. Like FHS support. If you have a good idea how it's possible to add it without breaking your stuff (or mine if you change something) please tell me. Not that fully FHS'izing OOo does work OOos standard builds are AFAIK fully FHS compliant. The problem is, that you change OOo to match your distribution and to become a bundled product. For you. Not for distris. The FHS does *not* allow /opt for distris. /opt is for third-party add-ons. Like for you. distris have to use /usr/lib, /usr/share, /etc, /var etc. (which I currently do using some symlinks, hacks, etc, and teh config still isn't in /etc and the arch-indep stuff still is in /usr/libn/openoffice/share.. AFAIK, /opt is for unbundled software, while the other directories are for bundled stuff. You may very well create a OOoForDebian and release it as unbundled software. And this is exactly the point I wanted to make, why do you want to release it as bundled? Because we are bundling it with the rest of the system and want integration? And because /opt is forbidden for distris. See above. You could very well ship a stock build from OOo (assuming that .debs would be provided), extending it with some custom system integration, basically not loosing any functionality and reducing your burden to always need to build everything! There was _not_ yet
Re: [dev] Wiki Extension: DynamicPageList2
Michael, it seems that the extension has not yet been installed on the wiki. According to Stefans forward, the 28th had been planned. Would you mind to give us an update what went wrong? Thanks in advance Kay Stefan Taxhet wrote: Hi, Leibowitz, Michael wrote: I think it would best for us to schedule wiki downtime after the main site has recovered from maintenance. The Wiki operates indepently of the main site and we are free to tweak it at any time. AFAICS the installation of an extension needs no downtime. Stefan, is the afternoon (Hamburg time) of the 28th of June acceptable? Sure, if an earlier date does not work. As said in another message you may feel free to go ahead at any time. Greetings Stefan - 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] Packaging process
Rene, that was a fast reply :-) Rene Engelhard wrote: Am Donnerstag, 29. Juni 2006 15:34 schrieb Kay Ramme - Sun Germany - Hamburg: distributions (not me) don't ship db4.2 anymore so they need to maintain own patches to use db4.3/4.4 which can't go upstream.. At least the numbering (minor update only) implies compatibility, so what are the patches for? API changes in db. They change API between minor releases which is also normal for other stuff. Or change db on-disk format (which thankfully isn't the cas ehere for OOos needs) Does that mean, that they did change the API incompatible in a MINOR? If it did not change incompatible, than there is no problem anyway. Yes. So, SONAME is not of any help here anyway. The db ABI seems to be Is is. Of course, those different versions have differend SONAMEs. So, if it has nothing to do with SONAMEs, why did you talk about SONAMES in the first place? unstable / unreliable. I can only see two solutions, either link hard against one particular version (which is unlikely to be available on all supported distros), or ship it privately. Yes.. ALthough db4.2 is that old But there unfortunately are distros which think they always must port stuff to the newest db and drop the old ones with no reasons (ok, for db4.2 there is because it has some licensing problems) So, you agree that there is no solution as to bring it privately with us? Also, this is what LSB recommends for non LSB stuff. There already is --with-system-zlib. Just not enabled per default for everyone because *you* (Sun) didn't want that. I am for enabling it on all Linux build from the start. There must be a reason for disabling it by default. If there is not, nobody would hinder you to turn it on. getopt is libc, so getopt is out of the discussion to make optional, and my upcoming patch will make it unconditional. Did yet have to do other stuff... See above. Regards, Rene Rene, you still did not provide any real reason to build the stuff by your own, instead of contributing and improving the overall situation for all (Debian based) distributions and users. The technical reasons you listed were IMHO _all_ minor. This is _not_ to offend you in any way, I certainly appreciate your work! I certainly can accept, that you say, that this is what distros do, and I am willing to support you! But, I still think that this is wrong technical approach and I am going to keep my opinion until somebody argues the opposite in a way, that I can understand. Thanks for the discussions and looking forward to meeting you at the OOoCon2006 Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Rene, Rene Engelhard wrote: So, what are they saying that they do not update the older versions? Are they backporting the fixes, or is Debian doing that? There are not. There wasn't really firefox security updates except new firefox releases with other stuff. Same with the normal Mozilla. Does Mozilla describe somehow, how distros are supposed to bundle its applications and how they are supporting the distros or something similar? This obviously should include the handling of security patches etc. contains mozilla 1.7.5 which you build against (NB: I don't know how your build env looks like) and ship. As already said elsewhere, the problem is, that we did not find a way, to reliable express dependencies against 3rd party stuff, except for the real core stuff, as libc and friends. And AFAIK even these are not You also ship getopt and readdir. Which reminds me I need to finish my patch to hack that out and make Linux builds not use it. expressed in a formally correct way. Yes, but then you still could have updated mozilla in-tree. it's still 1.7.5 there. Also the handling of issue http://qa.openoffice.org/issues/show_bug.cgi?id=66338 was bad. You are not shipping our version of Mozilla, so I would say, this is more or less our problem only. By the way, I think it would have been nice, to separate 3rd party stuff into their own packages (going to add this to my notes). Because you can't do source fixes? You can't produce reliable binaries? You certainly can, every binary release of OOo is (nearly:-) bitwise reproduceable and tagged accordingly in CVS. And I would be surprised, if our binaries would be less stable than yours ... No, you only can (assuming you take the binaries) when you got a new release. (Or a new milestone, rc, whatever, where the first is not really recommended for a stable release and the rc, well, it might, but..) I do not understand this, could you elaborate? You can't provide packages for other archs (like we also do ppc and sparc, for 1.1.x there also was s390) You may want to look at this from the other side. Builds for other archs may very well just be contributions to OpenOffice.org. OpenOffice.org would than obviously provide these contributions. There is no need to rebuild anything, even if you want to support other archs. Oh? You do e.g. Linux SPARC builds/porting? Where? Last I know only Jim Watson does. You surely own sparcs at Sun so hardware cannot be the issue? Analog with Linux/powerpc. I was talking about contributing. The work does not necessarily need to be done by us. In my opinion, this all is only a question of scalability. Things need to be done where they belong. Installation sets etc. IMHO belong to the project, they may very well be contributed by others, so. I would love to be able to put mozilla.org, x.org, openoffice.org, gnome.org etc. into my sources.list and to dynamically and _directly_ update my Linux. (claims to becausse there's stuff which is *not* free in the tree since loong which outstanding issues for them...) You may want to give me a hint? http://qa.openoffice.org/issues/show_bug.cgi?id=21678 This was some reading, I think I understand the issue and expect Martin to fix it for 2.0.4. http://qa.openoffice.org/issues/show_bug.cgi?id=37034 So, obviously the Dev.Guide is non-free. I wouldn't say that OOo is non-free because of this. In this sense, Debian can obviously redistribute the OOo SDK without the Dev.Guide only. - - using non-free libraries like gpc (thankfully now avoidable by --disable-gpc and using basegfxs stuff) This is indeed ugly. Could basegfxs replace gpc completely? - - questionable licenses for the hyphs (need to remove all but de and hu) - - rhino/rhino.patch (quite obvious, told mh, nothing happened yet) Need to take a look ... - - jurt/doc This is ridiculous, somebody should just remove it! For those issues I didn't file an issue because it woldn't have brought anything (see the jars issue). But we nevertheless need to remove this stuff from Debians source and binaries. We may want to discuss these things further on OOoCon2006. May be together with other distributions. I mostly commit fixes myself now when I have some... Sounds good :-) When I can not there's problems.. But for important functionality bugs or licensing bugs there's still no fix. Issue numbers on request... Just give me some ids, I try to comment ... See above. Or take http://qa.openoffice.org/issues/show_bug.cgi?id=49590 (which is still not fixed even with michaels patch, and so it's disabled This seems to be a distro issue only, so I am not sure why the patch did not make it yet. completely in Debian...). Or that LFS issue above which had a tiny change (which changed ABI, though, I am aware, so I didn't force it into my packages myself, although I think it wouldn't have mattered, we use an other stlport than you anyway - http://packages.debian.org/libstlport4.6) If I understand
Re: [dev] Will OOo version 3 preserve backwards file compatibility with OOo 2 ?
David, David Wilson wrote: In terms of the file format they would be. Older versions of Writer would just ignore the extensions. The question is how much backwards compatibility do we need to build in. In the current version of Writer every time you insert a Bibliography Entry / Citation the full set of bibliographic data (author, publisher etc.) is stored with each Entry, and no link is made with the source of the entry. The only way to correct a Bibliography Entry is to find each one and edit its data, or correct the database and reinsert the relevant Bibliography Entries. backward compatibility is often regarded a holy cow. The ones saying that you never ever are allowed to break it (often representing commercial entities), while others saying that such a beast never existed (often voiced by open source protagonists), that you are always allowed to do whatever you want, at least on the ABI level. So, my personal approach mostly is, if I do not expect to annoy to many people, I just break it and see what happens, otherwise I keep it. David Sorry for not being to helpful here, I am sure Michael Brauer has more to say Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Hi Thorsten, Thorsten Behrens wrote: Kay Ramme - Sun Germany - Hamburg [EMAIL PROTECTED] writes: - - using non-free libraries like gpc (thankfully now avoidable by --disable-gpc and using basegfxs stuff) This is indeed ugly. Could basegfxs replace gpc completely? This is mostly a question of test coverage. Functionality-wise, it's You mean, we do not know what we may break, do we? clearly possible. Would it be reasonable to do it in one of the next updates? Cheers, Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Packaging process
Éric, Éric Bischoff wrote: I - Good reasons 1) Suitability - Not all the Linux distributions follow the same purposes. Some are for desktop users, some are for generic servers, some are for specialized purposes like firewalls, application servers or clustering. Some try to imitate Windows or Mac OS X, some try to get away from other OSes as much as they can. A lot of changes are made to give personality to the distributions. That does not necessarily mean, that they need to patch or change anything in the provided products, does it? At least OOo provides extensive configurability to actually change everything, without needing to alter a single line of code. 2) Coherence - A Linux distribution is a coherent set of software. Even if documents like FHS and LSB state a lot of things, like the place where files should go, there's room for a lot of variations. As long as the various choices are coherent within the same distribution, that's okay. A lot of changes here and there attempt to have all software follow common conventions. I think you hit the point here, IMHO Linux does not only need to be coherent inside the distributions, but also _overall_ ... 3) Corrections - A lot of the work is made to fix problems in the packaged software itself. Why are such changes not done upstream at the initial software projects? They are done upstream too, but since it's a much slower process than a quick fix in the distribution, upstream corrections are done usually much after the distribution is in the retail stores. This is understood, but is IMHO the wrong approach and really should be the exception, I think at least we at OOo are very willing to support the distributions to get their fixes merged in upstream. II - Bad reasons 4) Not invented here - We all think that we have better ideas than our neighbours, so we want them our way. Distribution makers just follow the same behaviour because they have an ill ego just like every computer scientist. Yeah, I know that feeling too ;-), but try to be steady ... IMHO, Coherence and Suitability can be addressed independent of patching / rebuilding / packaging software products. Non-Coherence over distributions is one of the biggest obstacles ISVs, and I count OOo or Mozilla as ISVs, face when supporting Linux. LSB is actively trying to address this, unfortunately with varying success. I did visit the last DAM (Desktop Architects Meeting) in Mainz (organized by the OSDL), and we did talk a lot about this, so I am not yet sure, that we have any real outcomes ... ;-) In short: I suppose you bring a big problem to distributors by bringing already packaged software. I think I disagree again, as you said, distros may just install and repackage OOo. IMHO, the most prominent reason for repackaging is to change OOo to be a bundled product, while the packages we are providing are unbundled. The point being, that there IMHO is _no_ real or good reason to have products (applications) to be bundled, except that this is what distros do. Again, I am not working for a Linux distribution anymore, so that's mostly a guess of mine. Perharps someone can tell whether that's correct or not in his/her case. Any distros listening? I will cowardly let the Debian guys answer this ;-). Yes, Debianists, please comment ... Yup. In my honest opinion, if you really want to build packages, it should be done the regular way, on top of a make install. That implicits, to be able to work as root on a dedicated machine, while only wanting to develop OOo ... if all products / software would be provided as packages by their developers, there would be far less incompatibilities between the distributions, Well, there would be no distributions at all ;-)... So, you are right, that is what I personally concluded several times, when thinking about the subject. And yes, I know that this is a sensitive topic to discuss ... ... and we would have the DLL conflicts nightmare in Linux too (see Coherence paragraph) ;-). So, we already have that par excellence ... :-(. Exactly this is the reason, why we (being an ISV) have to bring all this 3rd party stuff by our own, basically being a kind of a mini distro on Linux. and one wouldn't need to wait until a particular distribution would provide the latest package of a particular product ... That's the Windows way, not the Linux way. Two points here, - being different just to be different (without good technical reasons) is IMHO stupid, - this could very well be one of the most prominent reasons for Windows success in both worlds, the open source world and the commercial world. And I want Linux to be successful in both (or more) worlds as well. Thanks for your explanations and comments, I am enjoying the discussions ... :-) Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:
