Re: [dev] Passive UNO Component Registration
Stephan Bergmann wrote: I am currently working on a new, passive way to register UNO components Yay for that!! It was about time ... ;) (While, strictly speaking, this is UNO specific and should thus go to d...@udk.openoffice.org, I consider its consequences for all of OOo important enough to warrant this wider distribution.) Quite. Thanks a lot for going after that, -- Thorsten pgpO4VGWZgS2M.pgp Description: PGP signature
[dev] --== OpenOffice.org HackFest ==--
Dear OOo hackers, the OOoCon just ended, and we realize how little time we can spend together face2face each year. To properly fix that problem, we hereby announce the next event around OpenOffice.org - a hackfest in Hamburg, specifically targeted to developers, to give all of us more face time collectively work on the code. The OOo Hackfest will take place over a weekend (starting Friday night with some opportunity to socialize, and ending Sunday noon), and a tentative program could look like this: Friday night - beer fun, warming up Saturday morning - Intro talks, Hands-on sessions Saturday afternoon/night - collective hacking, bug fixing Sunday morning - wrap-up, review, document For those who are in need for a bursary, we have a limited travel funding budget available. For sleeping, couchsurfing at the organizers is available. Be aware that would be in an unheated loft, so bringing a sleeping mat and a good sleeping bag would be essential. For more comfortable reasonably priced acommodations see http://wiki.services.openoffice.org/wiki/Sleeping_in_Hamburg To give as many people as possible the opportunity to participate, we're offering two dates to select from. If you're interested, we ask you to log your preferred date(s) within one week here: http://www.doodle.com/6agr35kkqyxtnakd Putting your name dates there is no obligation for coming, this is just a poll. Faithfully, your hackfest organizers Eike, Florian Thorsten pgp4lVw6zzQqB.pgp Description: PGP signature
[dev] Re: [ux-discuss] i47600 - action needed
Camille Moulin wrote:
//UNUSED2009-05 void ScDocument::SetPrintRange( SCTAB nTab, const
ScRange rNew )
//UNUSED2009-05 {
//UNUSED2009-05 if (ValidTab(nTab) pTab[nTab])
//UNUSED2009-05 pTab[nTab]-SetPrintRange( rNew );
//UNUSED2009-05 }
Ugh. Why are we still doing _this_ kind of thing? Surely this can be
retrieved from the $DSCM? For git, the 'pickaxe' is the tool du jour
to find commits adding or removing (patterns of) code.
Cheers,
-- Thorsten
pgpDEEcCaYiXz.pgp
Description: PGP signature
Re: [dev] Large source file
Jens-Heiner Rechtien wrote: $ du -sb sdext/source/pdfimport/xpdftest/ 3835812 sdext/source/pdfimport/xpdftest/ The hg storage is already compressed. This buys nothing for the cloning operations, in fact it goes a long way to make it even worse. Hi Heiner, in which way would that make it worse? It adds another 2MB-something to the repo, and removes 73MB from the checkout. I'd consider that a fair deal. ;) (please also consider the fact that this file may change, if someone fixes/updates/adapts xpdfimport - and since the file is ~binary, that'll add more 2MB chunks to the repo, anyway) Cheers, -- Thorsten pgpQ8Il1fhmTg.pgp Description: PGP signature
[dev] Re: OpenOffice.org Product Development (was: Community Council Elections: Introducing the Nominees)
Hi Martin, *, this is in response to your blog post here: http://blogs.sun.com/ratte/entry/openoffice_org_product_development (I'll separately post a blog entry about this, but would prefer discussion on this mailing list) You wrote: The only candidate now for the non-code contributing projects for the next round of council elections will be Thorsten Behrens. he's a well known great supporter of the hacker driven Product Development, from my perspective a good representative of the code contributors. But not for the non-code contributing PD projects of OOo as the charter of the CC states. It's difficult to do a no vote against the only candidate for this seat, especially if the candidate does good things for the project and I consider him as a good friend of mine. But we need a general review of the PD part of the project, and therefore I want to see a person representing the classical school of product development and call for a no-vote and call for new candidates. Martin, so do you really think someone capable of working on the strategic marketing plan will have _more_ time doing so when being a member of the CC? ;) More seriously, and as I wrote in my intro mail, I firmly believe that CC's central function is arbitration - i.e. talking to people, convincing folks, finding compromise. It's decidedly not the place to vote people into, because you need specific jobs A, B, or C done - that's what the different projects are for, for your example the marketing project. My selling point is surely not decades of marketing experience, but rather my ties into the wider community, for which I know very many people in person, and would call quite a few of them friends. I've done QA work on CWS sponsoring a tinderbox, I know a fair bit about the economies strategies in FLOSS communities - and I do my legwork in advertising OOo, e.g. at CeBIT. As stated in my introduction mail, I'm explicitely running for this seat representing projects outside of raw code contribution in the council - in fact, I've always frowned upon the notion of being purely code contributor, qa engineer, or marketer - core to my motivation is my love for this project, that is OOo, and everything that's necessary to further its success. Across all camps. And finally, I find the act of lobbying for a no vote against a CC candidate quite without precedent, even more so since there was not even a single question, neither public nor privately, about my intentions or motivations, let alone a discussion. I can only ask everyone involved to check the facts objectively, and keep up with the tradition of having the CC be a place of collaboration compromise, instead of exclusionism camp mentality. Regards, -- Thorsten pgphh8JNGVzPX.pgp Description: PGP signature
[dev] Re: Community Council Elections: Introducing the Nominees
Christoph Noack wrote: I would like to start - so please answer the following questions: * What is your idea by the work/tasks of the council? Hi Chris, all, so Eike already linked to the definitive, authoritative page about the council charta - to paraphrase, the council is largely a place where arbitration happens, in terms of (interpersonal) conflicts, funds, and overall project interests. Overall, the council has limited powers, so the trick is to be quite persuasive - I'm at least not extremely bad at that. Plus, I'm patient. ;) * Do you have any special areas of interest/ideas? Besides being a code contributor since almost nine years (in areas like gui toolkit, applications, build system filters), a focus on testability code quality, and working in the relevant standardization committees for office file formats, I'm actually passionate about connecting OOo with other free software projects, ideally sharing the work, and code. Events like FOSDEM or LGM are excellent opportunities to connect with other projects, and I make it a priority to attend there. Other than that, I find it very rewarding to mentor people for doing OOo hacking, and have used countless occasions to do so (like GSoC, new hires, and of course education project students). I'm personally convinced that getting pupils and students in touch with FLOSS is the biggest single opportunity we're facing. * Is there enough spare time for the work in the council? I can safely say that most of my spare time goes into OOo already, so this will only shift tasks towards doing less coding/mentoring and more talking/mailing; I've personally no doubts that I'll be able to invest the time over the course of the election period. Apart from that, it seems, since my employer (Novell) endorses my nomination, I might even be able to do this on company time. :) A few words about my person: I work on OOo code since 2001, first for Sun, now sponsored by Novell. I'm a computer scientist by education, and a free software enthusiast by heart. I have two kids, and live close to Hamburg in Germany. My blog: http://blog.thebehrens.net/ My (mostly incoherent) dents: http://identi.ca/thb I was hopefully able to at least convey a rough idea about who I am, but please don't hesitate to ask me for further details, either here, via PM, or on irc. You find me hanging out on channels like #dev.openoffice.org, #education.openoffice.org and #go-oo (all freenode.net). I'm thorsten there. Cheers, -- Thorsten pgpPSCMLpiNqN.pgp Description: PGP signature
Re: [dev] Re: Coding St{andards|yle}
Herbert Duerr wrote:
I think that criticizing old rules that cause problems today by
causing bigger, slower, limited code which introduces extra
maintenance burdens and extra bugs from too tight types and signed-/
unsigned issues is right on topic. Is this not the topic we are
talking about here?
Hi Herbert,
well, again just very slightly missing my point - see below ;)
[...] to permit ints and longs for everything
Who wants that? If you need fixed-width types you need them... but
even then using typedefs or or packing them into classes is often
better.
Anyway, I've stated my points. And I have a lot of experience to
back them up. With that said I'm getting out of this discussion, I
just don't have enough time.
Sorry to hear, maybe someone else is picking this up then - anyway:
so your suggestion is to use the native C ints by default, and
fixed-width types whenever there's a (recognized) need? And forcing
those fixed-width types into actual classes doing overflow,
underflow, and lossy conversion checking in non-pro builds?
If the answer is yes, then I think I have a decidedly bad feeling
about this - somewhat contrasting your experience mentioned above:
_everytime_ someone (preferrably exploiters) is putting integer math
to its limits inside OOo, there are bugs. Tons of them. Because
preventing overflows or truncation is non-trivial, even with fixed
ranges. Getting this right with only weak-relationed native int
sizes is even harder. So my (slightly amended) position on that
would be: iff the native ints are desirable (please scratch that
bigger, slower ... code from the first paragraph - that's truly a
red herring. For 99.9% of OOo's codebase), then let's make sure that
first off this dearly missed what every computer scientist should
know about integer math page is written. ;)
P.S.: case in point - X11 wire protocol:
struct _xPoint { INT16 x, y; };
X11 api:
struct XPoint { short x, y; };
Overflow handling: burdened on the app. Talk about transparency, and
POLS. XPoint being 'int' would have even been ok-ish, from an
abstraction perspective - 'short' is just a misguided attempt to
expose the INT16.
Cheers,
-- Thorsten
pgpWdGq2YUnJZ.pgp
Description: PGP signature
Re: [dev] Re: Coding St{andards|yle}
I wrote: [...] iff the native ints are desirable [...] then let's make sure that first off this dearly missed what every computer scientist should know about integer math page is written. ;) That's of course nonsense. This page needs to be written unconditionally. :) -- Thorsten pgpkvxOkUEPas.pgp Description: PGP signature
Re: [dev] Spanish NL Community requests for funding help on acquiring a local build box
Martin Hollmichel wrote: I think it's an good plan to verify localization (and terminology) as a early as possible.Are there any technical hurdles to import incremental localization updates from pootle and do frequent builds. Can this also easily be done for more languages than Spanish ? What would be your preferred platform for doing this ? From what I've learned in a previous discussion, it's Linux, and it's about getting binaries w/o being able to commit to a cws - as such a very supportable request, I'd be in favor of it. :) Cheers, -- Thorsten pgpQMtVki1mSm.pgp Description: PGP signature
Re: [dev] Call for Nominations for Community Council Seats
Jan Holesovsky wrote: Again, consider nominating yourself or someone equally interesting. We need energetic contributors who understand the Project and have a sense of its dynamic and potential. The world is changing--we know that-- and to make sure it changes for the better, join us on the Council. After having heard the sad news of John's rejection of his nomination to the council, please let me nominate Thorsten Behrens as a Product Development Representative. Hi Kendy, all, first off, let me join you in regretting John not running for a second term, he has set the bar very high for this job. I won't reach the standards he's set, but at least strive to - in a word, I accept and confirm this nomination. Feeling honoured, -- Thorsten pgpr4JtKfsVFO.pgp Description: PGP signature
Re: [dev] Re: Coding St{andards|yle}
Herbert Duerr wrote: With their int equivalents. E.g. svx/inc/svx/svdpage.hxx: sal_uInt16 GetPageNum() const; could be replaced by svx/inc/svx/svdpage.hxx: int GetPageNum() const; And there are a gazillion other methods that can be found using grep sal_.*Int16 */inc/ Of course all these are no high priority else they would have been updated long ago... Hi Herbert, your suggestion shows the fundamental flaw I've pointed out earlier - that too much of the code makes implicit assumptions about the available int ranges. Just grep for 0x, 0xFFFE etc. and weep. Add to that performance implications - the Calc guys can likely tell the story much better than me, how 'simple' increases in row/column sizes affect overall speed. When I look through other high profile multi-platform sources such as gcc, the linux-kernel, etc. they have no problems to use native types for everything except for interfaces defined by their ABI or the API of the underlying platforms. The kernel code presumably gets enough coverage with different int sizes over the range of supported platforms, that such bad code gets weeded out; besides I'm rather certain the kernel code is overall much more defensive than OOo's. gcc is a different league, compiler are usually no target for exploits. Ultimately, most of OOo's internal state stems from external input, and since there's no designed firewalling e.g. around the binary filters, I guess we're better safe than sorry, and not permit this extra dose of platform dependency, for no apparent benefit. Cheers, -- Thorsten pgp3ZSDvoix3d.pgp Description: PGP signature
Re: [dev] Re: Coding St{andards|yle}
Philipp Lohmann wrote: On 3/12/10 2:50 PM, Herbert Duerr wrote: your suggestion shows the fundamental flaw I've pointed out earlier - that too much of the code makes implicit assumptions about the available int ranges. Just grep for 0x, 0xFFFE etc. and weep. The hardcoded range-checks were probably good enough then because of the hardcoded types implied they would be safe forever. Changing any of these signatures now is a lot of work with lots of pain, little gain. That's why it isn't high on anybodies priority list. +1 Hi Philipp, much of what Herbert writes is beside my point - it's not about changing existing code, but about defaults for writing new, or fixing old. It's not whether the current code using fixed size ints is of especially good quality, but whether it would be rather harmful, or rather positive, to permit ints and longs for everything. Ages ago there was a decision to use typedefs like USHORT, ULONG, with apparently a fixed range - those were superseded by the recommendation of the uno types, now in the current coding standards. I still consider this decision valid, as it eliminates a very subtle way of introducing bugs (that are even platform-dependent, something we try hard to avoid in above-the-vcl code) - without any necessary drawbacks except, err, readability. Or should they get some value-add by e.g. in debug mode by them becoming smart classes? With range checks, signed-unsigned checks, cast-checks, etc.? Range checks should be simple. Maybe there is already a generic template library for this? I haven't seen one though. If I had to implement it I'd use type names close to the cstdint typenames and switch the namespace depending on debug-mode or product-mode. +1 You have a point here (and also with the unsigned ints are evil statement). But you'll need (much of) that checking for production code, too, if you say don't need fixed int range, will check for overflow myself. It's just much easier do code static checks at strategic places, if you know exact ranges, and not only weak = relations between types. Yes, I think the C int type system sucks. To this whole thread I can only say: don't we have more pressing problems than to change perfectly valid code to other perfectly valid code which in the best case does the same as before. See above. I was reasoning about coding style. Cheers, -- Thorsten pgpMitIjBFUgz.pgp Description: PGP signature
Re: [dev] Re: Coding St{andards|yle}
Herbert Duerr wrote: And while you are at it also replace the countless methods that still use sal_uInt16 instead of int as return value... goodbye Win3.1! ;-) Replace those methods with what? ;) -- Thorsten pgpq2wmSShlac.pgp Description: PGP signature
[dev] Coding St{andards|yle}
Hi, recently I was idly browsing through commit mails, and noticed two patterns that seem to have gotten into wider usage: * prefix abstract classes with an 'I' - presumably not to make it look as fashionable as an iPhone, but rather to denote it's an 'interface' ;) * use of fundamental types like long and int. Whereas I think the former is quite sensible (also the added SAL_NO_VTABLE), I have some issues with the latter. Are there any reasons _in favor_ of that, except for platform apis the occasional loop counter? I'd therefore like to revisit the OOo coding standards (http://wiki.services.openoffice.org/wiki/Category:Coding_Standards), and ideally merge the non-controversial stuff from http://wiki.services.openoffice.org/wiki/Writer/Code_Conventions with the overall rules. Cheers, -- Thorsten pgpNg4EOapGI8.pgp Description: PGP signature
Re: [dev] Coding St{andards|yle}
Stephan Bergmann wrote: * use of fundamental types like long and int. Whereas I think the former is quite sensible (also the added SAL_NO_VTABLE), I have some issues with the latter. Are there any reasons _in favor_ of that, except for platform apis the occasional loop counter? Yes: different semantics. On the one hand: [bunch of good examples snipped] Hi Stephan, sure, I buy those. Would then be worthwhile to re-def the types you listed in terms of their C/std:: counterparts. Can do that. sal_sChar is indeed unused, sal_uChar not so much (but there should be a trivial 1:1 mapping). Or better even, mass-move things like sal_Size/PtrDiff over to size_t etc. Let me get to the remainder: C++ int is the canonic type to use for integral quantities that are obviously within the guaranteed range of that type. Absent any additional constraints, why complicate things (and, potentially, pessimize the generated code) with using, say, sal_Int32 instead? I wince when I read obviously in this context. I grant you the pessimization argument, that's what I was alluding to with my loop counter example - but still, except for the most simple cases, these have a tendency to later spread their value's usage into surrounding code. Let's stick with the default choice of use the sal_* types, unless there are more convincing arguments. C++ long is the canonic type for integral quantities that are unbounded (i.e., code needs to take care of overflow to outside LONG_MIN--LONG_MAX) but for which plain long is deemed more appropriate than more complex, but more accurate solutions, like arbitrary-precision big-integer classes. Absent any additional constraints, why complicate things with using, say, sal_Int64 instead? (For C99, long long would be the canonic type to use instead.) I think that causes more harm than benefit, and many extra opportunities for subtle platform differences. Make up your mind what range you want to support, and then choose a sal type. Cheers, -- Thorsten pgpSVlNTQFi0i.pgp Description: PGP signature
Re: [dev] Coding St{andards|yle}
Stephan Bergmann wrote: I wince when I read obviously in this context. I grant you the pessimization argument, that's what I was alluding to with my loop counter example - but still, except for the most simple cases, these have a tendency to later spread their value's usage into surrounding code. Let's stick with the default choice of use the sal_* types, unless there are more convincing arguments. Re wincing at obviousness of matching range: How is that any different for plain int (with INT_MIN--INT_MAX range) vs., say, sal_Int32 (with SAL_MIN_INT32--SAL_MAX_INT32 range)? Because it's at least consistently too small (_if_ it is too small). ;) I think that causes more harm than benefit, and many extra opportunities for subtle platform differences. Make up your mind what range you want to support, and then choose a sal type. I see your point here, but am not entirely convinced. Both my paragraphs boil down to defaulting to the Principle of Least Surprise - in terms of algorithmic behaviour, not in terms of speed, I admit. But if I have to choose, I'm personally certain which side to pick (mind you, I'm still talking about general rules to put into coding standards here, not about exceptions). Cheers, -- Thorsten pgp9HidWmCB2V.pgp Description: PGP signature
Re: [dev] boost 1.42
Oliver Bolte wrote: just playing with a VS8.0 build (visual studio 2005), that according to the build guide is still a supported compiler - http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Windows_Build_Requirements I've updated the documentation sigh. well, that's also a way to deal with it. because I really recommend to use the VS 2008 compiler. any reasons except the problem I mentioned? Thanks, -- Thorsten pgpaMNHqfqAFb.pgp Description: PGP signature
Re: [dev] boost 1.42
Frank Schoenheit, Sun Microsystems Germany wrote: If you really want to upgrade this, please do not again introduce a platform dependency (or even compiler version dependency). Boost versions were a mess before we went to 1.39, please let's keep the clean one version for all state. Gotcha. -- Thorsten pgpnGiXY33wSN.pgp Description: PGP signature
[dev] Re: VS 2005 support (was: boost 1.42)
Oliver Bolte wrote: AFAIK you can't download VS 2005 Express anymore. The build for the 64 bit shell extension will probably fail, but I haven't used VS 2005 since years... Ok, thanks for the update there - nah, I think the shell xt is properly guarded with BUILD_X64, at least I did not hit any problems. So I finished a build with that compiler, with the boost upgrade being the most substantial change necessary. Given that we historically did not axe support for compilers just because, but only for reasons like inordinate effort, or insufficient 3rd party lib support, I'd vote for putting it back in as a supported compiler. Then again, _personally_, I'd not be completely inconvenienced to solely use VS2008, it's just that there's a slightly different set of warnings, slightly better chance of detecting compatibility/idiomatic problems in win32-only code, and of course the thing with the moz build, that speaks for keeping it. Cheers, -- Thorsten pgpkZh648GkRg.pgp Description: PGP signature
[dev] boost 1.42
Hi, just playing with a VS8.0 build (visual studio 2005), that according to the build guide is still a supported compiler - http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Windows_Build_Requirements Only that it's falling flat on its face with boost 1.39; upgrading gets me a reasonably smooth ride. Should we upgrade wholesale to 1.42, or only windows (or even only the 14.00.* compiler)? Cheers, -- Thorsten pgptNfci5raFy.pgp Description: PGP signature
Re: [dev] Should assertions abort?
Mathias Bauer wrote: The idea is the unification of pro and non-pro build. We have discussed that only as an idea to save time in release engineering and a nice opportunity for additional diagnostic abilities for customer problems, but maybe it can help in our current discussion also. Please don't. stlport_debug mode has found so many serious (and potentially serious, wrt. later code rework) errors, that I don't want to miss it. Additionally, I have code in place for non-pro builds that does similar expensive (in terms of runtime space) checks. If the build size/time is the problem, fix the root cause (which you, personally, are already doing ;)). Cheers, -- Thorsten pgpQebLE8lUh8.pgp Description: PGP signature
Re: [dev] Committing masterfixes directly to DEV300? [was: [gsl-issues] [Issue 108160] cairocanvas no longer builds in m69]
Mathias Bauer wrote: Just to give that discussion a good ending: master fixes we be pushed to DEV300 in the future. That was already planned to happen. But the people doing the last builds obviously haven't been aware of that, so it wasn't done. Thx for the update, that the outcome much appreciated! -- Thorsten pgpcBJWdxOmgH.pgp Description: PGP signature
Re: [dev] Committing masterfixes directly to DEV300? [was: [gsl-issues] [Issue 108160] cairocanvas no longer builds in m69]
Stephan Bergmann wrote: no, the decision was to put only final milestone builds to hg.services.openoffice.org/DEV300. I think I remember there was some announcement to handle masterfixes differently, but cannot find it. Anyway, would it not make more sense to commit masterfixes directly on the master, in between commits of completed milestones? That way, CWS that are hit by the masterfixed problem could easily be updated. Indeedly. Committing to DEV300_next defeats the whole purpose of masterfixes, namely fixing the build for the people out there. Using the next master milestone, one could simply setup a quickfix CWS, and following the normal CWS processes. Masterfixes were specifically designed to be _exemptions_ from the CWS process. Cheers, -- Thorsten pgp63ntTLs4nT.pgp Description: PGP signature
Re: [dev] DEV300_m69: canvas/source/cairo/cairo_canvashelper.cxx build breaker
Ariel Constenla-Haile wrote: besides the warning, the error is that the first parameter of doPolyPolygonImplementation() is of type ::basegfx::B2DPolyPolygon http://svn.services.openoffice.org/opengrok/xref/DEV300_m69/canvas/source/cairo/cairo_canvashelper.cxx#848 but in void cairocanvas::CanvasHelper::doPolyPolygonPath() http://svn.services.openoffice.org/opengrok/xref/DEV300_m69/canvas/source/cairo/cairo_canvashelper.cxx#993 doPolyPolygonImplementation() is invoked with a ::basegfx::B2DPolygon, aEdge To go ahead with the build I created a B2DPolyPolygon out of aEdge, and invoked doPolyPolygonImplementation() with it ( ::basegfx::B2DPolyPolygon has a constructor http://svn.services.openoffice.org/opengrok/xref/DEV300_m69/basegfx/inc/basegfx/polygon/b2dpolypolygon.hxx#62 for this) but I know nothing about this code, so I have no idea if it will work... it just let me go on building... Sounds good, let me checkout m69 have a deeper look. Problem here is, Hamburg does not build that code, so code changes in other places may not be taken care of there. Cheers, -- Thorsten pgpNRtuAdlQMM.pgp Description: PGP signature
Re: [dev] DEV300_m69: canvas/source/cairo/cairo_canvashelper.cxx build breaker
Ariel Constenla-Haile wrote: Sounds good, let me checkout m69 have a deeper look. Problem here is, Hamburg does not build that code, so code changes in other places may not be taken care of there. I was wondering how the * do they build without breaking the build! so, do the Linux Dev. Snapshots (for example, DEV300_m69 released today) nor common releases come with no Cairo canvas? I have to correct my previous statement, there are deliberate changes in canvas/source/cairo that fix an actual bug; but apparently the master builds have not been done with enabled cairocanvas. Let's handle the details in issue http://www.openoffice.org/issues/show_bug.cgi?id=108160 Cheers, -- Thorsten pgpLVJ06ULmqL.pgp Description: PGP signature
Re: [dev] patch submission page for new modules
Caolán McNamara wrote: animations - ? cairo - ? Put my name next to those. New rev. committed. -- Thorsten pgp0G36VYgXJG.pgp Description: PGP signature
Re: [dev] Re: Library requirements (freetype2 = 2.0 ) not met . . .
Michael Stahl wrote: What more curl(ing) stuff do I need? uhm, there really is a very simple rule for this: if configure complains that it cannot find the foo library, and you see that you have a libfooN package installed, then you should install a package that (on debian or derived distros) is either named libfoo-dev or libfooN-dev. that rule should apply at least 95% of the time. Heh. I wonder why people with virtually no build-stuff-on-linux experience actually choose OOo as their very first project, likely one of the hardest picks one could make. Maybe a disclaimer like: if you've never built stuff on Linux, please start with easy project Foo, build instructions at Bah should be added to the build guide? but of course there is also a simpler way: for a lot (but not all) of external libraries, the OOo repository already contains a copy. you can enable those by passing --without-system-libs to configure. I wouldn't call it simpler, if the general concept of a -dev package is not grokked beforehand. Cheers, -- Thorsten Java isn't platform independent; it is a platform. -- Stroustrup pgpFDTWDQyqlt.pgp Description: PGP signature
Re: [dev] Re: [OOoCon 2009] OOo4Kids and Education Project : presentations canceled
André Schnabel wrote: well, I guess matters are a bit more complicated here. From past years, it was quite customary to pay travel accomodation for volunteer contributors; in fact the conference submission site mentioned as much. So we seem to have different memories, what was customary. As I remember, last years conference was the first one to have a very generous budget for travel accomodation. This was explicitly mentioned by the main sponsor when the application was sent in. The years before, the reimbursements were much lower and always bound to active community members who really need the reimbursements. But my memory might fail, as I never got full reimbursements for any of the conferences I attended. Hi Andre, nah, your memory seems correct, that's what I remember, too. But I thought the amount was kind of adjusted to the actual need; anyway, was not actually involved in such stuff, so you will know better. Most of the time I payed the full costs myself. (Maybe this makes me one of the evil stupid, who find OOo Conferences interesting enough to go there on their own risk and costs :) ). Oh, count me in with the stupids, too - though I guess there's likely a difference between normal attendance, and speakers (and CC members, FWIW). ;) I guess the ones not being timely in this case were the people deciding/announcing on the reimbursements. Travel/accomodation usually gets noticeable more expensive even 6 weeks before ... Agreed - final rules for reimbursements were given very late. But this does not mean, that you can expect to get reimbursements, as long as no one told something different. Still I think, it is only honest to say I'll join the conference only if I get the reimbursements. This would help to mak decisions and put some pressure on the conference team. Yeah; past years IIRC had this mentioned on the CfP. There is indeed another problem for the Conference Team: OOoCon never had any budget assigned form the OOo project. We used to plan the Conferences as self-sustaining (means every cost related to the conference needs to be backed by dedicated sponsoring). You might imagine, that it was harder to find sponsors this year than any other before. I definitely believe that. But this also cuts the other way around, means community contributors may be more cautious with spending. Budgeting is actually a task of the council - so anybody who is not fine with this, should raise this to the council. Or - much better - apply for a council seat. You'll get the next chance some weeks after the Conference ;) Noted. ;) Cheers, -- Thorsten pgpxQGvhrRu1B.pgp Description: PGP signature
Re: [dev] --enable-lockdown
Mathias Bauer wrote: 2 The gconf backend provides data for configuration set member properties /org.openoffice.Setup/Office/Factories/com.sun.star.XXX.XXXDocument/ooSetupFactoryDefaultFilter, for XXX in Presentation, Spreadsheet, Text. Strictly speaking, this is problematic if some of those components are not installed (like an OOo installation where Impress has deliberately not been installed). The old configmgr implementation probably just ignores those items in such a case. I will need to see how to address that with the new configmgr implementation (see http://wiki.services.openoffice.org/wiki/Performance/Configuration#Platform_Backends for the way I intend to modify those platform backends). IIRC this relates to http://qa.openoffice.org/issues/show_bug.cgi?id=53781 So yes, looks like dead code. Hi Mathias, are you sure you're not referring to the wrong item? To me, issue 53781 looks like dealing with the DisableUICustomization part, not the factory default filters? Regarding that DisableUICustomization - well, if the disabling of the commands provides the same level of non-configurability, sure, let's get rid of it. Of course, as David pointed out, the general lockdown feature in the gconf backend is used out here. Cheers, -- Thorsten signature.asc Description: Digital signature
Re: [dev] Dropping tcsh support for Mac (all?) / changing configure's default
Stephan Bergmann wrote: But what about defaulting to the current login shell? People who might want tcsh already might use it as login shell I would vote for getting rid of tcsh-support in the build environment completely, sooner or later. Making the shell used within the build default to bash is a move in that direction, while making it depend on $SHELL is not. I wholeheartedly agree with Stephan. tcsh sucks large rocks, e.g. when it comes to output redirection; and the build system is complex enough supporting _one_ shell already ... Cheers, -- Thorsten signature.asc Description: Digital signature
[dev] Re: [qa-dev] Looking for QA-Rep for cws cloph13 - create backwards compatible builds for Mac by using the developer-sdk during compilation
Christian Lohmaier wrote: (i.e. if you have a MAC OSX 10.4 and can check the installset, or if you can verify the code changes by themselves,...) Hi Christian, can test-drive the installset do the code review; likely no time though for a proper testtool or tcm qa though. HTH, -- Thorsten signature.asc Description: Digital signature
[dev] Re: [tools-tinderbox] Moving to bost 1.3?
[Cc to tinderbox removed] Frank Schönheit - Sun Microsystems Germany wrote: As an additional note, it has been suggested to not commit the boost*.tar.gz to boost/download, but make it a pre-requisite which needs to be downloaded before building. This would (for 1.39) save 50M in the repository for every version ever committed there. Opinions on this plan are also welcome. Hi Frank, hm - in the light of heavy-weight commits like the .sdf one, ain't this just a micro-optimisation? Unless such stuff gets downloaded automagically, it's a big nuisance in the already-full-of-nuisances ooo build experience. Or invent a nice solution that does auto-downloads, and switch a few other huge external libs to that (like icu). ;) Just my 2c, -- Thorsten signature.asc Description: Digital signature
Re: [dev] Re: [tools-tinderbox] Moving to bost 1.3?
Rene Engelhard wrote: On Wed, Aug 19, 2009 at 04:53:28PM +0200, Jens-Heiner Rechtien wrote: Or invent a nice solution that does auto-downloads, and switch a few other huge external libs to that (like icu). ;) That would be a problem for some builders unless you don't download it when the file is there... That should go without saying; otherwise every rebuild would re-download the file, probably. For example, for Debian requiring any form of net access on a build is a no-go (and for some libs we have to use the internal versions, and be it sometime, in emergency) And please also think on people bulding somewhere without net access.. I think this is basically the same requirement Hamburg RelEng would have, so maybe some envvar like OOO_PREREQ_CACHEDIR would do? Cheers, -- Thorsten signature.asc Description: Digital signature
Re: [dev] Re: Build Comments
Bjoern Michaelsen wrote: Ok, I will remove the references from to gpc from the Building Guide for current releases. However, the directory external/gpc needs to be removed and configure needs to get rid of related options. Is there a bug for this already or do I need to open a new one? Hi Bjoern, heh, well, beforehand, better check whether indeed tools/source/generic/poly2.cxx does not get HAVE_GPC_H defined for the setsolar env. I'm not aware of an existing bug for the cleanup, please also dump the parts in poly2.cxx then. Cheers, -- Thorsten signature.asc Description: Digital signature
Re: [dev] Build Comments
Niklas Nebel wrote: No trace means it's used: .IF $(WITH_GPC)!=NO Yep (where the relevant part is in the tools/source/generic/makefile.mk). So my memory *did* fail me. ;) -- Thorsten signature.asc Description: Digital signature
Re: [dev] Build Comments
Mathias Bauer wrote: gpc is no longer needed (for a looong time). Are you sure? You are right that OOo can be built without gpc (with the option to disable it), but no developer could tell me if that will create a loss of functionality or not. Kai Ahrens told me that he is going to make sure in 3.2 that gpc is no longer needed. Until then it's unclear to me wether we need it or not. Hi Mathias, all distros I know of are using the non-gpc clipper since ages, I'm not aware of any regressions there. Also, if my memory does not fail me, Hamburg switched to non-gpc for 3.0, at least I don't find any traces of WITH_GPC in solenv anymore. HTH, -- Thorsten signature.asc Description: Digital signature
Re: [dev] Architecture/Process Flow documentation
Del Merritt wrote: Anyway, does anyone care to offer some history as to why both of these architectural pages seem to have fallen quietly by the side? Hi Del, well, you gave the answer to that yourself - it's not automatically generated from the source code thus quickly outdated. I maintain a subset of doxygen-generated documentation pages here http://docs.go-oo.org/ , which in principle could also contain medium- to high-level design documentation (see e.g. http://hci.iwr.uni-heidelberg.de/vigra/doc/vigra/index.html for a different project) - if someone would write it. One of the specific problems of OOo is the fact that so much code is already written, and only a comparatively small fraction gets touched or even written anew per release; so in a commercial setting, there's little short-term incentive to demand proper documentation for the code touched (requesting after-the-fact documentation of the existing, sometimes ages-old code, is even more illusionary). I'm by no means happy about that, and well aware of the fact how much of a barrier of entry this is. Regards, -- Thorsten signature.asc Description: Digital signature
[dev] Thinking about an API deprecation process
Hi *, on the last ESC meeting, we had a little brainstorming about if and how to deprecate OOo API. The 'if' was unanimously agreed upon, for the 'how' we came up with the following thoughts: API deprecation === See http://wiki.services.openoffice.org/w/images/2/2a/Esc-mar-2009-api-deprecation.odp for the kickoff slides -- What we need to do -- Decide on preconditions for change: - API was badly designed (architects/pleads to vote if not concordant) Have a list of 'design smells' here, e.g.: * missing exception specifications - API is unused * implemented but unused (can only be easily verified inside OOo code repo, with some more effort inside extension repo - is that enough?) * not implemented (maybe transitively, i.e. listener interfaces, which are meant for API clients, but don't have code to call them inside OOo) - API implementation is too expensive (referring to both effort performance) (architects/pleads to vote if not concordant) What we mean here is e.g. (hypothetical): * profiling xml import has shown that css::xml::sax::XEntityResolver is horribly inefficient and needs a third argument * after the drawing layer rework, one of the css::drawing interfaces needs an inordinate amount of code to emulate old semantics Decide on constraints: - how many clients does this API have * inside OOo code * (estimated) use outside OOo repo * (estimated) number of implementers not reading interface-announce For the latter two, if (at most) recompile is enough, any number of implementers won't block change. For the latter two, if syntactic changes are required, have architects/pleads majority in favor of change? - how 'bad' is the API really – if bad enough, change anyway? Process of Change - when would change be permitted - every feature release, or only major releases? - deprecate API in advance - one or two features releases before the actual removal. Of course, a replacement needs to be available then? - can/should we add technical barriers/support for detecting stale API usage, i.e. refuse to run such extensions? Should we add technical means to warn devs when using deprecated API (either enabled in debug builds, or in a special logging mode of OOo)? Who decides? - we've referred to the entity finally deciding as architects/pleads here; please consider that a place holder. We'd like to hear sensible proposals here also for that committee, also simply voting on the relevant project mailing list is conceivable, or just having the respective project lead decide. Looking forward to your ideas, Kay, Frank Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [graphics-dev] Re: [dev] New feature Intelligent Group
XiuzhiCheng wrote: Agree. I am sure that we can work together to speed up implement of this nifty feature. Where can we get your source ? We can discuss the the division of labor on this Friday's IRC meeting if we would get your source and anaysis it. Hi Xiuzhi, cool, most of it is in ooo-build, looking forward to discuss this on Friday! Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] New feature Intelligent Group
Liang Weike wrote: Now we're trying our best to implement a new feature temporarily named IntelligentGroup in OOo. It is intended to illustrate user's slide contents with graceful and colorful shape groups. Its function is similar to the function of SmartArt in MS Office 2007. Hi Liang Weike, yep, we talked about that. ;) As announced earlier, I'm playing with a similar feature, see here http://blog.thebehrens.net/2009/03/11/smartart-import-and-more/ for some details. I would seriously hate duplicating that effort, we should therefore find a way to align ideas code; I'm positive that this is possible, apparently we focused on different parts of the implementation. ;) Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Thorsten, you wrote: I do not know, how this can be fastened for all OOo users? Do you have any idea? I would guess a handful of servers can easily cope with the demand a dev snapshot generates, at least within the first 24 hours. No need to have the same requirements there as for a release build. BTW, since there was the request for an automatic solution: anybody knows what became of the mirrorbrain offering (on d...@tools IIRC)? Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Thorsten Ziehm wrote: As we talked in many other threads. Where are the problems for testing a CWS from a BuildBot? You can check fixed, you can test functionality etc. You are perhaps right, that for automated testing with VCLTestTool doesn't show always the same results. But for this the QA team from Sun is working on TestBots. So it isn't needed to adjust the test scripts for all test environment we will find in the community. What do you want more? Builds that reliably represents master builds, I guess. What sense does QAing random builds make? Exaggerating a bit, Mechtilde could then even use a ooo-build-based version for CWS QA, as buildbots also tend to patch a few things (to make the build succeed, usually). Also pointed out before: prerequisite for a testbot is a buildbot that builds Hamburg-compatible CWS. So you need those anyway, why going two steps at once instead of one after another? Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
Thorsten Ziehm wrote: [...] 3. I want to have TestBots - or how ever you want to call it - with defined environment to check each CWS automatically or by manual trigger. On these BuildBots automated testing will run automatically on each CWS. and 6. It is needed to have builds from a defined build environment. Therefore BuildBots have to be defined, with which the automated tests can run stable and without other errors like the ones from Sun internal build environment. If this is a BuildBot like sun internal environment or anything different has to be checked. Hi Thorsten, If this request is not valid - what is the alternative (how would QA community get cws builds?) TestBots should be the solution and I hope until mid of this year we will habe first results. testbots then are the solution for transparent autotesting. As you noted, buildbots with a defined build environment are a precondition to that, and thusly, having that defined build environment be the HH baseline makes perfect sense (otherwise Hamburg-released builds would differ from what has been QAed). So, I'm happy that we agree here. ;) Cheers, -- the other Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Frank Schönheit - Sun Microsystems Germany wrote: (If I had a wish, I'd vote for changing UNO incompatibly, and adding a Stack member to the css.uno.Exception class instead. Oh, well, just dreaming :) Hi Frank, nah, please stick to that, there *must* be something out there that *is* important enough to change UNO incompatibly (and then to sneak in all the other incompatible changes I'm dreaming of)... ;) Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
Mathias Bauer wrote: [let build bots be the 'reference' build system] Is that a wood we could agree on? Or shall we keep the status quo and look on the trees? Hi Mathias, definitely the former. And I like the picture of the forest you paint. :) Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
Gregor Hartmann wrote: another problem or rather a question is: what are Buildbots meant to be good for? Fom when they were introduced they had two tasks to perform 1. Test the build under as many different system configurations as possible. 2. Produce builds which are suitable for QA. Hi Gregor, hm, from my understanding, #1 is the purpose of tinderboxes. That idle buildbots also feed the tinder results is a nice side-effect, but not the main purpose IMHO. Instead, I definitely think #2 is the real thing, concurring with Caolan - allows hackers, QA people interested users to have a look at a CWS *as it would come out of HH when integrated* so the Buildbots seem to rather obey rule #1 now. The question is if we want to neglect this task of the bots in favor of #2 or not. Please. At least for the HH-maintained ones. Probably, for the RedFlag ones, they want to use *their* baseline environment there. Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] buildbot builds vs standard builds
Nils Fuhrmann wrote: I know that there were some issue regarding QA'ing buildbot builds in past. To get an idea what the real problem is, we should collect those issues in detail when they occur to find the root cause for them (as we always do). If those issues still are existent, I would await that this list is already available somewhere (Mechtilde, do you have such list?). Hi Nils, *, I would expect to *always* have subtle (or not so subtle) differences in the build, *as long* as we don't converge to exactly one build system (whatever that might look, not necessarily buildbots). That would be fixing the root cause, in my book. Really, we should investigate into the concrete list of issues before thinking about any additional infrastructure. So if such list of issues is available, I will ask someone of my team to take a look on it. In concur with Andre. I guess it's about using the existing infrastructure properly - why not setup a buildbot with the exact HH Linux buildenv (publish that as a VM/VirtualBox image at the same time), and keep it in sync with internal builds (of course, having RelEng build on that very same machine/setup would nicely ensure that this is the case)? Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Qt as a valid replacement for VCL
Juergen Schmidt wrote: Along that lines, see the work that's happening around dialog auto-layouting and the awt toolkit (http://marketing.openoffice.org/ooocon2008/programme/friday_1470.pdf) we need the layouter, we need it, we need it ... When will it be really usable? Hi Juergen, oh, it's quite usable - though the general answer to that question is of course the usual when it's done, which will be a lot earlier with more people working on that. ;) For more details, and for arbitration of volunteers, Janneke is the one in the know, and on Cc. -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Qt as a valid replacement for VCL
Éric Bischoff wrote: Recoding for qt, gtk, win32, and Cocoa is a serious duplication of efforts. If the purpose for having an abstract layer and porting on so many APIs is PORTABILITY to many operating systems, then this duplication of efforts becomes useless, because Qt is already very portable. If the reason for this effort is strategic INDEPENDANCY towards one library provider, then yes it makes a lot of sense to have abstraction layers in the middle. Hi Eric, definitely the latter, not in the sense of mistrust against the provider, but knowing the fundamental law that only one thing is constant - that things are changing. Quite as Qt appears like a good choice today, vcl's design appeared as a good choice back when the decision was made. And btw, qt and vcl are actually quite similar in their core design, and thus share the same weaknesses, conceptually - they don't use native widgets, but only native look (which is noticeable even today, if you look closely, and is surely not becoming less of a problem, c.f. Apple's deprecation plans...). In this light, I guess wxWidgets would even be the better choice iff we'd want to port against one specific implementation. Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Qt as a valid replacement for VCL
Éric Bischoff wrote: Nokia recently relicensed the Qt library under a triple license : GPL, LGPL, and commercial. Qt is cute, modern, C++, easy to program with, and multiplatform. Wouldn't it be the ideal replacement for VCL, now that LGPL is an option? Hi Eric, why are you following up to my (unrelated) lib unloading mail?! Anyway, besides concerns others have voiced regarding text layout accessibility, changing the underlying toolkit of OOo in the way it is proposed here is the most far-reaching change to the code base I can conceive of, short of changing the implementation language from c++ to managed c++ or somesuch. So that's nothing we should do on a whim - quite the contrary, we should never ever again bind ourselves against the implementation of one specific toolkit, but rather code against an abstract interface. Along that lines, see the work that's happening around dialog auto-layouting and the awt toolkit (http://marketing.openoffice.org/ooocon2008/programme/friday_1470.pdf) Of course, having qt then provide _one_ implementation of that toolkit interface is quite the plan (as having a gtk, Win32 Cocoa one). And the license change definitely helps there. Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Make component unloading possible again on *NIX
Hi,
with the 3.0 Linux baseline being glibc-2.2.3, maybe it's time to
enable dlclose() again in osl_unloadModule()?
From the atexit manpage:
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.
Cheers,
-- Thorsten
diff --git sal/osl/unx/module.c sal/osl/unx/module.c
index 874eb52..89d0869 100644
--- sal/osl/unx/module.c
+++ sal/osl/unx/module.c
@@ -150,12 +150,14 @@ void SAL_CALL osl_unloadModule(oslModule hModule)
if (hModule)
{
#ifndef NO_DL_FUNCTIONS
-#ifndef GCC
-/* gcc (2.9.1 (egcs), 295) registers atexit handlers for
+#ifndef OLD_GLIBC
+/* gcc (starting with 2.9.1 (egcs), 295) registers atexit handlers
for
* static destructors which obviously cannot
* be called after dlclose. A compiler feature. The workaround
for now
* is not to dlclose libraries. Since most of them are closed at
shutdown
- * this does not make that much a difference
+ * this does not make that much a difference.
+ * Since glibc 2.2.3 atexit handlers will be called on
+ * dlclose, when registered from within a shared lib
*/
int nRet = dlclose(hModule);
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Make component unloading possible again on *NIX
On Thu, Jan 08, 2009 at 09:14:35AM +, Caolán McNamara wrote: with the 3.0 Linux baseline being glibc-2.2.3, maybe it's time to enable dlclose() again in osl_unloadModule()? This was #i96683#, but needs to be reassigned to someone. Ah, so the disabling is doubly irrelevant now? At any rate, I have unloading canvas libs work beautifully now (after killing a broken unload implementation in libanimcore), which is a real bonus during debugging - you don't need to restart OOo anymore. Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Make component unloading possible again on *NIX
On Thu, Jan 08, 2009 at 10:53:26AM +0100, Stephan Bergmann wrote: Thorsten, do you want to take over http://qa.openoffice.org/issues/show_bug.cgi?id=96683 (completely dropping the #ifndef and GCC 2 comment)? Otherwise, I could include it in one of my OOo 3.1 CWSs. Hi Stephan, I'd prefer the latter, as I currently don't have any 3.1 CWS in flight. TIA, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Hardware acceleration
On Thu, Dec 25, 2008 at 11:11:19PM +, Caolán McNamara wrote: On Thu, 2008-12-25 at 11:04 +0200, Alan Yaniger wrote: In my build of OOO300_m9, the option: Tools/Options/OpenOffice.org/View/Use Hardware Acceleration does not appear. It does appear in the binary I downloaded from the oo.org webstite. Is there a switch or #define for including this option in the build? Should be basically --enable-cairo for unix platforms IIRC Yep, and --enable-directx for Win32 - a detailed answer went to d...@graphics, where the question appeared first. Cheers, -- Thorsten - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] DEV300_m37 cairo breakers
On Fri, Dec 05, 2008 at 04:46:15AM -0200, Ariel Constenla-Haile wrote: --enable-cairo breaks cairo canvas: build/openoffice/DEV300_m37/solenv/bin/checkdll.sh -L../../unxlngi6/lib -L/build/openoffice/DEV300_m37/solver/300/unxlngi6/lib ../../unxlngi6/lib/check_cairocanvas.uno.so Checking DLL ../../unxlngi6/lib/check_cairocanvas.uno.so ...: ERROR: /build/openoffice/DEV300_m37/solver/300/unxlngi6/lib/libcairo.so.2: undefined symbol: __sync_val_compare_and_swap_4 dmake: Error code 1, while making '../../unxlngi6/lib/cairocanvas.uno.so' Hi Ariel, hm, that *should* work on i586, what exact platform are you on? --enable-cairo --with-system-cairo breaks instsetoo_native because it still checks libcairo.so.2 Please dump the output tree in scp2 rebuild. libcairo2 is guarded with !defined(SYSTEM_CAIRO), but there's no build system dependency on changed environment. none of these breakes happen on DEV300_m36. That's because of CWS cairosource01 - actually, on Linux, I strongly recommend going --with-system-cairo, the self-built one is mainly for Win32 MacOS. HTH, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] I build the OpenOffice.org 3.0 from source code, but the installation path of .deb files is wrong, how could I do?
On Thu, Nov 20, 2008 at 11:59:27AM +0100, Stephan Bergmann wrote: That is not the official OOo source code. The official OOo 3.0 (OOO300m9) source code is only available via CVS, see http://tools.openoffice.org for downloading the source from CVS and more. Hi Stephan, nitpickhm, I guess the wording is somewhat misleading - ooo-build in fact does download this very OOO300m9, extracted from this very CVS repository. I want to avoid the impression that indirection via mirroring makes it somehow less 'official'/nitpick. That said, of course one of ooo-build's purposes is to add patches on top of the 'original' source code (which about every Linux distribution on this earth does, with almost every piece of software). In this case, for Debian, the set of patches applied is more conservative than, let's say, for the go-oo version. In fact, you can use ooo-build with just a very bare-bones set of patches, that basically simply ensures buildability on your specific platform. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Source code for PDF editor extension
On Wed, Nov 19, 2008 at 07:05:25PM +0200, Alan Yaniger wrote: http://framework.openoffice.org/source/browse/framework/filter/source/pdfimport/ which is a directory structure devoid of any source code. Hi Alan, stuff has moved to sdext/source/pdfimport HTH, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOO300_m11 build problem on WindowsXP
On Wed, Oct 29, 2008 at 04:26:05PM +0100, Christian Lins wrote: I recently updated the cygwin installation of the WinXP2 Buildbot, but now it is not able to build OOO300_m11, which imho worked before the update. The error message is: [snip] ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@boost@@A) already defined in directx9canvas.lib(dx_canvashelper.obj) directx9canvas.lib(dx_canvashelper_texturefill.obj) : error LNK2005: class boost::arg1 `anonymous namespace'::_1 ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@boost@@A) already defined in directx9canvas.lib(dx_canvashelper.obj) directx9canvas.lib(dx_canvashelper_texturefill.obj) : error LNK2005: class boost::arg4 `anonymous namespace'::_4 ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@boost@@A) already defined in directx9canvas.lib(dx_canvashelper.obj) directx9canvas.lib(dx_canvashelper_texturefill.obj) : error LNK2005: class boost::arg3 `anonymous namespace'::_3 ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@boost@@A) already defined in directx9canvas.lib(dx_canvashelper.obj) ../../wntmsci11.pro/bin/directx9canvas.uno.dll : fatal error LNK1169: one or more multiply defined symbols found dmake: Error code 2, while making '../../wntmsci11.pro/bin/directx9canvas.uno.dll' Hi Christian, the linker complains about multiple-defined classes in different object files, in an *anonymous namespace* - that appears to be a major mess-up of either compiler, linker, that dreaded def/map/flt mechanism, or a combination thereof. Is dxcanvas the only place this bombs? You might try other canvas/source subdirs, the slideshow module or oox, which also make relatively heavy use of boost. _If_ it's the only place - then maybe checking the SECOND_BUILD parts might have triggered it... HTH, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SELinux selection manager copy/paste problem
On Sat, Oct 25, 2008 at 12:01:42PM -0500, Xavier Toth wrote: I am working on a selection manager for SELinux. In certain copy/paste scenarios this manager pops up a dialog to confirm that the user want to paste the clipboard contents to the requestors window. The problem is that if this dialog is used the paste does work instead I get the text , in oowriter for instance, �### before the user responds to the dialog which then does the SendEvent. If the dialog is not used the text is pasted without issue. This appears be a timing issue related to the delay induced by the dialog. Might well be. See e.g. https://bugzilla.novell.com/show_bug.cgi?id=417839 for a somewhat related problem. Can someone point me at the code that processes the Edit-Paste menu item? I've looked around the code but didn't see anything that I could identify as implementing the ICCCM protocol. On Linux what toolkit does OO use, gtk? It's here: dtrans/source/X11/*. And strictly speaking, OOo has its own toolkit (though using qt/gtk for rendering controls). HTH, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Writer Code Conventions / Cpp Coding Standards
On Mon, Oct 20, 2008 at 01:55:11PM +0200, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: - I like the module organization section, but would add more, like e.g. the convention of building libs one directory up (for Writer), what generally the util prj dirs are for what they should contain. Yes, I would love that too, however my idea of how this is supposed to look like is only vague. Maybe someone from RelEng might step up and add a few lines about how a wellformed module is layed out? +1 - IIRC there's even an old request pending from when we did the coding standards ;) Maybe keeping filenames all-lowercase is a bit anachronistic - but keeping them [a-zA-Z0-9.-] seems still crucial. True. OTOH, for example Subversion has some interesting behaviour with upper/lowercase filenames on Windows (commit svn mv SomeFile.cxx somefile.cxx on unix and update on Windows). I see. But this surely doesn't apply to all-new files, no? (is there an svn bug filed for this already?) - the formatting section is probably the most controversial one (and that's one of the reasons we didn't specify that in the coding standards). Either skip it as well, or at least refrain from catering for tools like lxr (which is obsolete now anyways). The most frequent reader of the code is still you, and your fellow devs (using a proper editor) - strive to make code readable *there*. Well, lets just call them recommendations. If you do not have a stylistic preference on a topic, you could use those for guidance. Ok, then fine with that - except that I'd veto the one-line if-statement (prevents setting a breakpoint there for various frontends), and the non-alignment of statements (proper editors do that en passant, and it's quicker to parse for the eye). [Now you see where it leads, when trying to agree on formatting ;)] I removed the camtrip.org-link. Please feel free to add recommandarions about SAL_NO_VTABLE, SAL_DLLPUBLIC_EXPORT, SAL_DLLPUBLIC_IMPORT and SAL_DLLPRIVATE. Will do - seeing that you're working on it, can you ping me for a handover in private? While it is true that code by one person with any sense of style is perfectly readable, it also true that 200 persons with any sense of style working in the same codebase will lead to documents formatted different every five lines, severely reducing readability. Well, then clue-bat them with the CodingStandard, which you quoted so appropriately in your Naming Conventions section. :) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: testautomation the effects on the CWS process
On Fri, Oct 10, 2008 at 01:39:46PM +0200, Helge Delfs wrote: Am 10.10.08 10:36, Caolán McNamara schrieb: On Fri, 2008-10-10 at 06:50 +0200, Helge Delfs wrote: However you might run these tests by yourself and it is of course acceptable to fix these tests if required. What's the (hopefully one line) way to run these tests myself ? Or is this a work in progress and not for use right now ? You should add module testautomation to your CWS to get the testscripts matching your milestone. All tests to be found in directorys 'required' are required to run on a CWS. Due to issue http://www.openoffice.org/issues/show_bug.cgi?id=93675 currently batch files to run 1 test after another are not added to testautomation but you can use the batch files from HEAD of module qa/qatesttool in CVS A quick-start guide (not finished yet) can be found in wiki to get VCLTesttool configured correctly http://wiki.services.openoffice.org/wiki/VCLTesttool May I suggest a moratorium on enforcing this (at least for community) CWS then, until this is finished? And why can't I simply use the testtool from my build, instead of downloading a prebuilt binary? Maybe I broke the testtool itself with my vcl changes, shouldn't my CWS be tested as one atomic entity? And finally, I will just happily adhere to all of this shut my mouth, if only this would be integrated into the build - why not have another module besides smoketest_native, say autotests_native, that builds all of OOo, installs it like smoketest does, and runs the testtool with the required tests on it? Then running tests on tinderboxen would be a breeze... ;) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Writer Code Conventions / Cpp Coding Standards
On Thu, Oct 09, 2008 at 12:02:46PM +0200, bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: OpenOffice.org has these Coding Standards: http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards As a new member in the writer team I tried to find some additional conventions that are current (good) practice. The results incorporating the feedback from other members of the writer team can be found here: http://wiki.services.openoffice.org/wiki/Writer_Code_Conventions Since the effort to codify some of the conventions tacitly agreed upon was generally well received, I thought I might post it as a inspiration for all OOo devs. Hey Bjoern, I generally like the idea of documenting intra-module coding conventions (as sadly, OOo has quite a range, stylistically, across different modules). That said, as seemingly the listed conventions go beyond existing Writer code (i.e. the parts that suggest refactoring, and the 'general' section), and therefore might have general applicability for the OOo code base, let me point out a few problems: Generally, the list seems fairly parallel to the coding standards, there are places where coding standard items are just repeated or refined (e.g. when to make a header external, namespaces, encapsulation, pimpl) - I would love to have this cross-referenced, or even moved to the 'details' section of the coding standard. This would improve the coding standards digestability, shorten your list, and save people generally aware of the coding standards some reading time. Some misc stuff: - I like the module organization section, but would add more, like e.g. the convention of building libs one directory up (for Writer), what generally the util prj dirs are for what they should contain. Maybe keeping filenames all-lowercase is a bit anachronistic - but keeping them [a-zA-Z0-9.-] seems still crucial. I'd relax the strict .hxx|.h rule a bit, taking udk headers for example, which split templates up into separate declaration definition files - the formatting section is probably the most controversial one (and that's one of the reasons we didn't specify that in the coding standards). Either skip it as well, or at least refrain from catering for tools like lxr (which is obsolete now anyways). The most frequent reader of the code is still you, and your fellow devs (using a proper editor) - strive to make code readable *there*. - in the general section, why the reference to cantrip.org? I fail to see the connection (though deriving virtually from an interface does have its merits). Also, recommending SAL_NO_VTABLE for interfaces seems beneficial. - maybe some words about SAL_DLLPUBLIC_EXPORT/SAL_DLLPUBLIC_IMPORT/ SAL_DLLPRIVATE in the encapsulation part? None of the conventions are obligatory for anybody, of cause, but they might make life a bit easier for all (especially for newcomers). Yes, definitely. And well worth getting Writer (and other modules) closer to this. But I still have mixed emotions about the minutiae of formatting - why not simply referencing http://wiki.services.openoffice.org/wiki/Editor_Emacs for people that use a proper editor, and otherwise acknowledging that code written by people that have *any* sense of style is generally perfectly readable? ;) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] testautomation the effects on the CWS process
Hi Helge, fellow devs, reading this http://blogs.sun.com/GullFOSS/entry/fixing_or_adapting_automated_tests I think the rules (and maybe the hurdles) for CWS have changed substantially, but I cannot seem to find http://wiki.services.openoffice.org/wiki/CWS_Policies updated - so, as a dev, what _specifically_ do I have to do for my CWS now? Run all automated tests after every code change, to notice if they break (or are the tinderboxen running autotests)? Run them all prior to setting Ready for QA state, and calling in a test writer only then? Is it acceptable if I fix the tests myself? Is there a list of tests that _must_ pass, and what kind of functionality do they cover? (this http://blogs.sun.com/GullFOSS/entry/test_code_on_it_s list might contain a few answers, but is IMO still far away from an executable do this, do that, then done explanation) Sorry for being ignorant, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
On Wed, Oct 01, 2008 at 01:00:43PM -0500, drhooo wrote: Does this refer to work that has been completed and is in the CVS or Subversion system, or is it a work in progress in a CWS? Where should one look to learn more about this (and maybe use it)? This is in ooo-build, a build system set of patches around OOo. More on http://go-oo.org/ HTH, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Hi Mathias, you wrote: I think that your blog is a little bit unfair and so I posted a comment. Sorry if it came across like that - I did not mention your name there, as this was not meant as a personal attack, but I was rather challenging this (IMO) wide-spread mind-set the quote so nicely captured. Or more precicely: our problems are grouped objects and form controls that don't support the idea of a 1:n relation between core and layout properly. But we haven't given up. Would be nice to get some support of people in the know (perhaps you?). Although my personal focus would be more on the gsl side of things, I wouldn't rule out the possibility ;) Any more details (maybe off-list)? I would be glad to see my apprehension unjustified. I don't want my statement be understood as a I never would do that because the users won't like it, more like a before I will do that I must have the impression that it can be accepted by the users. Nah. The dilemma I was referring to is that the users will _not_ accept it this year, but two or three years down the road, they'll flock over to those other offerings nevertheless, _despite_ the fact that those are worse than OOo on that metric - because their value network has changed, i.e. all of a sudden the relative importance of e.g. collaboration or ease of use backward compatibility has changed. So while this statement isn't a description of the status quo only, it also isn't a vision. It's just loud thinking about how I could implement my vision. As promised elsewhere in this thread I will present them (or the more general part of it) soon. Looking forward, really. :) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Hi Mathias, you wrote: My personal experience with asking people about possible code sharing quite often was: I don't like UNO, I don't like Windows, I don't like your build system etc. etc. While some of these statements are valid, I always wonder why nobody says: nice idea, how to make it happen and how can I help you. The fixed mind-set isn't on one side only. Definitely. But then, excuse the business metaphor, in a market setting, one usually doesn't blame the buyer for not buying, but the seller for failing to sell - and after all, the seller and the offering is all we (possibly) have influence on. ;) And, as you conceded, convincing other projects to swallow larger subsets of OOo wholesale (as up to now, there are no real independent parts - the smallest piece that makes sense would be build system, boost, stlport, xml2cmp sal, the next one probably already URE - all of which would force the other project into _our_ world, build-system, packaging configuration-wise), when they want to share some bits, is hard to say the least. That said, at least on Linux, Michael did split OOo up into 18 distinct packages, that build on top of each other, and can be independently built installed (and most importantly, one can install debug info only for e.g. Writer) - but that's still OOo, much better packaged, but dragging in the whole stack, if someone links against svx for the Escher filter. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo 2/3 still using gpc?
On Fri, Sep 05, 2008 at 03:49:46PM +0100, Caolán McNamara wrote: Agg is dead for OOo, since it moved to GPL. But is it a dead module ?, canvas still seems to make use of it if agg is not explicitly disabled. Does it profit the vanilla version much to have that old agg in there, i.e. is it worth dropping agg out totally, removing the module and shrinking the vanilla checkout/build/etc down ? The code in canvas using agg is dead (for all that is relevant for OOo). If there are no objections, that can be removed, or at least the configure default changed. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo 2/3 still using gpc?
On Fri, Sep 05, 2008 at 05:31:27PM +0900, Nguyen Vu Hung wrote: It seems that OOo 2.x uses agg ( 2.3 BSD license if I am not mistaken ) Yeah, but that's disabled for ~all builds - at least the Linux distros I know don't build it. agg_conv_gpc.h doesn't use GPC's source code but it claimed to be *BASED* on GPC's algorithm. Can anyone double check that it is OK to use this code in OOo? agg_conv_gpc.h only _uses_ gpc (if it would be there. which it isn't, unless you copied it into the source tree). Agg is dead for OOo, since it moved to GPL. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] scp2 PATCH flags for OOo 3.0.1
On Fri, Aug 22, 2008 at 12:58:18PM +0200, Stephan Bergmann wrote: (Re Windows: If we decide to use Microsoft Installer MSP patches for OOo 3, then for Windows manually set PATCH flags would indeed be unnecessary, as an MSP is computed as the diff of two installation sets. The neat part is that only the different parts of a file are included in an MSP, not the whole file, so that even if there are many false positives---like build time stamps, or mangled names for anonymous C++ namespaces---the resulting MSP will not get excessively large.) Well, if that is acceptable, then why not use makepatchrpm/makedeltarpm on *nix? I really loathe doing those things manually... Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Debugging OOo
On Fri, Aug 15, 2008 at 01:19:52PM +0200, Michael Stahl wrote: please note that symlinking .so files into an installation has never been guaranteed to work. there have always been cases for which this breaks (e.g. dlopening shared objects relying on RPATH), and the three-layer installation has introduced some additional ones... Right. But linkoo does take care of that (via a blacklist). It's actually working like a charm in ooo-build, and I don't want to miss it anymore. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] IRC session on OOo online
On Mon, Jul 14, 2008 at 08:24:42PM +0200, Charles-H. Schulz wrote: Kay Ramme, Louis Suarez-Potts and I would thus like to invite you to an IRC session on Monday 21st, 5pm CET (Hamburg time), 4pm GMT to initiate a discussion on these topics and perhaps go forward on some ideas that could emerge then. Hi Charles, excellent idea - just to clarify, 4pm GMT is 6pm CEST (Hamburg time currently). Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] building and using cairo
On Mon, Jul 07, 2008 at 10:58:19PM +0900, Takashi Ono wrote: The new external module cairo recently included in OOo source tree. I wanted to build and use it in Windows .NET 2008 Express environment as a referece for MinGW porting. However, BUILD_CAIRO environment variable is not handled by config_office/configure. And even if I add it by hand, the build fails. Is it still experimental or shall I raise an issue? Hi, yeah, the whole internal cairo thing is work-in-progress in CWS cairosource01, please use that one for experiments. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Problem With scrolling
On Tue, Jul 01, 2008 at 02:48:27AM -0700, [EMAIL PROTECTED] wrote: Was having a problem with the scrolling functionality where in on scrolling a little vigourously the document text is replicated (ie. beside the original text) which is not expected. This behavior is seen in all the 3 types of documents namely .doc,.ods and .odp. Gentle scrolling or using the scrollbar arrows gives no problem. Hi Karl, have a look at vcl/unx/source/gdi/salgdi2.cxx around line 528, there's a bNeedGraphicsExposures variable - when blitting with a window as the blit source, exposure events are generated to fill the potentially hidden/clipped content. I guess either the events or the processing of them fails somehow. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Proposal: new modules
Hi Pavel, On Sat, Jun 28, 2008 at 10:00:00AM +0200, you wrote: - make cwses with new modules tinderboxable (the work is already in progress) I'm all for it, and this is the most important point - see below. - announce new module (e.g. in cws-announce list) much earlier then integrating it in the milestone or via issue to add alias or add it to the OpenOffice* alias. This could be also automated via EIS - see above. - peer review of new module by someone who at least knows there is also configure based environment or that you can use different shells etc. before the integration of the cws I believe the two last points follow more or less directly from the first one - hopefully, the tinderboxen cover the range of shells, platforms etc. sufficiently. Back to the first point, I was wondering whether maybe tagging new modules with the CWS tag could be helpful - but then again, maybe changing too much of SCM-related things before the switch to svn is a waste of time... Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Trouble compiling DEV300_m19
On Fri, Jun 27, 2008 at 12:28:15PM +0200, Regina Henschel wrote: The build has finished now without further breaks and in first tests the installed program works fine :) Yay! :-) I got a lot of warnings during building, what about them? The last warning is: WARNING! Project(s): swext not found and couldn't be built. Dependencies on that module(s) ignored. Maybe you should correct build lists. You can safely ignore those. Recently, a bunch of optional modules have been added (swext e.g. contains the wiki extension), that for some dubious reasons are not in the OpenOffice2 alias. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Trouble compiling DEV300_m19
On Thu, Jun 26, 2008 at 01:24:42AM +0200, Regina Henschel wrote: I now tried to compile with MSVC Express 9.0, but get d:\softwarearchiv\ooosource300m20\embedserv\source\inc\stdafx.h(21) : fatal error C1083: Cannot open include file: 'atlbase.h': No such file or directory dmake: Error code 2, while making '../../wntmsci12.pro/slo/register.obj' [snip] And I added DISABLE_ALT=TRUE export DISABLE_ALT to winenv.set.sh If you meant that literally, then it's a typo - should be DISABLE_ATL (http://wiki.services.openoffice.org/wiki/Windows#Visual_Studio_2008) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Trouble compiling DEV300_m19
On Fri, Jun 20, 2008 at 10:55:14PM +0200, Regina Henschel wrote: I try to compile DEV300_m19 on WinXP using Visual C++ 2005 Express Edition. That had worked without problems for OOo680m244. But for DEV300_m19 building stops with this message: [snip] What to do? Grab the patch from issue 89973. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Urgent:How to check if gdk API is failiing??
On Thu, Jun 19, 2008 at 01:49:14AM -0700, [EMAIL PROTECTED] wrote: I have checked the Clip regions and there is no problem there.The clip region for the dest drawable seems set correctly. Next,as you said I tried with slides containing two small bitmaps and the animated text and have noticed only a small but important observation. I noticed that in this case on fullscreen the first slide comes up(ie.Only the bitmap as expected) and on a click(ie any user event) the slide is shown completely along with the text.The last time when I had the whole screen covered in a bitmap and animated text, the first slide did not show up the slide on Fullscreen and required a click to show the bitmap and the text. Weird. Some limit in bitmap sizes? I strongly suggest you to publish your code, so that others can review/debug it, this here starts to become wild guessing... Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Urgent:How to check if gdk API is failiing??
On Wed, Jun 18, 2008 at 01:56:17AM -0700, [EMAIL PROTECTED] wrote: I have seen that when i start the slideshow from any slide it works for that slide . Navigating to the other slide during slideshow is failing . Hi Karl, could you please also try whether assigning a slide transition effect to the first slide shows up correctly? What is the flow in following cases : a) When u press F5 on the current sllide Versus b) When u press Page Down on the current slide which is fullscreen Do the flows at a) and b) differ . Not fundamentally. The next slide gets prepared in the background in a second bitmap, so maybe a caching/resource issue on your side? Note that when i navigate the presentation in non-slideshow mode , it works . Do you see any obvious problem , which i am missing . Any pointers from you will help me debug the issue with my bitmap / virtual device code. The non-slideshow mode is using completely different code paths, this does not give much information - to give more specific help, I'd need the code - preferrably a full patch, such that I can debug that in a live office. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Urgent:How to check if gdk API is failiing??
On Wed, Jun 18, 2008 at 06:37:44AM -0700, [EMAIL PROTECTED] wrote: On Wed, Jun 18, 2008 at 01:56:17AM -0700, [EMAIL PROTECTED] wrote: I have seen that when i start the slideshow from any slide it works for that slide . Navigating to the other slide during slideshow is failing . Hi Karl, could you please also try whether assigning a slide transition effect to the first slide shows up correctly? What is the flow in following cases : a) When u press F5 on the current sllide Versus b) When u press Page Down on the current slide which is fullscreen Do the flows at a) and b) differ . Not fundamentally. The next slide gets prepared in the background in a second bitmap, so maybe a caching/resource issue on your side? Note that when i navigate the presentation in non-slideshow mode , it works . Do you see any obvious problem , which i am missing . Any pointers from you will help me debug the issue with my bitmap / virtual device code. The non-slideshow mode is using completely different code paths, this does not give much information - to give more specific help, I'd need the code - preferrably a full patch, such that I can debug that in a live office. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] As u suggested I put a slide transition in the first slide ,but with no succes and it dint show up. :( Also I was just wondering if its really a caching/resource issue on my side, as i came across a situation wherein the slideshow works but wid slight change in the way the user delivers the events. The situation is summarized as follows. 1)I have 3 slides each being bitmaps covering the entire screen and each containing some animation(ie. Some text coming up on a click) 2 (a)On F5,the first slide doesnt show up(ie.No bitmap comes up as in the original slide). However on a click as proposed the 1st slide is displayed correctly(ie.The bitmap as well as the animated text). (b)To move to the next slide ie. on any key press , the first Slide is erased and a black screen comes up.But giving one more click ( this is for the animated text) , the slide comes up with both the bitmap and animated text. (c)this happens in case of all the remaing slides. Hi Karl, yes, this indeed gives some more hints - maybe clipping has issues (in that there are subtle differences in how to interpret empty or no clip), or there's something wrong with timer events, yielding or rescheduling. You might want to single-step in sd/source/ui/slideshow/slideshowimpl.cxx:updateHdl, to verify that there are no differences to the X11 version. Next thing to try: what's the differene if you use normal shapes instead of the slide-sized bitmaps in your example above (and keep the animation)? x-posted to [EMAIL PROTECTED], I'd suggest continuing there. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Urgent:demo applications not building
On Wed, Jun 11, 2008 at 11:00:01PM -0700, [EMAIL PROTECTED] wrote: (gdb) bt [snip] #2 0xb7d6cf51 in uno_type_any_assign () from /2.3.1/OOG680_m9/solver/680/unxlngi6.pro/lib/libuno_cppu.so.3 Hm, that's usually the 3-layer-OOo blues - binaries in dev300 build no longer run without further magic. I tend to copy them into the openoffice.org3.0/program dir of an existing installation, and duplicate the sofficerc file (e.g. into canvasdemorc) HTH, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Urgent:demo applications not building
On Wed, Jun 11, 2008 at 10:29:44AM -0700, [EMAIL PROTECTED] wrote: 1)While building slideshow after adding the rule at the end of the prj/build.lst as follows pe slideshow\test nmake - all pe_test pe_api pe_inc NULL Hi Karl, strictly speaking, this is not necessary - just cd into the test dir, and issue a 'dmake'. A patial dump of the Error is as follows: Making: ../unxlngi6.pro/lib/libtests.so ccache g++ -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,-z,defs -Wl,-rpath,'$ORIGIN' -Wl,--hash-style=both -g -shared -Wl,-O1 -Wl,--version-script ../unxlngi6.pro/misc/export_tests.map -L../unxlngi6.pro/lib -L../lib -L/home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/solenv/unxlngi6/lib -L/home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/solver/680/unxlngi6.pro/lib -L/home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/solenv/unxlngi6/lib -LNO_JAVA_HOME/lib -LNO_JAVA_HOME/jre/lib/i386 -LNO_JAVA_HOME/jre/lib/i386/client -LNO_JAVA_HOME/jre/lib/i386/native_threads [EMAIL PROTECTED]@ ../unxlngi6.pro/slo/views.o ../unxlngi6.pro/slo/slidetest.o ../unxlngi6.pro/slo/testshape.o ../unxlngi6.pro/slo/testview.o ../unxlngi6.pro/slo/tests_version.o -o ../unxlngi6.pro/lib/libtests.so -luno_sal -lbasegfx680li -luno_cppuhelpergcc3 -luno_cppu -lcppunitli -lutl680li -lvcl680li -ldl -lpthread -lm -Wl,-Bdynamic -lstlport_gcc ../unxlngi6.pro/slo/views.o: In function `(anonymous namespace)::UnoViewContainerTest::testContainer()': /home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/slideshow/test/views.cxx:62: undefined reference to `slideshow::internal::UnoViewContainer::UnoViewContainer()' /home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/slideshow/test/views.cxx:65: undefined reference to `slideshow::internal::UnoViewContainer::addView(boost::shared_ptrslideshow::internal::UnoView const)' /home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/slideshow/test/views.cxx:72: undefined reference to `slideshow::internal::UnoViewContainer::dispose()' ../unxlngi6.pro/slo/slidetest.o: In function `LayerManagerTest': /home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/slideshow/test/slidetest.cxx:60: undefined reference to `slideshow::internal::UnoViewContainer::UnoViewContainer()' ../unxlngi6.pro/slo/slidetest.o: In function `(anonymous namespace)::LayerManagerTest::tearDown()': /home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/slideshow/test/slidetest.cxx:85: undefined reference to `slideshow::internal::UnoViewContainer::dispose()' ../unxlngi6.pro/slo/slidetest.o: In function `(anonymous namespace)::LayerManagerTest::setUp()': /home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/slideshow/test/slidetest.cxx:73: undefined reference to `slideshow::internal::UnoViewContainer::addView(boost::shared_ptrslideshow::internal::UnoView const)' No idea what's causing this - tried it on a OOH680_m16, and it just worked. Issuing a 'cvs diff -rOOG680_m9 -rOOH680_m16' in slideshow/test yields insignificant differences, that you still might want to merge, via 'cvs up -dP -kk -jOOG680_m9 -jOOH680_m16' 2)Have added the following line to the prj/build.lst of canvas cv canvas\workben nmake - all cv_test cv_inc NULL See above. Get the following error while building the module Making: ../unxlngi6.pro/obj/canvasdemo.obj ccache g++ -fmessage-length=0 -c -g -O0 -I. -I../unxlngi6.pro/inc/canvasdemo -I../inc -I../inc/pch -I../inc -I../unx/inc -I../unxlngi6.pro/inc -I. -I/home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/solver/680/unxlngi6.pro/inc/stl -I/home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/solver/680/unxlngi6.pro/inc/external -I/home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/solver/680/unxlngi6.pro/inc -I/home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/solenv/unxlngi6/inc -I/home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/solenv/inc -I/home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/res -I/home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/solver/680/unxlngi6.pro/inc/stl -I/home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/solenv/inc/Xp31 -INO_JAVA_HOME/include -INO_JAVA_HOME/include/linux -INO_JAVA_HOME/include/native_threads/include -INONE -I/home/openoffice/OpenOffice-2.3.1-directFB/OOG680_m9/solver/680/unxlngi6.pro/inc/offuh -I. -I../res -I. -pipe -mtune=pentiumpro -fvisibility-inlines-hidden -Wall -Wextra -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor-DLINUX -DUNX -DVCL -DGCC -DC341 -DINTEL -DCVER=C341 -DNPTL -DGLIBC=2 -DX86 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1 -DSUPD=680 -DDEBUG -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=2 -DGUI -DOOG680=OOG680 -fexceptions -fno-enforce-eh-specs -DEXCEPTIONS_ON -o
Re: [dev] Where to find cvs tag for the three-layer patch?
On Wed, May 21, 2008 at 07:00:03PM +0200, Juergen Schmidt wrote: Maybe you can provide some more details about the layout engine test tool. How do you use it and in which context or environment. Hi Jürgen, the relevant stuff resides in toolkit/workben/layout/* As far as i know all this stuff is not upstream and that makes it impossible to take care of such things. This is definitely upstream. I am personally work only on upstream sources, everything else is too much overhead for me and i simply don't do it. Turning this argument around - as this is upstream, could you help out here (you mentioned you're doing similar work for devtools anyway)? Set ENABLE_LAYOUT to TRUE, and IIRC (EIS seems to be currently offline) rebuilding offapi, offuh, transex3 toolkit should be enough. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Helping.......
On Sat, May 17, 2008 at 02:25:21PM -0700, Pat McBride wrote: I have experience in writing databases in dBase III and IV, and in writing user manuals for dBase and Oracle. It's been some time since I did this (1985 to 1991); I was also a Novell CNE from 1996 to 1998, and wrote the MCSE exam for Windows 95 (which I failed by about 5 points). I've been an instructor in Electrical subjects, and served in other instructional fields. I have 5 years experience in the QA field, although it was in mechanical devices there was a fair amount of electrical, electronics, and computer topics that arose. I can also assist users in a help desk format, I have experience on Handymanwire as a moderator, running a panel on electrical subjects. I'm finally retired, and will have time to help out with the project; actually I'm looking forward to it. Hi Pat, welcome to OpenOffice.org - glad that you want to lend a helping hand! For QA work, visit the QA project's portal at http://qa.openoffice.org/ For database stuff, have a look here: http://dba.openoffice.org/ For building, hackinggeneral development howtos, I'd like to refer you to the wiki: http://wiki.services.openoffice.org/wiki/I_want_to_be_an_OpenOffice.org_developer (poster on Cc - Pat, you should consider subscribing to the lists you're posting to, otherwise you might miss answers directed only to the list) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Update: Removing external header guards
On Tue, Apr 01, 2008 at 01:53:21PM +0200, Frank Schönheit - Sun Microsystems Germany wrote: I still hope to be wrong in assuming that this will cost us a lot of work in resyncing, but well ... Hi Frank, all, well, now is the time to check - DEV300_m7 should be almost clean from external header guards. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Update: Removing external header guards
On Tue, Apr 01, 2008 at 10:39:33PM +0200, Thorsten Behrens wrote: Done with the first two rounds of guard removals. Linux builds cleanly, I'm currently doing Win32 Aqua builds. Win32 Aqua now clean as well. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Update: Removing external header guards
On Wed, Apr 02, 2008 at 09:16:21AM +0200, Stephan Bergmann wrote: But why is rtl/string.hxx not visible to the script? Do occurences of external guards around including rtl/string.hxx (and others?) need to be removed manually? No. Please check the file again. ;-) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Update: Removing external header guards
Hi, as the license change for 3.0 will touch ~every file anyway, we decided it to be advantageous to do that jointly with the incguards removal. Both is currently happening in CWS changefileheader. 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. Frank, are your objections still valid? Currently, I plan to leave the following modules out: - external stuff - binfilter - dbaccess Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Update: Removing external header guards
On Tue, Apr 01, 2008 at 01:53:21PM +0200, Frank Schönheit - Sun Microsystems Germany wrote: I still hope to be wrong in assuming that this will cost us a lot of work in resyncing, but well ... My CWS which did the most changes in this area is meanwhile integrated, the other open CWS'es don't touch that much of the includes, so go ahead With dbaccess as well? -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Update: Removing external header guards
On Tue, Apr 01, 2008 at 03:21:01PM +0200, Stephan Bergmann wrote: Is your tooling defective? Why is the external header around rtl/string.hxx not removed below? Nope. The script first collects all headers, extracts the header guards from it, and then removes those guards in all files where they externally guard the corresponding include statements. Following from that, - typos are not removed - headers that are not visible to the script are not considered at all Your case fits in the latter category (I've been a bit conservative in the first strip run). There will be more changes, am currently trying to capture the most prominent typos as well. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Update: Removing external header guards
On Tue, Apr 01, 2008 at 12:06:39PM +0200, Thorsten Behrens wrote: as the license change for 3.0 will touch ~every file anyway, we decided it to be advantageous to do that jointly with the incguards removal. Both is currently happening in CWS changefileheader. Done with the first two rounds of guard removals. Linux builds cleanly, I'm currently doing Win32 Aqua builds. There's been quite some (semi-)manual work needed, as the script only removes _correct_ header guards (i.e. where the macro name in the header matches that at the inclusion place) - I surely did not remove every instance of those misspelled cases. So, if someone (in Hamburg, preferrably, as Rudiger will have checkouts readily available) wants to have a look at his or her project and remove some more bogus guards, I'd say _now_ is the time - please coordinate with Rudiger, we want to provide install sets ASAP. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] drop configimport?
On Fri, Mar 28, 2008 at 09:55:39AM +0100, Stephan Bergmann wrote: Are there any objections against dropping the configimport tool from OOo 3.0? It seems that its typical uses (if any) can also be achieved with other means [...] Hi Stephan, while I don't think you can get away with simply copying files, it's true that there are other mechanisms to achieve config import - e.g. the xcu fragments one can put into oxts. So, yep, sounds reasonable to drop it. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] I'm new
On Thu, Mar 20, 2008 at 01:17:35PM -0700, Kevin wrote: Hi. My name is Kevin. I am a c++ programmer and I am happy to contribute to this project! I am signed up on openoffice.org as kjsisco1984 I hope to learn from you all...and perhaps you will learn from me as well. Hi Kevin, welcome to the project! If you'd like to hack on OOo, you might want to start from this page: http://wiki.services.openoffice.org/wiki/I_want_to_be_an_OpenOffice.org_developer Have fun, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo porting to DirectFB
On Wed, Mar 19, 2008 at 08:56:12PM -0700, Travis Athougies wrote: I may be wrong, but doesn't GTK have its own DirectFB port, why can't you use that instead of reinventing the box? Because, as the OP already mentioned, VCL uses X11 calls directly, even with the GTK plugin. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Cairo Canvas build error due to x11_extensions/inc/Xrender.h
On Tue, Mar 18, 2008 at 03:42:06PM -0300, Ariel Constenla-Haile wrote: Anyway I downloaded the OOH680_m12 sources packaged by OpenOffice.org. Shouldn't they provide up-to-date stuff, not something that will brake your build? --with-system-xrender-headers is your friend here. And yes, we should probably really update those headers... ;-) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVG import
On Mon, Mar 17, 2008 at 10:25:38AM +0100, Mathias Bauer wrote: I don't know the complete background of the discussion wrt. rendering of vector graphics, so most probably you are completely right from a technical POV. But OTOH - what does that mean for the SVG import? How many years of development will it take to prepare OOo in the way you want it before we can have an SVG graphic filter? Hi Mathias, there ain't much missing, see for example the EMF+ work, which tunnels the original file through svm via a comment action, and then renders via XCanvas. Being able to insert SVG graphics into text documents like you can do with pixel graphics nowadays is a very often required feature. I'm sure that most people that voted for SVG import had this feature in mind and not the document import filter. Given the the low percentage of users that use Draw at all (compared to Writer, Calc and Impress) this sounds quite reasonable. That question should probably be asked directly in the issue. And then, implementing another SVG renderer (admittedly to a different graphics API) seemed a bit redundant to me - there a some, and e.g. librsvg (LGPL) could be used to render a pixmap of the right size on-demand. So if my assumption is right - do we plan for user requirements or for technical elegance? Heh - I would hope for both! ;-) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] SVG import (was: [dev] Contibuting)
On Thu, Mar 13, 2008 at 04:54:33PM +0100, Mathias Bauer wrote: I think going for the document filter is a pity. I think we need a graphics filter much more than a document filter as people want to use SVG in the gallery. Or do you plan to extend the gallery to be able to contain drawing documents that will be inserted as OLE objects? Hi Mathias, well, the gallery does already contain draw shapes, used e.g. for ppt import custom shapes. Apart from that, you're right, a SVG graphic filter would be nice as well. But there are a few reasons why I don't think it's the right time to do that now. First off, as you know, I'm not happy with svm as the common grounds for vector graphics, I'd rather render the corresponding document directly to the target surface (at least I would do so for any new filter). But which interface to use for rendering? Naturally, I'd pick XCanvas, but that's currently a bit extended, and to really benefit from it for SVG, would need some work at least at the vclcanvas side of things. So, I kind of punted that for now - a stop-gap solution, that would also be quite useful in other cases (and easy to add), would be a conversion service, that transforms an odf document to svm. xposted; fup2 [EMAIL PROTECTED], please. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Contibuting
On Wed, Mar 12, 2008 at 10:49:24AM +0100, Mathias Bauer wrote: Is it the SVG import you are interested in? AFAIK Thorsten Behrens announced that he wanted to work on SVG import, but perhaps with a different goal. IIRC he wanted to implement a graphics filter, not a document filter, that would enable to embed SVG files into any OOo document. This kind of filters must be implemented in C++ as no infrastructure is available to support XML technology in our Graphics objects. Well, no, it's actually a document filter. Perhaps this graphics filter might be fine with supporting only an SVG subset (Tiny SVG), as probably our Graphics objects don't support more than that anyway. This would leave room for another SVG document filter that imports from SVG to Drawing ODF as much as possible. I think that's almost impossible using pure xslt. The subset of SVG OOo supports (well, it's actually just a subset of the entities, not necessarily the semantics) is too small, and the amount of processing too big for this conversion to be of any fidelity. But depending on the requirements, any transformation might be better than no transformation - and clearly, having svg-odf xslt can be useful in a web server context e.g. So, Ray, knowing the limits, your offer is surely welcome! Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] soffice.bin crash when start up and return value is 78
On Thu, Mar 06, 2008 at 10:52:22PM -0500, Zongyun Lai wrote: However, when I want to launch the application, I do the following operations, and it crashes, $ . LinuxX86Env.Set.sh $ cd solver/680/unxlngi6.pro/bin/ $ ./soffice.bin -impress (.. a quick splash screen, then crash, can't even see what it is...) $ echo $? 78 As you found out, OOo needs to be installed for proper operation - you can kind of make the build do that for you, by setting PKGFORMAT=installed. Then, instsetoo_native/yourplatform/OpenOffice/installed/... will contain a ready-made OOo installation. Even easier is using ooo-build (http://wiki.services.openoffice.org/wiki/Ooo-build), that's a build system set of patches around OOo, that basically makes building a ./configure ./download (to grab build prerequisites) make ooinstall -l target_dir So, could anyone give me some hints for this weird situation? Why can't I just launch applications in solver/680/unxlngi6.pro/bin/ directdory? I have googled the problem, some article suggest setting OOO_FORCE_DESKTOP=none, but it is of no use. So, if I have to install those packages after each modifications, it is very inconvenient for testing and debugging. True. Usually people manually copy libraries from solver to installation to avoid this situation - ooo-build's ooinstall conveniently integrates a script that symlinks solver installation, so that's taken care of there (vanilla OOo's version of that script is currently broken). HTH, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: soffice.bin crash when start up and return value is 78
On Fri, Mar 07, 2008 at 12:24:26PM -0500, Zongyun Lai wrote: By the way, since I only want to hack some new features for Impress, is there any way I can check out and compile codes only for Impress? I knew the concept of 'solver' from http://www.openoffice.org/dev_docs/source/solver.html, which seems just what I want. This didn't really work for Linux - too much variation in libs, compiler, compile-time options, etc. And it would be a large chunk to download... ...besides, debugging in an OOo application sometimes has the tendency to drag you into lower levels quickly - you'll then be happy you have all the code. ;-) Is there any smart way to avoid downloading all the source tree? No, everything else is less smart. And likely bigger than the sources. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
