[dev] Mozilla libraries in LD_LIBRARY_PATH?
Hi all, Current (SRC680m246) soffice start scripts on Unix still try to add some Mozilla library directory to LD_LIBRARY_PATH or equivalent, see desktop/scripts/soffice.sh:1.29 l. 88--168. Does anybody need that code, or can it go for good? -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SRC680_m246 build breaks in
Giuseppe Castagno wrote: mm, it seems I have no scext module, I checked out the source in full, but no scext module present and no error signalled. I'll do it again. that is issue 85986. I think there was a warning message just when the build begins... jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: Proposal: Drop Win98 support with OOo 3.0 release
Martin Hollmichel wrote: since the efforts for supporting Windows98 and WindowsME are reasonable high and makes maintainability of the code quite hard, I would like to propose to drop Windows 98/ME support with the release of OOo 3.0. ... (Briefly) what is it about supporting Win98 that makes it hard? Missing/buggy features? Testing? I'm just curious. As someone whose only Windows is still 98, I hate to see it, but I suppose it is inevitable. I almost never boot it any more, but I know there are people who do, and are very happy that OOo still runs on '98. Do we have any data as to what fraction of OOo users are running '98/ME? OOo 3 will introduce some file format incompatibility, right? Will the default ODF output from 3.x be readable by 2.x? Will people who are stuck with OOo 2.x on '98 suddenly find that they can't open documents created by other OOo (3.x) users? What is the plan for OOo 2.x; will there be any long-term support for 2.x? Will it be a viable option for people who depend on '98 to just stick with 2.3? Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] New intermediate version 1.1.1 of the OpenOffice.org API plugin available
Hi, i have promised it for last Friday but i wanted to do some clean up first, sorry for the delay ;-) I have put a new intermediate version 1.1.1 of the OpenOffice.org API plugin on the API project page (http://api.openoffice.org/Projects/NetBeansIntegration/org-openoffice-extensions.nbm). See also the updated download section in the wiki (http://wiki.services.openoffice.org/wiki/OpenOffice_NetBeans_Integration#Intermediate_version_1.1.1_for_NetBeans_6) for further details. Feel free to try it and please report any kind of problem. Juergen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Dictionaries for spell checking etc... (was: Re: [dev] Where our products install to)
Hi all, @Caolan, Petr: I have made this answer of mine a cross post to lingucopmponent.dev as well. And since it is about lingucomponent issues it would be nice to continue the discussion there @lingucomoment reades: This mail is a reply to a posting in the openoffice.dev list. On Fri, 2008-02-08 at 14:05 +0100, Petr Mladek wrote: I think that the best solution would be to get rid of share/dict/ooo and look for the dictionaries into a common place, for example /usr/share/myspell. It would be nice get rid of share/dict/ooo/dictionary.lst. The dictionaries have well defined names. It is possible to create symlinks for compatible languages, ... Well, there might be problems with symlinks on Windows but it would be very useful on Linux. Specifically wrt dictionaries, as you probably know that's precisely what we do on fedora where we've done away with dictionary.lst (well it still works if you want to use it) and just auto-detect them and the language/locale they service based on their names and add looking in a system /usr/share/myspell location as well the shared OOo one and then the per-user one. If there's any interest in it, then I could try and perhaps upstream this work and co-opt the existing --without-myspell-dicts or whatever its called into a sort of --with-system-dicts=LOCATION and bind the code off that, or something of that nature. It seems you guys have your own way with fedora to get rid of the dictionary.lst. Since we currently are in the same process I'd like to describe shortly what we are doing. From what I understood here so far our concept is different but both should be able to be used concurrently. Well at least if we sort out some issues of precedence if dictionaries for the same language and purpose are installed at various places and be identified with various means. Our planned, and for the most part by now implemented, idea was to allow for dictionaries to be installed/distributed as extensions. Thus our approach needs several new configuration entries. BTW as with OOo 3.0 we want to get red of the way those things currently work in OOo. In the meantime when my CWS tl41 is finished an is integrated the old and new behaviour will work both for a while. And for OOo 3.0 a proper migration from the old-working-way to the new one using configuration entries is planned. After that the old code should be removed. Now on to what we currently do or did in the CWS - the path settings for 'Linguistic' and 'Dictionary' have been changed to be multi-paths. The new 'Dictionary' path is now dedicated to those personal user-dictionaries as it always should have been. And the 'Linguistic' path is for data etc. that is to be used and found by an actual spell checker, hyphenator, ... implementation Thus those cnfiguration setting will soon look like this: node oor:name=Linguistic oor:op=fuse oor:mandatory=true node oor:name=InternalPaths node oor:name=$(insturl)/share/dict oor:op=fuse/ node oor:name=$(insturl)/share/dict/ooo oor:op=fuse/ /node prop oor:name=UserPaths value$(userurl)/wordbook/value /prop /node node oor:name=Dictionary oor:op=fuse oor:mandatory=true node oor:name=InternalPaths node oor:name=$(insturl)/share/wordbook/$(vlang) oor:op=fuse/ /node prop oor:name=WritePath value$(userurl)/wordbook/value /prop /node As you can see the 'Linguistic' path covers all places where previously data files for the linguistic might have been installed. The 'UserPaths' entry is actually a string list and thus can also hold more than one path. The next we did is: - spell checkers, hyphenators, ... need to make configuration entries that describe what type of dictionary the may make use of. Such an enty will look like this: node oor:name=SpellCheckers node oor:name=org.openoffice.lingu.MySpellSpellChecker oor:op=fuse prop oor:name=SupportedDictionaryFormats oor:type=oor:string-list valueDICT_SPELL MySpell_old/value /prop /node /node The component has to specifiy it's implementation name and a list of dictionary formats it may make use of. We don't have implementations that make use of more than one format at the same time yet but we want to be flexible and future-safe with our new configuration entries. For example in the future we could have a dictionary format named DICT_SPELL_EXCEPT that is used to identify exception dictionaries. Something that Hunspell currently does not implement, but hopefully will do so at some point. Then it would be normal to support the two formats DICT_SPELL and DICT_SPELL_EXCEPT at the same time. On the other side of the line we now have the new entries for dictionaries: - dictionaries need to make entries in the
Re: [dev] Removing external header guards
Hi Frank, On Mon, 2008-02-11 at 15:00 +0100, Frank Schönheit - Sun Microsystems Germany wrote: Sure. Again: The question is whether the gain is worth the pain. Personally, I somehow doubt it. I'm all for removing external header guards, and doing it in one step. The big gain I see is less confusion among external developers/contributors who do not have all the intimate details, agreements, rules about the codebase. When such a developer sees OO.o's codebase where headers are externally guarded in some places and not in others, he would get confused as to which convention to follow. Eliminating external guards entirely will also remove that confusion. Those who work on the codebase on a daily basis and communicate with each other every day may not be affected much, but there are others who don't have that luxury. Also, the benefit of removing ugliness from the codebase should not be underestimated IMO. Some people may not care all that much, but for others it is a big deal, and one that might determine whether or not he will contribute to the project. There is a pain of course, of syncing all the CWS'es, but it's just a one time pain, so I would not see it as a big roadblock, as long as someone else's doing the work. ;-) Kohei -- Kohei Yoshida - OpenOffice.org Engineer - Novell, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Removing external header guards
On Mon, Feb 11, 2008 at 03:00:06PM +0100, Frank Schönheit - Sun Microsystems Germany wrote: Are you suggesting to do this incrementally? In which way would that help, for the individual developer, who needs to resync one or more CWSs against the inevitably changed include portion of her files? The developer has better control. If I touch includes in any file of any module of any CWS, and have to resync to the big-bang-MWS (the one containing incguards01), I will almost certainly get a conflict. This happens for all people touching any include in any file of any module of any CWS. Yes. But these are easy-to-fix conflicts. My conjecture would be that very few CWS touch more than a handful of include statements, which would be a very bearable pain. If I touch includes in any file of any module of any CWS, and let the script run immediately before I pass the CWS to QA, then at least for this particular CWS, and this particular module (more precise: all files in this module where I tampered with the includes), I will not have conflicts. If you are in the lucky situation of developing this module alone, then yes. But this is rather uncommon in other areas. IoW: There's a little less pain. Still, I am unsure whether the reduced pain is worth the gain. But if we minimize the former, I'd perhaps be willing to sacrifice this uncertainty to the higher abstract goals of removing some uglyness ;) Hey, looks like we've a deal then - do it like that in dbaccess, which, as mentioned, I'll leave alone in incguards01. And the rest gets cleansed by kendy's script an me. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Removing external header guards
Hi Thorsten, I cannot imagine changes to OOo code that do not potentially cause pain someone somewhere. The thing is, it's a change for the better, removes a ton of unnecessary, fragile hard to maintain code, and there simply won't be a better time for this. Sure. Again: The question is whether the gain is worth the pain. Personally, I somehow doubt it. Are you suggesting to do this incrementally? In which way would that help, for the individual developer, who needs to resync one or more CWSs against the inevitably changed include portion of her files? The developer has better control. If I touch includes in any file of any module of any CWS, and have to resync to the big-bang-MWS (the one containing incguards01), I will almost certainly get a conflict. This happens for all people touching any include in any file of any module of any CWS. If I touch includes in any file of any module of any CWS, and let the script run immediately before I pass the CWS to QA, then at least for this particular CWS, and this particular module (more precise: all files in this module where I tampered with the includes), I will not have conflicts. IoW: There's a little less pain. Still, I am unsure whether the reduced pain is worth the gain. But if we minimize the former, I'd perhaps be willing to sacrifice this uncertainty to the higher abstract goals of removing some uglyness ;) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] New intermediate version 1.1.1 of the OpenOffice.org API plugin available
Juergen Schmidt escribió: Hi, i have promised it for last Friday but i wanted to do some clean up first, sorry for the delay ;-) I have put a new intermediate version 1.1.1 of the OpenOffice.org API plugin on the API project page (http://api.openoffice.org/Projects/NetBeansIntegration/org-openoffice-extensions.nbm). See also the updated download section in the wiki (http://wiki.services.openoffice.org/wiki/OpenOffice_NetBeans_Integration#Intermediate_version_1.1.1_for_NetBeans_6) for further details. Feel free to try it and please report any kind of problem. Juergen Hi Jürgen, although cross-posting is bad, a copy of this to [EMAIL PROTECTED] and [EMAIL PROTECTED] will be useful (there is more people interested in Java-NB in these lists than here ;-) ) Regards Ariel. -- Ariel Constenla-Haile La Plata, Argentina [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ArielConstenlaHaile.com.ar/ooo/ Aus der Kriegsschule des Lebens - Was mich nicht umbringt, macht mich härter. Nietzsche Götzendämmerung, Sprüche und Pfeile, 8. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SRC680_m246 build breaks in
Hi Eike, Eike Rathke wrote: Hi Giuseppe, On Monday, 2008-02-11 13:16:34 +0100, Giuseppe Castagno wrote: I can correct the library liblpsolve55.so issue by manually building the module lpsolve, but I have no idea about the other two. Where does libsolver680li.so and come solver680en-US.res from? Module scext, your scext/prj/build.lst should contain the lines scx scext : offuh comphelper lpsolve tools NULL scx scext\source\solver nmake - all scx_solver NULL (Note: m247 also added a dependency to transex3 and rsc) mm, it seems I have no scext module, I checked out the source in full, but no scext module present and no error signalled. I'll do it again. and your postprocess/prj/build.lst the dependency po postprocess :: ... scext ... this looks fine. Thanks, Giuseppe. -- Kind Regards, Giuseppe Castagno [EMAIL PROTECTED] [EMAIL PROTECTED] Acca Esse http://www.acca-esse.eu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Removing external header guards
On Mon, Feb 11, 2008 at 12:33:47PM +0100, Nikolai Pretzell wrote: Frank Schönheit - Sun Microsystems Germany schrieb: What, except removing some ugliness, which is alway highly subjective, is the gain of this change? Maintainability. The uglyness IMHO is not subjective, and a defect. Maintainability is a major problem in any project as huge as OOo, so any improvement is helpful. The external header guards have two kinds of impact: - unnecessary code, - a potential cause for difficult to find errors, when internal include guards change. Yep. External guards expose an implementation detail of the included header, that's a) likely to change (and _is_ changing already for those that unfortunately took the guards out of boost or stlport headers), and b) apparently fragile, as I found a whole lot of places where non-existing or misnamed (wrong case, etc.) headers were included - change the includes in one central header, and you risk build breakages across the whole office. So, in my book, this change is justified, and only lets us suffer some pain now, instead of continuous pain in the future, at a possibly much more inconvient time. As I mentioned, I'll happily exclude dbaccess from this CWS, since you largely reworked includes there. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Removing external header guards
Frank Schönheit - Sun Microsystems Germany schrieb: Hi Thorsten, kendy and me now intend to execute the once-postponed plan to remove external header guards (that #ifndef STUFF #include STUFF #endif ugliness). A bit more background: http://blog.thebehrens.net/2008/02/05/obsolete-external-header-guards/ We already discusses this a little bit by PM, so you know I have to ask this here :) What, except removing some ugliness, which is alway highly subjective, is the gain of this change? Maintainability. The uglyness IMHO is not subjective, and a defect. Maintainability is a major problem in any project as huge as OOo, so any improvement is helpful. The external header guards have two kinds of impact: - unnecessary code, - a potential cause for difficult to find errors, when internal include guards change. I think we should welcome the opportunity that somebody is willing to do this work. Nikolai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Where our products install to
Rene Engelhard wrote: So you want to tellme that /usr/lib/openoffice won't work anymore (be it with /usr/lib/openoffice/ure, /usr/lib/openoffice/basic3.0) anymore? Using /usr/lib instead of /opt as prefix should just work fine, I guess. (In principle, the three layers can be put wherever you want; all that needs to be adjusted are two symbolic links: the brand layer has a symbolic link basis-link to the basis layer, and the basis layer has a symbolic link ure-link to the ure layer. Especially folks that package OOo into some specific distro format should find no real problems with the new structure, I hope. But if there are any details with the structure that could be improved from your point of view, do tell now, as long as the structure is still soft and can be modified rather easily.) -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Where our products install to
Oliver Braun wrote: Stephan Bergmann wrote: The planned new (OOo 3.0) structures are as follows: On Unix (Linux, Solaris): - The URE product still by default will install to /opt/openoffice.org/ure (but only the /opt prefix is relocatable). - The OOo product by default will install its three layers into -- /opt/openoffice.org/ure -- /opt/openoffice.org/basis3.0 -- /opt/openoffice.org3.0 (where only the /opt prefix is relocatable). - The StarOffice product, for example, by default will install its three layers into -- /opt/openoffice.org/ure -- /opt/openoffice.org/basis3.0 -- /opt/staroffice9 (where only the /opt prefix is relocatable). In light of recent events: how will the new directory structure affect LD_LIBRARY_PATH set in the soffice launch script ? It would be nice to have only a small subset of libraries in the directories added to LD_LIBRARY_PATH, especially none of the external. Maybe we create an extra directory (for the purpose of minimizing the number of libs present) and populate it with symbolic links to the real libs ?! I did a lot of work on CWS sb83 to clean up finding of all sorts of dependent libraries (URE libraries, OOo libraries, external libraries, extensions, ...), on all the various platforms; see the new (APP|SHL)nRPATH stuff. desktop/scripts/soffice.sh:1.28.34.8 etc. still contain code to mess around with LD_LIBRARY_PATH etc. and PATH (simply because I did not yet touch that code), but it (a) is probably not needed any longer, and (b) probably sets wrong, useless paths (brand vs. basis) anyway---and OOo continues to work for me, at least in standard situations. Let me know of any LD_LIBRARY_PATH related problems, and we can see whether they are already solved on sb83, or do solve them. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Where our products install to
Caolan McNamara wrote: On Fri, 2008-02-08 at 14:05 +0100, Petr Mladek wrote: I think that the best solution would be to get rid of share/dict/ooo and look for the dictionaries into a common place, for example /usr/share/myspell. It would be nice get rid of share/dict/ooo/dictionary.lst. The dictionaries have well defined names. It is possible to create symlinks for compatible languages, ... Well, there might be problems with symlinks on Windows but it would be very useful on Linux. Specifically wrt dictionaries, as you probably know that's precisely what we do on fedora where we've done away with dictionary.lst (well it still works if you want to use it) and just auto-detect them and the language/locale they service based on their names and add looking in a system /usr/share/myspell location as well the shared OOo one and then the per-user one. If there's any interest in it, then I could try and perhaps upstream this work and co-opt the existing --without-myspell-dicts or whatever its called into a sort of --with-system-dicts=LOCATION and bind the code off that, or something of that nature. I guess Thomas Lange can add to this thread. (I mainly worked on keeping the old code up and running in the new structures largely unchanged, but any additional improvements are of course welcome.) -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Removing external header guards
Hi Frank, Frank Schönheit - Sun Microsystems Germany schrieb: I'm all in for somebody else doing work :), and I do not doubt that it is *reasonable* to remove external include guards /in general/. I only suspect that the minor gain we get from this is not worth the potential medium or big pain it will cause. the resulting conflicts will probably merge gracefully on CWS resync. Anyway, Thorsten already promised to spare your module. :-) Owners of other modules will tell, if they see a problem. Nikolai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Tools - Translation
Hi linuxa, On Sunday, 2008-02-10 10:26:21 +, linuxa linux wrote: I found this sourceforge project quite interesting and I thought why not tell you because it could be a shortcut for all the projects: http://translate.sourceforge.net/wiki/start If you actually had read the page you're posting the link of you might had known that Pootle is already used in OOo translation: http://translate.sourceforge.net/wiki/toolkit/oo2po http://wiki.services.openoffice.org/wiki/Pootle_User_Guide Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks. pgpYapZPHosym.pgp Description: PGP signature
Re: [dev] Removing external header guards
Hi Nikolai, The uglyness IMHO is not subjective, and a defect. Maintainability is a major problem in any project as huge as OOo, Sure. - unnecessary code Which is true for a lot of other places, too. I usually fix those incrementally :) - a potential cause for difficult to find errors, when internal include guards change. If an internal include guard changes - this only means that the external include guard does not apply anymore (i.e. the #ifndef evaluates to false), so the file is unconditionally included, effectively. Where's the difficult-to-find error here? I think we should welcome the opportunity that somebody is willing to do this work. I'm all in for somebody else doing work :), and I do not doubt that it is *reasonable* to remove external include guards /in general/. I only suspect that the minor gain we get from this is not worth the potential medium or big pain it will cause. That's why I still think the all-in-one thing is not the best approach here. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] positive discussion ...
Hi Sophie, Thanks for your mail; I agree - this particular dead-end of the thread got a little unpleasant highly charged; I'm well up for killing it. On Fri, 2008-02-08 at 20:42 +0100, sophie wrote: We are now thinking about SCA, an adapted one to our community, so no need to quarrel about what is already behind. Is there a link to a copy of that somewhere ? (or is the thinking going on on a public mailing list ?). If you really have this energy to argue, please come and discuss how we can reenforce our workflow, our communication flow, our visibility and add more power to our community. I think I'm missing something here. Is there a public statement anywhere that means discussing the unbalanced ownership problems, that (clearly) substantilly impeed Novell's involvement (and that of other developers) is fruitless ? Are you aware of any such statement, or indication from Sun, that says this problem is un-solvable; whatever the community wants ? Of course, such a statement might shut down such discussion pretty quickly, but I havn't seen any clear public statement of that form. Indeed, I've not seen many clear, black white statements about the compromises necessary to accomodate our major sponsor's business interest (which is of course necessary to some degree) inside the project; and what plans there are for the future here. But confidence is a key word in all these discussions to make them come to real facts. So please, really, stop this fight, and allow us to think at something that is reflecting our common love for OOo. So - I think we were getting there - we'd finally got past some of the more basic, emotive, low-level arguments, and were starting to communicate; at least mba I seemed happy: http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=21708 clearly no-one wants to shut down a whole discussion on a topic like this, (and without a conclusion) on the basis of a few sub-threads unfortunately disappearing off into the long grass. I've renamed my reply to remove the odious Butler :-) would be a good move; perhaps as/when we continue other discussions to do the same. Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Where our products install to
Oliver Braun wrote: Hi Stephan, Stephan Bergmann wrote: The planned new (OOo 3.0) structures are as follows: On Unix (Linux, Solaris): - The URE product still by default will install to /opt/openoffice.org/ure (but only the /opt prefix is relocatable). - The OOo product by default will install its three layers into -- /opt/openoffice.org/ure -- /opt/openoffice.org/basis3.0 -- /opt/openoffice.org3.0 (where only the /opt prefix is relocatable). - The StarOffice product, for example, by default will install its three layers into -- /opt/openoffice.org/ure -- /opt/openoffice.org/basis3.0 -- /opt/staroffice9 (where only the /opt prefix is relocatable). Is there a good reason to keep the minor (3.0) in the path names and thus to continue to lose (super-)user deployed dictionaries and UNO extensions when upgrading from e.g. 3.0 to 3.1 ? - The versioning of the basis directory (3 vs. 3.0 vs. 3.0.0) is constrained by the compatibility characteristics of the interface between basis and brand layer: If we can keep that interface compatible among minors, we can label the basis directory just 3; if we can only keep that interface compatible among micors, we need to label it 3.0; if, however, we would not even manage that, we would need to label it 3.0.0. As it stands now, the interface will be rather thin, the brand layer only containing startup code for the executables (and the meat of the executables residing in the basis layer, with few simple entry points), some .ini/rc files, bitmaps, icons, configuration entries, extensions (which should only be programmed against the URE, anyway), etc. But---compatibility is a hard problem, so I am not sure we will manage to stay compatible between minors. - For dictionaries, see the parallel sub-thread by Petr and Caolan. - Shared extensions for now will always go into the brand layer, anyway. (Rationale: there are brands that bring with them brand-specific extensions.) Note that this could be changed in the future, by having three extension layers instead of the current two. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SRC680_m246 build breaks in
Hi Giuseppe, On Monday, 2008-02-11 13:16:34 +0100, Giuseppe Castagno wrote: I can correct the library liblpsolve55.so issue by manually building the module lpsolve, but I have no idea about the other two. Where does libsolver680li.so and come solver680en-US.res from? Module scext, your scext/prj/build.lst should contain the lines scx scext : offuh comphelper lpsolve tools NULL scx scext\source\solver nmake - all scx_solver NULL (Note: m247 also added a dependency to transex3 and rsc) and your postprocess/prj/build.lst the dependency po postprocess :: ... scext ... Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks. pgpTZjIRcjahX.pgp Description: PGP signature
Re: [dev] Where our products install to
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Stephan Bergmann wrote: Rene Engelhard wrote: So you want to tellme that /usr/lib/openoffice won't work anymore (be it with /usr/lib/openoffice/ure, /usr/lib/openoffice/basic3.0) anymore? Using /usr/lib instead of /opt as prefix should just work fine, I guess. (In principle, the three layers can be put wherever you want; all that needs to be adjusted are two symbolic links: the brand layer has a symbolic link basis-link to the basis layer, and the basis layer has a symbolic link ure-link to the ure layer. Especially folks that Aha, that's good to know. Because I do want to keep the installdir version-number free. That of course wouldn't have worked if it expected openoffice.org3.0 somewhere. If it's just done via links, that's fine for me, too. Thanks for the clarification. package OOo into some specific distro format should find no real problems with the new structure, I hope. But if there are any details Yeah, I hope so, too. with the structure that could be improved from your point of view, do tell now, as long as the structure is still soft and can be modified rather easily.) I currently don't see one, but then again I didn't yet invest any work in packaging 3.0 snapshots... Regards, Rene -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHsBM4+FmQsCSK63MRAlv8AJ9ry+gpoovrKOV00B+z+HeIpBfoiACfdD6T qwThxK7JO0df/qKo/7VTeck= =3PE+ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] SRC680_m246 build breaks in
Hi all, on GNU/Linux Debian lenny, while building m246 from scratch, at the end of the process, in module instsetoo_native the build complains with: ** ERROR: Saved logfile: /home/beppe/ooo-b/m246-std/build/current/instsetoo_native/unxlngi6.pro/OpenOffice/deb/logging/en-US/log_SRC680_en-US.log ** ... analyzing files ... ERROR: The following files could not be found: ERROR: File not found: liblpsolve55.so ERROR: File not found: libsolver680li.so ERROR: File not found: solver680en-US.res I can correct the library liblpsolve55.so issue by manually building the module lpsolve, but I have no idea about the other two. Where does libsolver680li.so and come solver680en-US.res from? Any help appreciated, thanks. -- Kind Regards, Giuseppe Castagno Acca Esse http://www.acca-esse.eu [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Butler Office Pro - really a violation ?
On Fri, 2008-02-08 at 17:51 +0100, Juergen Schmidt wrote: The project simply don't need people like you who has probably never contributed one line of code but are very good in this kind of useless discussion. I must of missed this email (I did notice Michael's reply), but really, I don't care if you like me or not, and I don't care whether you personally consider this discussion to be useless or not. First of all, many people make many contributions other than code. This includes bug reports, documentation, marketing and community support. I won't bother to list all the possible avenues for contribution because if you are so myopic as to make a statement like that I will not waste my time. In addition, as I very clearly stated, any contribution I could make has been refused by the project. As soon as the licensing issues are worked out, and the project is willing to accept code licensed only under the LGPL, then I would be willing to make contributions. I will not be signing the JCA, or SCA or whatever the name du-jour happens to be. I'm sure I'm not the only developer who feels this way. Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
