Re: [dev] Re: Grand Concept, splitting up the monolith, dynamic content
Hi Mathias, On Tue, 2008-09-30 at 18:03 +0200, Mathias Bauer 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. Well, it's clear we need to go out and evangelise. This is the difference between passive and pro-active :-) There are also more telling issues such as control, ownership, timeline RCS of shared code that tend to be problematic - but that aside ... one of the first things I tried to work on (back in 2001) was using autotools for sal / cppu etc. such that we could re-use UNO elsewhere in the Gnome desktop: that met with resounding loathing from the build.pl / dmake lovers - and was one of the things that killed that co-operation (AFAIR). [ and I was doing the work and trying to contribute it (even in parallel with dmake foo) ]. Strangely, not the first time that our passion for our (frankly unbelievable) build-system has substantially hindered useful co-operation with others ;-) Ultimately, if we want to evangelise our technology it is necessary to meet the other people where they are, listen to their problems and adapt to them. Technologies that don't do that fail in the long term. Of course, there is a lot for others to dislike in UNO - the UCS-2/UTF-16 Win32 heritage of all strings, the appalling intrinsic threading / granularity problems ( un-addressed by apartments ), and so on: but at least it should be a no-brainer to share non-UNO-using pieces of the infrastructure. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [council-discuss] Re: [discuss] Suggestions for a new Community Council structure
Hi Andre, On Wed, 2008-06-04 at 15:25 +0200, Andre Schnabel wrote: The council in it's current structure seems very centralistic to me (it's almost built around the project leads). Sure, it's a problem wrt. generating interest and participation. Anyway - it would need time to discuss some rules who should be eligible. An we surely should discuss this. Do you have a personal time-line, or estimate of when you would want that to yield a result ? 1 month ? 6 months ? 1 year ? 3 years ? ;-) But next council elections are overdue, for more than a year now (if not two). So we really should go on with new elections. Well, IMHO the fact that the elections have not happened for years at a time in the past, and that the structure is agreed by virtually everyone (that speaks up) to be sub-optimal, surely suggests that now is a great time to re-invigorate the council structures before the next election. What greater legacy can the out-going members give, than a more open, interesting and accountable structure for OpenOffice ? ie. do we really need to delay ? ;-) Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCL UI Rework
On Wed, 2008-05-14 at 13:15 +0200, Christian Lippka wrote: Michael Meeks wrote: There was some resistance to nominating this for 3.0 because ChristianL wanted to re-do the translation work to use Java Properties instead of the new transex tool we wrote that translated complete XML files per-lang. Ah ! - finally I see your reply while looking for something else in the archives ;-) [ a CC is most appreciated when using the collab-lists ]. This is bogus, I discussed with Jan that in my opinion it is a cleaner solution to use the Java Properties file for translation as I think the current way of doing it does not fit with the OOo translation database and tooling. I wanted to look into it but never said this would be a stopper for this cws. Oh; sorry - presumably I'm confused: but AFAIR there was a concern about the translation mechanism that held things up. I too like the Java properties (a bit) now I think about them - but, OTOH - I didn't like them a while back I can't remember why ;-) sadly that is all the state I kept. Nevertheless - I think Java Properties is the direction we want to go in now. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCL UI Rework
Hi Jurgen, On Fri, 2008-05-16 at 10:12 +0200, Juergen Schmidt wrote: whatever we will use in the future it will be important that we will have a GUI editor to make the design of new dialogs much more easier than today. Yep; absolutely - it's in the spec. and we have a quarter-functioning one already ;-) Ideally a replacement for the basic dialog editor and make it more general for internal development as well as extension development (includes Basic as it does today). Sure - ideally :-) I think it is important to concentrate on one format everywhere and consolidate the different formats that we have today over time. Well - I read the xmlscript code at some considerable length, and also the toolkit/ 'model' code too - and we tried to work with that to start with: we came to the conclusion after burning quite a while, that writing something simple clean was much easier with a containment hierarchy did something new. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCL UI Rework
Hi Kay, On Wed, 2008-05-14 at 11:42 +0200, Kay Ramme wrote: does anybody know what the state and plans regarding the VCL UI Rework (see http://wiki.services.openoffice.org/wiki/VCL_UI_Rework) project are? As we need to do something to improve our GUI, this seems to be a good step into the right direction ... Sure - so Jan is working on this full time - modulo having just had a baby taking some time off for that. Oh - and also, having been somewhat shipwrecked by the problems of bootstrapping new-3.0 split-up-OO.o enough to get the editor / tests working again in 3.0 [ a bottomless time sink no doubt based on my experience making it work in the 1st place ]. Anyhow in the absence of Jan who can give you a live update (janneke on #go-oo) - currently some version of the layout code is merged into toolkit/ in DEV300 and has been re-factored to fit more snugly within the toolkit structure [ saving some ugliness ]. toolkit/workben/layout has some samples. I believe Jan is working on converting some of the more tricky dialogs - eg. the calc format dialog - and extending the vclcompat API, and creating wrappers for embedding old-style fixed-size VCL widgets inside Layout containers vv. I believe he is doing that work in a CWS 'layoutdialogs' - which is the latest code. There was some resistance to nominating this for 3.0 because ChristianL wanted to re-do the translation work to use Java Properties instead of the new transex tool we wrote that translated complete XML files per-lang. So - in summary; it's going quite nicely - though Jan is away for a bit: and wrt. helping out - perhaps the most useful thing would be to unwind the UNO*3.0* nightmare in the CWS so that toolkit/workben/layout 's 'test' binary will run again; and/or secondarily looking at java property files for translation: which prolly belongs near toolkit/source/layout/import.cxx [ still a not-cleaned-up WIP ]. Oh; and you need to export ENABLE_LAYOUT=TRUE to get that good stuff to build :-) HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [tools-perf] Re: [dev] Benchmarking multiple versions of OOo
On Mon, 2008-04-07 at 14:40 -0600, Andrew Z wrote: What I really want is something like Michael's http://live.gnome.org/iogrind but that just says your app burned up 110,000 bogoios and 90,000,000 bogocpus and every time you run it it says 110,000 bogoios and 90,000,000 bogocups. It doesn't even matter too much if it the ratio is wildly different to the real world as long as it's consistent between runs and reducing measurable bogoios reduces real world work by some amount. I am not a performance guru, but I think not all bogoios are worth the same in practice. For example, see slides 15-16 here So - bogoio's are the right approach; the problem is less getting an accurate simulation, but getting a repeatable simulation :-) of course, accuracy is nice if you can be repeatable; but ... Unfortunately, iogrind doesn't work wonderfully well for threaded applications; but it can be run on OO.o to profile cold-start; and it might even give some useful numbers - particularly now there is a 'warming' feature (so you can simulate eg. gedit first to warm the gtk + / glibc stack (etc.)). The console mode will give you a single 12.35 bogoseconds type number. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] New License and Contributor Agreement
Hi Martin, On Wed, 2008-03-12 at 13:19 +0100, Martin Hollmichel wrote: Also, there are some improvements possible wrt. Section 7 - eg. how does updating modules in external projects (eg. boost under BSD) fit with this clause ? is that something only Sun can do ? [ eg. (hypothetically) how could Fridrich commit an updated version of libwpd ? ]. we're working on a revamp of the external project homepage to give guidelines for all these kind of questions, please stay tuned for a some more couple of days, Well; it's *20* days later, and I'm still unclear what the SCA means here. There are conflicting reports: The licensing FAQ at: http://www.openoffice.org/FAQs/faq-licensing.html Now has a question: How are extensions affected by the new agreement and license? That appears to link to an answer in a different section 'sca11'. That should be 'sca13' I believe. sca13 - mis-spells 'including', and apparently the sense of that, when read with the SCA falls short of what has been reported elsewhere. I must be missing something: where are the guidelines ... as posted by us [Sun] on Openoffice.org as referenced in the SCA ? I assume Sun will follow at least the spirit of the agreement it asks people to sign. Presumably if this was available to read, there would be less concern more clarity around this issue. Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] GoOOoCon2008 / Prague ...
Hi Charles, As always it's entertaining talking with you. On Fri, 2008-03-07 at 16:02 +0100, Charles-H. Schulz wrote: Yes, it is one; I thought it was a community event. While technical discussions are perennial to our project, I don't see the need for segregating the community between hackers and non hackers; As I understand it this is a normal practice for organic communities: eg. the Linux Kernel Summit[1] - has purely technical talks, or say the Gnome Developers Summit[2], or perhaps aKademy (AFAIR originally billed as a developers conference). There are of course a myriad of hack-fests, and other highly technical conferences on many topics everywhere. Are you suggesting that these are fundamentally evil ? that developers meeting to talk, enjoy each others' company, work together and discuss technical detail is bad ? it's not as if we are excluding anyone - just warning ahead of time this will be technical, and our core constituency is hackers. Clearly broader conferences have their place too. every part of our community is legitimate Did I suggest it was not ? Honestly, I'm happy to talk politics[1] vigorously: will you share an hour slot with me for a debate on the future of OpenOffice in Beijing ? I will be more than happy to do so Great; I suggest the Parlimentary debating style[3] and a proposal of the form: Contribution to OpenOffice.org by entities with diverse motivations is a strength not a weakness [ or you can cast it negatively if you wish ]. I'm sure Sun, or someone can provide an impartial speaker to compare it: I'm not sure how well it would go over to a predominantly non native speaking audience, though with slides we might get somewhere: sounds fun. although debating with somebody from Microsoft could have probably sped up things. Nice rhetoric, shame about the mismatch with reality; and what do you want to speed up ? I was thinking of starting with Why I believe Open-Source/Free Software is the disruptive movement of our time - I suspect MS has a different view. Of course, such a debate is possible provided I can get the funding to go there, and I realize that you and I, just like many other contributors, are facing this problem. Book early to save :-) See my first comment: provided that the community as a whole is invited, it is a Regicon, yes. Honestly, substance concerns me far more than branding; do call it what you will; all are welcome - the content will be ~exclusively technical. Regards, Michael. [1] - http://en.wikipedia.org/wiki/Linux_Kernel_Developers_Summit + sadly invitation only, not my preferred approach. [2] - http://live.gnome.org/BostonSummit [3] - http://en.wikipedia.org/wiki/Parliamentary_debate -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] GoOOoCon2008 / Prague ...
Hi Charles, On Thu, 2008-03-06 at 19:39 +0100, Charles-H. Schulz wrote: - it will be 'hackers' only Well, given the content of the talks and company, I'm confident it will be much less interesting to non-hackers, so modulo some really patient people coming, you're prolly right, is that a problem ? - nobody will be able to speak politics (ah, those darned politics and, always pointing out awkward things about your employer! Why do they even exist?) Honestly, I'm happy to talk politics[1] vigorously: will you share an hour slot with me for a debate on the future of OpenOffice in Beijing ? However, I realise that other people are not; in particular our friends among the Sun hackers. Indeed, at the last two ESC meetings, it has been similarly forbidden to discuss so called 'politics', instead focusing on technical issues. which in essence means, that discussions will be managed Sure, self regulated - I agree it sucks at some level, but don't believe for a moment it's for my benefit. - you seem to be ignoring the existence of RegiCons, or regional conferences that work very well. Yep, was unaware of them; on the other hand I want to meet, talk to and drink beer with hackers from all over the place: is that what a RegiCon is ? if so, lets call it a RegiCon. In short, you advertise for a Novell event. Notice that I think a Novell event could be an interesting idea, but, as I wrote above, the way it is being pictured looks problematic to me. Problematic because it tramples on some existing RegiCon ? or that it is primarily focused at developers[2] ? or because it's (as I said) tacked onto the end of an existing Novell event, or becuase it's organised by Novell ? or ... ? All the best, Michael. [1] - eg. I'm still waiting for some a reply that appears to have been collateral damage in an unrelated end-thread (though perhaps now moot with the new SCA exemptions, only time will tell): http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=21708 [2] - If the Native-Lang guys want to have their own Native-Lang-contributors-only meetings whether virtual, or real I have no problem with that; why different for developers ? -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] GoOOoCon2008 / Prague ...
Hi guys, The Novell team thought that, what with the next OOoCon being in Beijing and the cost of travel there (etc.) and of course the broad focus of that conference; that it would be good to have a very hacker-focused event in Europe. So, we're inviting all hyper-technical people (with or without long hair) to join the Novell go-oo team for part of their annual team face-to-face in Prague. To re-iterate, this is not an attempt to undermine OOoCon - if you can only afford to go to one conference (money, time, spousal -patience / whatever); go to OOoCon. Having said that, it should be a fun time to sit and chew over the latest developments, problems, and opportunities - while getting to know other people. Conference site: + http://wiki.services.openoffice.org/wiki/GoOOCon_2008 The place: + Prague, beautiful city, home to SUSE labs, an inexpensive place to stay eat The time: + April 11th / 12th The (preliminary) plan: + April 11th, ad-hoc presentations, hacking, evening drinks / meal. + April 12th, am: more of the same pm: fun ropes course / team building + check the wiki as time passes for more details. Getting there: + unfortunately, we can't pay expenses, which is sad. + on the other hand, cheap flights cheap hotels shouldn't bust the bank. We're trying to keep the event small friendly, focusing on hard-core coding, and vcl/source/inc/hardcore.hxx type topics. There is no need to speak, but if you have something you want to talk about, please do show up with some slides, and drop Kendy a line with some idea of what you'd like to say. * There will also be a moratorium on overt politics * Inevitably, this being the .cz republic, unless you are careful, there will be a certain amount of walking through forests, and with the ropes course it's worth bringing some good footwear. Please poke Kendy [ NB. not the mailing list ;- ] if you can come. Thanks for reading, Michael, JP team. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] positive discussion ...
Hi Sophie, Thanks for your mail; I agree - this particular dead-end of the thread got a little unpleasant highly charged; I'm well up for killing it. On Fri, 2008-02-08 at 20:42 +0100, sophie wrote: We are now thinking about SCA, an adapted one to our community, so no need to quarrel about what is already behind. Is there a link to a copy of that somewhere ? (or is the thinking going on on a public mailing list ?). If you really have this energy to argue, please come and discuss how we can reenforce our workflow, our communication flow, our visibility and add more power to our community. I think I'm missing something here. Is there a public statement anywhere that means discussing the unbalanced ownership problems, that (clearly) substantilly impeed Novell's involvement (and that of other developers) is fruitless ? Are you aware of any such statement, or indication from Sun, that says this problem is un-solvable; whatever the community wants ? Of course, such a statement might shut down such discussion pretty quickly, but I havn't seen any clear public statement of that form. Indeed, I've not seen many clear, black white statements about the compromises necessary to accomodate our major sponsor's business interest (which is of course necessary to some degree) inside the project; and what plans there are for the future here. But confidence is a key word in all these discussions to make them come to real facts. So please, really, stop this fight, and allow us to think at something that is reflecting our common love for OOo. So - I think we were getting there - we'd finally got past some of the more basic, emotive, low-level arguments, and were starting to communicate; at least mba I seemed happy: http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=21708 clearly no-one wants to shut down a whole discussion on a topic like this, (and without a conclusion) on the basis of a few sub-threads unfortunately disappearing off into the long grass. I've renamed my reply to remove the odious Butler :-) would be a good move; perhaps as/when we continue other discussions to do the same. Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Butler Office Pro - really a violation ?
Hi Mathias, On Thu, 2008-02-07 at 16:05 +0100, Mathias Bauer wrote: I don't want to kill the thread - I'm not even empowered to do that. :-) Good 'oh :-) personally I think the discussion is helpful. Jurgen is right, of course, that we discussed this 3 months ago, and that there has been no progress in between. That itself is worth noticing - despite the perception of activity improvement created by Advisory Boards and so on. Anyhow, if we can discuss there are a few other bits worth clearing up as well: On Wed, 2008-02-06 at 23:54 +0100, Mathias Bauer wrote: Michael Meeks wrote: Haha :-) I once tried using OpenOffice too, it's user-interface was perfection: no changes welcome. OK, I was just pulling your leg. Sorry for that. Of course, no need to apologise, it was amusing, good to inject some humour :-) Of course you can :-) I spent some time explaining that the vast majority of that code is CA free (I call that eclectic ownership). How much code is CA free doesn't make a difference - This is partially true - but re-applying this back to the interesting case: OO.o - what then is the problem with having CA free plugins included in the product ? :-) - it doesn't change the fact that only Novell is able to licence the whole stuff under proprietary conditions. With regard to our current discussion this is the identical situation as in case of OOo. Not really; lets summarise the differences: the vast majority of the Mono code is eclectic ownership, there is a small (and shrinking) core that is not. Furthermore, there are replacements for the 'core' piece as I understand it: eg. 'Portable.Net' implements their own core, and shares the run-time libraries, or you could use an IKVM type technique to run .Net apps on a JVM (I imagine), and at worst there is the non-free MS runtime. Were Novell to do something truly stupid unreasonable with the core Mono licensing tomorrow, demanding cash / concessions / whatever to ship / use it - there are lots of other options. Now consider OO.o - Sun owns everything, and insists on owning and controlling everything, even cleanly separated components [ included in the product ] (despite as you say) it not really making an immediate difference to Sun's licensing stranglehold. Obviously this leaves a very different situation if Sun decides to do something stupid tomorrow. IMHO, representation should follow contribution, the more you contribute - the more say ownership you should have: that seems only fair. Unfortunately, this is not true of OO.o - and I was hoping for some movement here - AB wise. A trivial and incremental way to achieve this, without hurting Sun's licensing business (in the 1st instance), is (as I outline) - allowing non-Sun-owned components into OO.o, under some suitable license of Sun's choosing etc. It seems fair and extremely reasonable. It is the sheer reasonable-ness of the proposal, combined with it's (apparent) unequivocal rejection by Sun that concerns me most. If a company gave me the opportunity to get some useful open source software and adjust it to my needs I would gladly accept that wonderful opportunity and contribute my code back. That would be my thank you for the huge amount of work that the company already had invested and that gives me a benefit. I know the argument, I used to try to persuade people of this view :-) clearly however gratitude has its limits. It cuts both ways: Novell, and others have contributed substantially to OO.o, yet (apparently) Sun is unwilling to accept a wonderful opportunity to contribute their changes to our code back to (not even Novell of course, but some open transparent foundation). ie. why should the thank-yous appear to only go one-way ? Insinuating a participation of Sun in the case of Butler office really is ridiculous. *That* is the stupid part of the thread I would like to see stopped. Fine :-) it would be silly anyway, now we know it's not so. The rest might still be boring, as it presents the same arguments we heard days, weeks or months ago (and probably we will also hear days, weeks and months later), but that's life. Heh :-) glad you can cope. And as you are doing your own builds anyway where you can include extensions easily - why bother? Well - ultimately, I would like to aim at working within the OpenOffice.org project, and reducing the differences between our builds to a minimum [ and of course, trying to ensure OO.o our users have the latest greatest components / features we work on in their download ]. But as you know, the main problem is that non-inclusion of components, appears to lead to duplication in the core. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED
Re: [dev] Butler Office Pro - really a violation ?
Hi Mathias, So - since you want to kill the thread, lets try to do that; but first I must address this: On Wed, 2008-02-06 at 23:48 +0100, Mathias Bauer wrote: What makes you think it could be anything else? Wow, how easy it is to get some public interest. It's enough to give others some reasons to cultivate their paranoia. How many licensees are there of our code in OO.o, and under what terms ? without knowing that, it's really hard to say; that is my point. Clearly I would hope and expect that (in the absence of a compelling commercial reason to do otherwise), Sun would act in a way to safeguard the OO.o project, ensure that code changes get back up-stream under the LGPL etc. Novell even states explicitly that this is the reason why they ask for a copyright assignment. As does Sun. Whether Novell already does business like that (Michael calls it ripping off people's code) is something I don't care for. It's amazing the concern that is suddenly shown for code that was not written or contributed by Sun, or you, or me :-) I'm interested in the relevant code for this forum: that contributed to OpenOffice; rather than some wider discussion about Java, OpenSolaris, NetBeans [ or whatever ]. Presumably each project can decide for itself. Let me clarify ripping off, since that unfortunately ended up seeming offensive to you. I would personally feel ripped off, if my code ended up in a commercial product, which clearly had modified improved that code, and where the improvements were not available to all under the LGPL, in OO.o. I just would like to stop this stupid discussion started by Michael's ridiculous idea that Sun would make business with a company like butler office. I still can't believe that this is really what he thinks. This would have been an effective end-thread, as a #1 reply :-) Unfortunately, reading back, it looks as if: before Martin checked with the lawyers and confirmed that you did not have such a relationship (thanks Martin), you argument was framed only in defense of Sun's right to re-license our code under any terms :-) It's good to see the principle laid out clearly: that Sun will not deal with Butler-alikes, that it would be ridiculous to do so I welcome that couldn't agree more. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Some thoughts about our community
Hi Mathias, On Wed, 2007-10-10 at 10:47 +0200, Mathias Bauer wrote: I'm sure that he is not naive enough to believe that the rules of the project would be changed in a hurry just because he started his campaign. IMHO it's certainly worth changing the rules to meet contributors legitimate concerns. In a hurry ;-), probably not - but to effectively rule out any change before OO.o 3.0 (Summer 2008) by starting a duplication effort is unfortunate; and shows the likely outcome here. Nobody tries to sell anything. If people don't want to share the copyright with Sun, it's fine. Unfortunately, it's not that fine - since they can't get their code into OpenOffice.org, which totally sucks. Sun's StarOffice is not the reason for the JCA. We could make it even without it as do others with their own proprietary versions. What are the purposes for which the JCA is necessary then ? Which of these purposes are valuable enough to Sun, that a foundation cannot easily fulfil them ? and lets state here that adequate funding for a non-profit to defend the license, perform due diligence etc. should not be an issue. The foundation won't solve anything. It solves a serious transparency trust problem around ownership. But there's another problem. Novell never had any problems with the JCA for years but their contributions to OOo never came close to what you could expect from the number of people they claim to have assigned to OOo. We claim to have 15 people working on OO.o; their names are: Michael Meeks, Radek Doulik, Florian Reuter, Tor Lillqvist, Petr Mladek, Noel Power, Eric Ward, Fong, Jian-Hua, Hubert Figure, Fridrich Strba, Kohei Yoshida, Jon Prior, Zhang Yun (/contract people), Jan Nieuwenhuizen (starting soon), and JP Rosevear (mgmt). Perhaps some of them don't exist :-) to be sure, I've not met all of our Chinese hackers in person. As for not contributing close to what you expect, I am sorry to disappoint you. It is easy (for those who have tried external development on OO.o) to imagine many reasons why that could be. I'm personally pleased with our level of contribution, though as newer engineers slowly get more familiar with the code I expect the level to increase a little :-) And they still refuse to do anything else than hacking code what even more diminishes their contributions. Eric does QA; but yes - we think that focusing on fixing improving the code is a strength, not a weakness. RedHat, whose work we both appreciate, has AFAICS a similar focus on coding. I didn't criticize that nor did anybody else from Sun. But we expect that all people responsible for that move live with the consequences. Including Sun. To pretend that Sun has no choice here is just silly ;-) we both made a choice - I'm happy to defend mine; you seem to deny yours was a choice, though I can understand that it was not you that chose it :-) And I criticized that Kohei left out in his blog that it indeed was shown to Novell how this code could be contributed to OOo without a JCA. As Kohei explained in a comment to my blog, he wasn't aware of this option because those in his company who knew that didn't tell him. This is just silly :-) It is clear Sun that is refusing to include the code, and then doing this hostile duplication. We have all been aware of this plug-in idea, but if this is the answer: why does Sun not simply take the code and make it such a plugin: it should be fairly easy, Sun (or anyone else) is free to do that any time. We want to see our work included with OO.o by default, and ensure there is no demotivating wasteful duplication effort; the exact packaging mechanics: plug-in vs. component, vs. patch are completely irrelevant to my mind. All the best, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Some thoughts about our community
On Thu, 2007-10-11 at 12:53 +0200, Philipp Lohmann wrote: Michael Meeks wrote: We claim to have 15 people working on OO.o; their names are: Michael Meeks, Radek Doulik, Florian Reuter, Tor Lillqvist, Petr Mladek, Noel Power, Eric Ward, Fong, Jian-Hua, Hubert Figure, Fridrich Strba, Kohei Yoshida, Jon Prior, Zhang Yun (/contract people), Jan Nieuwenhuizen (starting soon), and JP Rosevear (mgmt). Actually that makes 16. And you left out kendy. Good grief ! how could I omit Kendy ? (particularly since, as you see he has 2 names) - Jan Holesovsky and Kendy [ so I could have write him twice (which perhaps matches his large contribution) ]. You would be amazed at the fun that can be had on phone conferences with (now) 2 Jan's and a Jian (almost a homophone) ;-) But you're right, we round downish - since, it seems I spent a lot of time working on platform issues that affect OO.o, and JP is a part-time manager on OO.o etc. But you know, I'm always glad to help :-) Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] proposal for change of cws policies
Hi Martin, On Thu, 2007-07-05 at 14:14 +0200, Martin Hollmichel wrote: With the help of Nikolai we are now able to provide a proposal for a modified version of the child workspace policies on http://wiki.services.openoffice.org/wiki/CWS_Policies This looks like an improvement :-) thanks. Under the Setting a CWS to approved by QA - since this is something developers can do (for category B) - can you expand on the (should for bug fixes) section - Make a test specification / test case available - is there some repository of such things somewhere ? how is that done ? in what form ? can this be waived in the case that a unit test exercises the code paths ? :-) Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] uno cil bindings for linux
Hi Daniel, On Wed, 2007-04-18 at 19:22 -0400, Daniel Morgan wrote: What is the status of the uno cil bindings for mono on linux? Radek managed to make them self-hosting in the last few weeks - by porting climaker to C# (from C++), which is great news - and we did some tests on Win32 / Linux to prove equivalence. So - now it is self-hosting, I guess Debian can package the bindings in addition to SUSE, and hopefully we can get this stuff up-stream sometime. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] CWS configrefactor01 unit tests ...
Hi Stefan, Any chance you can help me get some skeletal unit tests setup for CWS configrefactor01 ? I'm very happy to write nice chunks of unit test, but getting the environment setup (and some config data to play with) is more problematic I think. I checked in the (simple enough) testshl2 framework pieces into qa/unit/ but it's clearly not enough :-) Of course, OO.o starts nicely and fiddling with settings works, but clearly having unit tests would be nice. Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Hi Mathias, On Wed, 2006-11-15 at 12:39 +0100, Mathias Bauer wrote: Which timeouts are you talking about? Primarily interaction with User Experience, but also Documentation, l10n - I'd like to ensure not only that they have a clearly defined opportunity to comment / have their say; but that their window of opportunity here is time limited :-) 'discuss' with ... UserEx is fundamentally synchronous, and very hard to verify later, and perhaps open to lots of problems. Much as I hate process, I'd like to be able to point to a mailing list post and say no replies in 2 weeks = uncontroversial approved. If QA people don't have time to test your CWS there is no way to workaround this. If the QA people just forgot about it you might need an escalation path and not a fixed timeout. Of course, but we have our own people (or other engineers) that can do QA - so, if there is some check with UI / Docs / l10n implied by QA then that piece needs to be asynchronous. I believe Kai volunteered to write some of this up in the Wiki somewhere as a conclusion, so we actually move to the decision making phase after the lengthy discussion ;-) IMHO this could be a good reason for an ESC meeting. Indeed :-) it'd be good to talk; perhaps best to rubber-stamp (or recommend to the Community Council (or whatever) the draft result ? Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Specs. closer to a solution
Hi Mathias, So - I think your summary here is great: On Wed, 2006-11-08 at 14:41 +0100, Mathias Bauer wrote: ... snip various good points... So perhaps we can describe it so (with less details ;-): (1) While developing your feature: discuss feature with people on IRC, mailing lists and whatsoever to your liking; it is *recommended* (though not mandatory) to contact the project lead as early as possible and discuss with QA and UserEx also (not to ask for approval but to avoid problems by early contact!). (2) While development happens make sure that at the end you deliver a spec. This could be just an issue in IZ, a web page or a document, details can be described elsewhere. BTW: I consider having an Issue in IZ mandatory as we need to have a reference for cvs commits. (3) Get necessary builds (perhaps by using build bots) and hand builds and spec over by announcing them somewhere(we must define where!) so that QA, translation and documentation can start working on it. (4) React on feedback given by them, be it changing the spec, fixing a bug etc. One thing - we managed to loose the timeouts here :-) since non-responsiveness has been a bug-bear for some years, and is one of those things that may vary substantially over time depending on mgmt imperatives focus, I really want those in there. In order to have a 'fair' timeout, it's necessary to have a time-stamped, reliable, agreed communication medium and length of timeout: a mailing list is fine for that I guess; but it should be specified. Possible an early 'features@' post is sufficient (?). On the other hand - the real strength of your outline is that it is not too rigid / specific: and can be iterated later and expanded as needed to cover unforseen cases [ wow, have I converted you to an iterative process development model ? ;-] So - where do we go from here ? I believe Kai volunteered to write some of this up in the Wiki somewhere as a conclusion, so we actually move to the decision making phase after the lengthy discussion ;-) Anyhow, thanks for your time, Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Unit testing ...
Hi guys, On Wed, 2006-11-08 at 11:27 +0100, Kay Ramme wrote: yes, definitely. What about a staged approach to that: first include all unit tests in a regular build, but _only_ perform them with a magic env var set (like the debug=true stanza)? good idea, that would at least make it obvious how to trigger the tests ... Right, knowing how to run these tests (and that they exist) is at least a large part of the problem. Of course, if more people run them then we get more tests, and the tests don't tend to bit-rot so quickly. I looked at the nice list of tests on the architecture page, dived straight into one: http://wiki.services.openoffice.org/wiki/Uno/Cpp/Module/CPPUhelper/test I tried the 1st test, since the instruction list for the 2nd set of tests looked long scary ;-) [ and presumably would be better expressed as a simple 'check:' dmake rule instead of a hand-typed recipe ]. The result: $ cd cppuhelper/qa/propertysetmixin/ $ dmake ... snip a surprising amount of successful building ... g++ -fmessage-length=0 -c -Os -fno-strict-aliasing ... -o test_propertysetmixin.o /opt/OpenOffice/src680-m187/cppuhelper/qa/propertysetmixin/test_propertysetmixin.cxx /opt/OpenOffice/src680-m187/solver/680/unxlngi6.pro/inc/cppunit/TestAssert.h: In static member function ‘static _STL::string CppUnit::assertion_traitsT::toString(const T) [with T = rtl::OUString]’: /opt/OpenOffice/src680-m187/solver/680/unxlngi6.pro/inc/cppunit/TestAssert.h:100: instantiated from ‘void CppUnit::TestAssert::assertEquals(const T, const T, CppUnit::SourceLine, const _STL::string) [with T = rtl::OUString]’ /opt/OpenOffice/src680-m187/cppuhelper/qa/propertysetmixin/test_propertysetmixin.cxx:407: instantiated from here /opt/OpenOffice/src680-m187/solver/680/unxlngi6.pro/inc/cppunit/TestAssert.h:50: error: ambiguous overload for ‘operator’ in ‘ost x’ /opt/OpenOffice/src680-m187/solver/680/unxlngi6.pro/inc/stl/stl/_ostream.h:96: note: candidates are: _STL::basic_ostream_CharT, _Traits _STL::basic_ostream_CharT, _Traits::operator(unsigned char) [with _CharT = char, _Traits = _STL::char_traitschar] near match ... Of course, it's possible that my environment is just twisted up in some strange way of my own construction ;-) however the install from this build works I believe so ... Naturally it's unfair to infer that the unit tests are all broken under-used on the basis of the 1st one tried ;-) but ... having a standard way to run all included unit tests [ eg. at the end of a BuildBot build ] would be really rather useful. Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Unicode---Give us all of it!
Hi Kay,
On Tue, 2006-11-14 at 10:53 +0100, Kay Ramme wrote:
Michael Meeks wrote:
There's no chance then of switching to UTF-8 as an underlying string
representation :-) and saving a measurable chunk of our string
overhead ?
this is certainly possible by introducing a new string (I mean exactly
_one_ string), which IMHO should address some other points I
investigated into (see
http://wiki.services.openoffice.org/wiki/Uno/Binary/Analysis/String_Performance).
An interesting paper.
This new string should also be opaque, so that internal data
representation could use the most beneficial format available (which
might be UTF8). Unfortunately, this would be incompatible and quite a
big chunk of work.
Well - of course, a big chunk of work is less work if we break it down
do it slowly while doing other things [ like this string re-work
task ;-]. As a first step, (perhaps) while doing this change we should
remove:
operator const sal_Unicode *() const SAL_THROW(()) { return pData-buffer; }
const sal_Unicode * getStr() const SAL_THROW(()) { return pData-buffer; }
And replace them with an inlined [] operator, or better an iterator
API:
* Pro:
+ no performance impact
+ useful for identifying problems with sal_Unicode usage
+ doesn't break ABI compat for existing plugins
+ helps wrt. privatising the internals
* Con:
+ some source/API compat breakage
This then would give us some flexibility to (perhaps) do more
interesting things later with our internal string class.
Just a thought,
Michael.
--
[EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specifications - summary suggestions ...
Hi Joerg, On Tue, 2006-11-07 at 12:40 +0100, Joerg Sievers wrote: + specifications are critical for (at a minimum): + file formats + complex / unfamiliar behaviours + behaviour changes affecting other's work (e.g. the automated gui testing is extremely dependent to the basics of OOo) hokay - well, this can easily be amortised by partitioning the tests such that it is easy/fast to run the tests on the piece of GUI code you changed to verify they are still perfect before marking the CWS 'Ready for QA', and/or writing guidelines on how best to avoid breaking the GUI test tool, and/or improving the GUI test tool code so it is less fragile under test :-) [ string names for key widgets eg. ]. Clearly a situation where the regression tests are fragile over small UI changes, require lots of maintenance and produce lots of false positives is in no-one's interest. Presumably also getting lots of developers to run the tests themselves try to analyse the output may result in more interest in improving the test framework itself. + we need to be able to execute these way more quickly: ~2 hours, to get yes/no answers on individual CWS' faster. On it's way, You can directly contact me for an update. Great; that's good news indeed; thank you. + Wiki + using a wiki for specs allows easier spec editing and construction and maintenance Don't think so, but there is now one. Try to design UI in it and you will love .odt :-) As I've said before, I am certain that the process of designing a UI is best done either in a UI Engineers head, or on some paper, or even better with several iterative prototype models and filmed analysed studies of test subjects using each etc. The spec. document should not be used as part of a workflow, but -only- to communicate relevant information about the finished result to interested parties; hence my desire to remove the IMHO unhelpful iTeaming aspect. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Unicode---Give us all of it!
On Fri, 2006-11-10 at 17:12 +0100, Stephan Bergmann wrote: This indicates that an application's concept of character is often best represented by a programming environment's concept of string. An interesting insight indeed. Use sal_uInt32 to represent individual Unicode encoded characters and add any necessary base functionality to rtl::OUString (e.g., operating on the individual Unicode encoded characters represented by an instance of rtl::OUString). There's no chance then of switching to UTF-8 as an underlying string representation :-) and saving a measurable chunk of our string overhead ? Interesting mail anyhow, Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Hi Christian, On Thu, 2006-11-02 at 00:47 +0100, Christian Lohmaier wrote: But surely the specification needs to be final or stable or whatever you want to call it before the code gets into the master. Sure - it needs to be in a good state of agreement with the code, although as we know, currently the specs bit-rot drastically as soon as we get past this point. So adjusting the spec as your likings after throwing random junks of code into the tree is not what I have in mind when talking about wiki-based specifications. Nor me :-) clearly throwing random junks of code into HEAD is stupid. And if you need to change your whole feature multiple times, then you ought to thing before. (and again this doesn't relate on how to actually code it, but on what the feature is supposed to do) Anyone that thinks they can sit down and design a perfect system and then implement it, without some (perhaps substantial) degree of iterative fixing is [ I think ] deluding themselves. When I worked with hardware design, it was -unheard-of- for revision A. hardware to work without modifications. [ the hardware design flow including a ton of design, simulation, review, etc. ]. There are some great examples of unsatisfactory usability in OO.o that have specifications ( I guess packed with screenshots to match :-). There are other great examples of all-out-over-design around the code, where an iterative approach would have saved both time, money, complexity etc. I don't expect to convince you that iterative development is a good idea for you, it seems you prefer a cathedral approach :-) but at least, it appears to work out rather well for other people. All the best, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OO.o / Win32 startup profiles ...
Hi Malte, On Thu, 2006-11-02 at 13:28 +0100, Malte Timmermann wrote: I don't have any current numbers, sorry. Hokay, I'll try to generate some then, I have them only for Linux. A good profiler for Windows is Intel VTune, evals can be downloaded. I'll boing MikeLeib about that again - Mike ? I could really use a gratis / full copy of VTune :-) Does the Novell build contain more optimizations than the standard build? Is it compiled/linked differently? Sure - i#63927 is rather significant on Linux, and not up-stream yet, also I guess i#66680, and i#66679 are useful, our other wins are mostly targetted at cold-start though, where the difference to Win32 is somewhat smaller. Would you like to also measure the standard build on your machine? Can do, will download it and have a go, (only warm start numbers though for now). Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Hi Mathias, Sorry - didn't notice your summary before posting mine. OTOH - yours looks rather better than mine, thanks so much for taking the time here. OTOH - I make some more concrete proposals, so perhaps there is some value in discussing both in the same thread. It really helps me to keep at least one of thread-ids or subjects constant wrt. tracking the discussion. Is that a basis for further considerations? Did I miss something important? Nope, seems a good summary; one of the ideas I came up with was of splitting the work-flow aspects [ step1: create iTeam, step2: design, step 3: review, step 4: implement ] etc. from the other pieces that are necessary for QA / docs / i18n etc. ie. providing separate guidelines for how teams can function, and develop software vs. what information / approvals are necessary to get changes included in the product. Anyhow - thanks again, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
On Tue, 2006-10-31 at 17:42 +0100, Christian Lohmaier wrote: I disagree. Esp. when the UI is changed significantly the UI-mockups are necessary. Both for finding flaws in the proposed design as well as for documentation. I'm well up for the UI team doing mock-ups and communicating those to the developer, makes perfect sense. Of course, what comes out in the product may not be like the mockups, hopefully it's even better - so why enshrine the mockup process in a formal document ? I'm sure nobody expects you to do a pixel-accurate mockup, but again the user-interaction part should be clearly visualized. Sure - and of course UI is important. Snip some good quick-starter related questions - sure - all of these things can be easily added to an unstructured wiki page / FAQ, that can be built up as people ask the questions. In this scenario, a spec cannot be used to verify the implementation, because the implementation is done first. Well, you can still see whether what you coded actually is what you thought it would do (i.e. what you coded is what you wrote down in the spec). But we didn't write down a spec. We conceived of the idea, then implemented it, now we have it. The original conception of course was prolly inaccurate, no-one gets things right 1st time, we most likely have a solution that is now far better than that, similarly we are now probably aware of the various limitations of the current approach, and various next steps / future development to do. It is true that you miss the find errors in the planning phase (but again I don't think you start coding without having planned the changed first, so no gain/no loss) The problem is that there is a very large difference between conceiving an idea and writing it down as prose (with pictures); you can conceive of things almost instantly, writing a general document for an uncertain audience is very time consuming. Anyhow, Good stuff, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... - unit testing
Hi Christian, On Tue, 2006-10-31 at 17:54 +0100, Christian Lohmaier wrote: An unfair cite. ;-) lets look at the context contention: On Mon, 2006-10-30 at 23:57 +0100, Mathias Bauer wrote: You mix up some things here. Nobody said that we need a spec for each and every tiny ergonomic fix. ^^^ On Tue, Oct 31, 2006 at 02:27:23PM +, Michael Meeks wrote: I refer you to the Sun rubric ** emphasis added. ... I Want to Change Something in OpenOffice.org - Do I Have to Write a Software Specification? **In general the answer is YES**. This applies to: Features, Enhancements, **Defects** That page appears to say nothing to exclude tiny ergonomic fixes (for defects) from the spec. process, -) Indeed they are clearly in the Behavioral changes of the UI. I think the current thrust of the process is clear here. An unfair cite. it is Defects **requiring the following type of changes**: list of criteria You don't cite include the relevant criteria either :-) Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... - unit testing
Hi Mathias, Once again thank you for your thought provoking mail. On Mon, 2006-10-30 at 23:57 +0100, Mathias Bauer wrote: You mix up some things here. Nobody said that we need a spec for each and every tiny ergonomic fix. We need them for new features - e.g. a quickstarter on Linux. :-P I refer you to the Sun rubric ** emphasis added. http://wiki.services.openoffice.org/wiki/Category:Specification I Want to Change Something in OpenOffice.org - Do I Have to Write a Software Specification? **In general the answer is YES**. This applies to: Features, Enhancements, **Defects** Now, of course we could explicitly exclude more things from this, which would be good - but AFAICS - at least as of now, each tiny ergonomic change requires -at-least- a round-trip to the team lead. So we have parts in the code that are unit-testable (and we have tests for it) but most code unfortunately is bound to some vcl/sfx/svx/etc. stuff that makes unit testing impossible. Great - so, what pieces of code have functioning unit tests ? whenever I hack on a module I like to try and find these tests, I poke in 'workben' and I see very frequently stale/un-buildable/un-runable code, then I poke in qa/ and eg. in configmgr/qa/unoapi I see a makefile.mk I 'dmake' that, something happens and it barfs: Exception in thread main java.lang.NoClassDefFoundError: org/openoffice/Runner dmake: Error code 1, while making 'ALLTAR' it appears broken out of the box. I would -Love- to have a good, standardised unit testing framework in place to add tests to, and let us re-factor code more aggressively with confidence. However - I just don't see anything here. The long duration of the tests is indeed a problem. Yep, and something we need to fix of course; hopefully some of Noel's work on the performance of StarBasic's may help here. We are currently investigating how we can get faster tests, one direction we are looking into is avoiding or at least reducing the idle/sleeping times. Yep - of course, understanding why these idle times are there would be good I guess. Other ideas are welcome. My very personal opinion is that we should have more API (code) based tests and less GUI testtool based ones but I know that there are other opinions. Must be discussed. Well; of course from a 'community' perspective - I'm well up for adding in-source, in-CWS, standardized, fast unit-tests. eg. reading the calc 'R1C1' work recently, I was itching to write a test-suite, that would simply exercise this piece of the calc code parse 100 formulae of varying complexity and validate that the results were correct. Unfortunately it's -really- difficult to do that. There's nothing wrong with doing unit and API tests in Java. As long as they are easy to run with some standard command, I don't much care what they're written in. And UNO components don't make anything more complicated Au contraire - if you have built all of OO.o up to 'sc' (eg.) and you now want to write a very small, very fast unit test to exercise just the formula parsing piece - you have a nightmare. Somehow, you have to get OO.o alive enough to actually start, bootstrap etc. you need to build a custom .rdb file [ we have ugly unsustainable hacks in 'workben' directories around the place to do some of this ]. You can't even read a file in without having an huge types.rdb, services.rdb, a ton of paths set right and a big piece of boilerplate code etc. etc. :-) AFAICS it's a huge pain. Of course - if there was an existing small/light/simple infrastructure that tests could be easily added to, then I for one would write more unit tests: this gap has frustrated me on the 2/3 times I've actually wanted to sit down write a block of test code. [ And really, arguably, people should be writing the torture tests as they write the code ]. The other problem with UNO is you can only test what is exposed via. UNO, and that is not enough to torture the internals often. Or is there anything you find more complicated in unit testing of UNO components? Then please give an example. It's possible my horrific past experience of UNO bootstrapping is now obsolete :-) if so, wonderful. I'm looking for a solution that doesn't require installation, can be run in the source tree very simply with 'dmake check' (eg.) and will run through a list of test modules, build them, execute them, and report their output; and wrt. VCL - having a live X/GUI connection, at least for now is just fine. Preferably being able to automate this fully (on each CWS before it's nominated) would be ideal. You again mix things here. This is no longer true for fixes in 2.0. And nobody asks for specs for bug fixes. Please give examples where a bug fix was not integrated because a spec was missing. It depends what you see as a bug. I see something being
Re: [dev] Specification Process Possibilities ...
Hi Thorsten, Thanks for your mail - this is good stuff. On Tue, 2006-10-31 at 10:45 +0100, Thorsten Ziehm wrote: Yes the specification process was introduced in OOo 2.0 time frame. But it doesn't work, as you said. The bug count was high in OOo 2.0. Therefore a template for specifications were developed to eliminate the most important faults. Sure - I just don't think that (given the mixed results of the initial spec. process to substantially improve quality) it's possible to authoritatively state that increases in code quality post 2.0.0 are due to the [new] spec. process itself. So much changed (for the better), it's hard to say where the dominant effects are. I think this is one reason why OpenOffice.org is so successful. Do you have data to back that up ? It isn't possible to get data here. But from my own feeling and discussion with many people, quality is the highest priority. Of course, anecdotally I have a different slant :-) to measure this - if we do user surveys we could perhaps work out some questions to ask that would measure this (though it's hard to phrase them I suppose): What did you notice most about OO.o 2.0 a) better interop b) new Impress layout c) improved stability ... it'd be interesting to see the result. [ I thought Sun did market research of this form, perhaps Erwin has some hard data ]. OO.o is incredibly slow to start Yes this is a bug. But I think it is more than one bug. :-) indeed. Unit tests and tests with automated TestTool are different level of quality assurance in Software. Unit tests are used to check the code itself. The next level are API tests to check the integrated code in the whole content. Sure - of course, being able to run large numbers of very complex tests very quickly inside a local developer's build tree is clearly a good goal, and (I hope) quite attainable. So - I need a deeper understanding of what you understand by quality and how you weight these statements: This was very interesting indeed, and broadly I agree with you, so perhaps we're not so far apart at all :-) User perspective : In my opinion we had the following goals in the last updates. (I changed the order of your points) + Quality is OO.o not crashing (stability) + Quality is OO.o not loosing data + Quality is OO.o loading saving my 'foreign' data files + Quality is OO.o performing acceptably + Quality is OO.o not consuming all available memory And we don't do too badly with the above. + Quality is OO.o behaving ergonomically as I expect + Quality is OO.o being slick beautiful + Quality is OO.o being feature competitive with others I guess these last 3 are what the spec. process targets, and of course prolly where we need the most extra polish all over the place. Unfortunately wrt. slickness the large number of small changes to make OO.o 'slick' [ a vague term it's true ], are substantially retarded by the spec. process - which concerns me. Code contributor perspective : These are important points too. These are and should be goals for the development. I cannot speak about that, because I am not the professional in code quality. + Quality is OO.o source code being readable + Quality is OO.o source code being maintainable + Quality is OO.o source code being consistent + Quality is OO.o source code not being cut/pasted So - here we can perhaps use automated lint style tools to help [ eg. the warnings redux work is really useful here I think ], we could also (perhaps) use one or other of the cut/paste detection tools to generate a metric before/afterwards and point out the delta. The other bits can only be improved by code review I think. The quality (user and developer perspective) can be increased with specifications. But specifications are not a part of the quality. + Quality is every aspect of OO.o having a detailed spec. And this is the wonderful. It's great that you view the spec. process not as an end in itself, but one tool to achieve greater quality in certain circumstances. Of course - ultimately it's clear that we both want a higher quality end-user product, and we just need good processes that encourage contributions that (we can be sure) raise the quality to get into the main-line as fast as possible. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ...
Hi Thorsten, On Wed, 2006-10-25 at 13:23 +0200, Thorsten Ziehm wrote: Nobody said, that it is needed to include _burdensome_ processes to get a higher quality. Wonderful, so making the process less burdensome is possible. Great - so, lets get the design requirements for the specification process all collated in 1 place, and then try to make a much less burdensome process :-) All over in the industry you see processes and control mechanisms. Without that we are not in such a high living standards. So why the Software industry and OpenOffice.org should give up processes and control mechanisms? Did I say we should give up our high living standards ? ;-) of course we need -some- process; ideally though it should be one that is minimal [ ie. requires the minimum effort to achieve the maximum benefit ], and simple to use. Furthermore, there needs to be a get-out clause for external contributors, at least for their first N features, and finally it needs to not rely on people being responsive :-) That the quality is still not good you are right in some cases. Yes we have still more then 9000 issues open. Nearly 6500 issues are defects. But in my opinion OpenOffice.org 2.x is more stable and is more usable and more bug free than ever. From my experience (of back-porting, sometimes critical, fixes from the 680 branch back to OO.o 1.1.x) the -primary- driver of improved quality in OO.o 2.0.x has been the switch to frequent releases, and not the introduction of painful, and change inhibiting processes. The frequent release means that people do their fix once and get it included in the product shortly afterwards, instead of having to worry if it's critical enough to get back-ported. As for the quality of OO.o 2.0.0 [ created AFAIR after the specification process was introduced ], I think it was a fairly 'interesting' release (defect wise), hence the compound slippage etc. I think this is one reason why OpenOffice.org is so successful. Do you have data to back that up ? If somebody think the quality isn't high enough, why they are working on new features and why they are not working on fixing bugs? Perhaps their bugs are of the form: OO.o is incredibly slow to start :-) is that not a bug ? or perhaps they are bugs about ergonomic problems - is it fixing a bug or adding a feature to make some minor (unusable) corner case usable ? That's not the point. It isn't possible to check the quality of all integrated code by the Sun QA team. Which is strange. At least, from where I stand we need more quality [ by which I mean all-around polish ] not less; from a UI perspective we need thousands of tiny ergonomic fixes all over the place: almost all of them trivial in and of themselves; but if each one requires a multi-page specification, they will never get done. Furthermore, I find the quality of the QA tests generally rather poor. My recollection (which may be wildly astray) is that broadly there is a large list of StarBasic test cases [ which is good ], but many of these are known to fail / spit warnings, they take several (3+) -days- to run (mostly with the machine idle / sleeping), and they're not particularly reliable :-) [ is that unfair ? ] Good unit testing [ as in I can run dmake check in configmgr and get a yes/no answer in a few seconds ], such as I've implemented in previous projects I've worked on [eg. the several thousand lines of unit test in ORBit2] is invaluable. It helps re-factoring, it improves quality and confidence in the product, and so on. Of course UNO components substantially complicate such unit testing in OO.o (along with (apparently) a love of only testing what can be tested via UNO, from Java ;-). At least, I've not been able to understand the useful / common recipe for running do tests or whatever in a given source directory getting useful data - I'd love to be shown how this works. One point was not understood over years at StarOffice team at Sun and other software products around the world. The Quality Assurance cannot bring quality into the product. The developers bring the quality into the code and the QA have to make regression testing. So - if maintaining a constant quality level is what matters would you trade higher quality code (ie. peer reviewed code) for some reduction in of code-duplication-as-paper-work [ the spec. burden ] ? I learned from the past quality takes time. If you want to have quick fixes and changes into a code line, the quality will decrease. What do you want to have, a product with higher quality or a product with much more features and changes ? The problem is you are retarding not just features, but fix inclusion. This was dramatically the case with the old-style 1.1.x branch: the cost penalty of back-porting *fixes* was so high that only very infrequently did people bother to actually do it, consequently the quality
Re: [dev] The QuickStarter Spec.
Hi Frank,
On Mon, 2006-10-30 at 09:58 +0100, Frank Schönheit wrote:
Right, the specification is not ... really comprehensive here. Which,
technically, is a bug in the specification document ;)
Thankfully the code works :-) But the very concept of rampant
duplication of state all over the place is at root broken IMHO. Having
unnecessary screenshots, duplicating bi-lingual strings etc. adds
[AFAICS] nothing at all to an existing impl, but a huge amount of pain
in terms of re-synchronising things.
I don't have an answer to this. I still think the document has its
value. But from certain of you comments, especially the repeated example
of self stultifying arguments, I suppose you won't accept when I say I
think that we're learning by doing. In specifications as well as in
coding ;)
Well; clearly the argument that at least with a spec. QA can know what
the impl. should do is shown to be almost totally bogus :-) it's
possible that spec.s are good for -something-, but we should find what
that something is, and only do that - rather than trying to replicate
War Peace [ with pictures ], before changing a single string ;-)
* Why does it matter that it's broken ?
...
I cannot but agree here. Reading [EMAIL PROTECTED], you might notice that I
repeatedly argued that specification documents become increasingly
useless over time, if they're not embedded in some system to ensure that
they (means: we have a chance to keep them) up-to-date. A document
management system, in particular, which for instance allows to search
for the spec covering the functionality I am going to change.
Sure - the wiki is a reasonable choice here. That at least cuts a good
few steps out of the painful process [ wrt. finding where spec.s are
committed, checking stuff in / out etc. ].
However, I fear you won't like this idea, and label it is even more
bureaucracy.
Well, the main problem with the spec. process - beside the specs being
way too verbose ('Complete'), is the latency problem. It's all very well
soliciting input from all sundry, but if they ~never respond life
becomes very painful indeed; particularly if you just invested a ton of
effort in trying to please people - who having done this - turn out not
to be at all interested.
An asynchronous work-flow, whereby an Engineer can implement a
feature / fix, knock up a quick wiki page describing it, commit it to a
CWS, assign it to QA, mail the dev@ui.openoffice.org list about it, and
get on with his next task would be ideal. Of course, U.E. could poke at
the wiki/issue (if they were interested had time), otherwise it would
just proceed, QA likewise could ask questions / extend the wiki page
describing the change (if at all necessary), otherwise they could focus
on the real grist of the implementation.
So - I'm not against writing -something- down, but lets make it
absolutely minimal. Matthias Heutsch had a nice flow based on the
Solaris process that included a streamlined fast track for
'uncontroversial' changes; codifying that (and a load of timeouts for
comments) would substantially improve things.
HTH,
Michael.
--
[EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Hi Mathias, So, while broadly agreeing with most of what you say: On Mon, 2006-10-30 at 08:53 +0100, Mathias Bauer wrote: Without the spec the QA wouldn't be able to even find bugs in many cases (with the exception of obvious ones). We hear this a lot. And, now we know that specifications are frequently inaccurate, buggy / out of sync with the code anyway. So - I'm having problems understanding what -exactly- QA need here. It'd help to have 10 representative examples of times when a specification has actually helped distinguish between bugs features, and what was done with that information [ writing tests / whatever ]. Perhaps with some good examples to analyse here, it'd be easier to understand some of the rational. Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ...
Hi Frank, Sorry to spam you with yet another huge E-mail, this is quite an effective technique known as argument by exhaustion ;-) On Wed, 2006-10-25 at 09:48 +0200, Frank Schönheit wrote: I agree with you that those hurdles experienced by contributors are a big reason for not attracting more developers. Good 'oh :-) and of course, so do we - and various people are trying to fix them: trying to make the BuildBot work well is a prime example. What I want is to be able to test CWS builds easily on Win32 - since that's a problematic platform for me (and virtually all Free software developers), it requires proprietary tooling to get anywhere, and well - it's of course critical that it's not broken. Contrary to popular belief I don't like to break the build / code :-) All I can seriously recomment is: keep fighting. Both for people from outside Sun as well as inside Sun :). Thanks for the encouragement :-) I will do myself, as I did in the past, since I heartly believe that we cannot throw all full-blown processes at a newcomer who does a small fix/feature. Right - and of course, I'm to some extent preaching to the choir here, you've done some great work in this area in the past. This doesn't mean those processes/requirements are unnecessary or stupid, it just means that we should allow people to grow and learn, and not do everything right and complete in the first step. Ah - in itself it doesn't mean the processes/requirements are *not* unnecessary or stupid either ;-) Simply because you can think of 10 good reasons for a process, doesn't mean that that there are not many other more weighty reasons for not using it. Well - my attitude here is rather different :-) in the time that it took to create the CWS, commit the code, go through QA etc. I had in parallel done a number of other improvements / fixes, and subsequently ... Well, and that's a fundamental misunderstanding on your side, sorry. That's explicitly *not* how OpenOffice.org works. The whole idea of child workspaces is closely coupled to the idea of having a stable master build. In ideal, we would be able to ship every master build (in reality, that's not the case, but we're much better than some years ago). Interesting. I don't know how you square that with the state the code is in, and (even) some of the things that people commit to it [ even with specs ;-]. That's an explicitly stated goal of the OpenOffice.org project: We don't break the master, we finish implementations in a child workspace, until they're really finished. It's a worthy goal, ultimately though - no matter how much QA you put into something, you won't find some bugs until it is deployed. And I was aware of -no- bugs in the feature when it went it ( I am of course now ;-) only some areas for future work: so what does 'finished' mean ? It's interesting instructive to head to LXR search for TODO: http://go-oo.org/lxr/search?string=TODO 'handle error', 'error handling', 'Check return value', 'introduce error handling', 'still needed?' ... ... Other projects have other means for ensuring quality. For instance, Mozilla has a *very* rigid code review process. OpenOffice.org's mean for ensuring quality is the finish it on a child workspace policy. There's no room here for put it in and let it evolve. I would be amazed if we actually managed to get any non-trivial piece of code through to HEAD that had no defects found in it later. You might want to question this idea and policy, but please not by silently undermining it. Pah ;-) as I said, it was a less feature-full implementation, not a (known) buggy one. And I think it's a legitimate decision. However, what I really *really* like about this process is the exchange of ideas and arguments. In my experience, sitting down (or meeting in IRC) with a small (!) number of people having experience with and/or interest in a particular feature is invaluable. You always gain insights you wouldn't have had alone. And finally, this means you deliver a better feature. I wholeheartedly agree with the above. -Clearly- it is important to talk to people skilled in the area of artwork, HCI, etc. etc. and to some extent the more advice you can get the better. However - if you hand out veto's to everyone, and then each communication round-trip takes even days, life is not good. I think the problem here is that the specification process also tries to make a rigid mould into which to pour basic team activity interactions. The book I'm currently reading on building good teams (Peopleware) tends to emphasise the stifling nature of methodology, and homogoneity - and encourages diversity. ie. If your team happens to communicate best by semaphore, and works only between 2am and 5am - then, if they do great work, perhaps it's worth accommodating them without feeling threatened :-)
[dev] Specification Process Possibilities ...
Hi Frank, On Mon, 2006-10-23 at 13:12 +0200, Frank Schönheit - wrote: To me, this whole discussions seems to be about the bring it in quick (and sometimes dirty) vs. bring it in slow, but matured (though sometimes still dirty) Well - it looks like that on the face of it. However - while I absolutely loathe the process, I can (perhaps) live with it - if it actually worked :-) Sadly it is totally dysfunctional. If 1 (one) interaction can take of the order of months to occur, the spec. process which mandates another order of magnitude more interactions, puts any feature inclusion into the multiple year time frame. My problem primarily is with responsiveness inclusion. You prefer the first one, as you said often enough. I continue to think that the second one might bring more than it costs, *if* applied properly. I might be wrong here, but that's still not proven to me). Plus, that's a big, fuzzy if, admittedly. Cool, I'm glad you're willing to accept there might be different (perhaps just as valid) answers to the same question :-) And of course - from my perspective the only certain way to ensure that the process is applied properly is to have no process :-) On the other hand, I often hear this wonderful (circular) argument it goes like this: them: We need this burdensome process for Higher Quality ! us: But lets face it quality is still not good them: Then we need -even-more- burdensome process ! repeat ad nauseum. The 1st step here is to realise that perhaps there are other self referential world views that also lead to better quality, and to tackle the issue from 1st principles again, recognise the local maximum we're at - and try to peer around the energy surface to see if we can see any other big peaks around that would get us higher :-) The problem is: We need to find a consensus in the OpenOffice.org project as a whole, and all your sarcasm doesn't change this. Well, (apparently) my sarcasm has at least got people to discuss this problem that has been festering, un-fixed for some years now. My feeling is that some parts of Sun are in fact eager for the process to be burdensome - precisely to raise the barrier to entry, and ensure that (to their mind) only the best work gets included. To my mind this is a tragedy and a sure-fire recipe for continuing to not attract any developers. I sometimes think that some people are also in fact quite pleased that eg. it's impossibly difficult for the average developer to build on 2 platforms before getting their CWS included, (which would explain the almost total lack of action wrt. making this easier to do). Or are there chances we find a compromise? I'd love to find a compromise, but this has to be part of a bigger discussion as to why OpenOffice.org is failing to attract a meaningful developer community - and who owns that problem; or if it even is a problem. (There seems to be substantial doubt in a lot of people's minds here). There also appears to be a free labour perception of volunteers in certain places: that these people can be asked to do arbitrarily unpleasant things, and that they will do them. I'd like to persuade people this is (emphatically, and clearly) not the case. That if Sun QA wants to include all this process for Quality reasons, then -it- must shoulder the burden [ at least for volunteer contributions ]. Ultimately, I'm not unhappy to have a mega-ton of specifications that few people if anyone read, and an ongoing maintenance nightmare of keeping them in-sync with the code as long as I don't have to pour my resources down this particular black hole :-) [1] Did I mention your port doesn't work as expected for me? After the first start, I have a quickstarter. After closing it, I never get it back, again, not even with checking the respective option in the menu. This is in fact a 'feature' of the Win32 quick-starter too :-) Basically the option is not instant apply, consequently you need to re-start OO.o to see the effects. Similarly (reading the code) it seems it's likely that another bug filed (i#70484) also afflicts Win32 users but they didn't notice ;-) Somehow I think this particular feature *should* have had some more QA, in other words: some involvement of more parties. Well - my attitude here is rather different :-) in the time that it took to create the CWS, commit the code, go through QA etc. I had in parallel done a number of other improvements / fixes, and subsequently then fixed a number of other issues which were kindly reported when (you guys) started using it in the milestone - all of which are committed to gtkquickstart2 - which FWIW improves the usability, makes the settings instant apply, etc. and starts to be a rather nice solution. Unfortunately it may be mired in the process perhaps indefinitely [ unless some friendly QA person wants to help out ].
Re: [dev] Quickstarter on Linux
Hi Bjoern, On Tue, 2006-10-24 at 13:00 +0200, Frank Schönheit - wrote: But, coming back to a more technical stand-point, how does this work? Don't know. Michael said he simply ported the existing Windows code Basically yes, there is an empty OO.o window running in the background all the time - it burns some MB certainly, it also saves a lot of cold-start time for an average office worker I think [ clearly not us ]. Of course, whether it should be enabled by default is an interesting question; it is not for our Linux builds, is it possible there is some difference in the Sun build system in this area ? [not got to the bottom there - just turned it off for Sun]. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ...
On Tue, 2006-10-24 at 16:19 +0200, Frank Schönheit - wrote: (separating out the following from the more general discussion) :-) I meant what I said: never. Not even restarting OOo gives me back the quickstarter. Well, not really never: When I erase my OOo user data directory I get it back, but that's not really something I'd do with my production installation :) Oh wow, that's really silly; honestly though I have no idea how it manages to be on by default for you :-) the code that does this is (pseudo-code) sfx2/source/appl/shutdownicon.cxx: bool ShutdownIcon::GetAutoStart() .. return fileExists (~/.config/autostart/qstart.desktop) It's not that clear to me how it can possibly be finding that .desktop file there post 1st install; that is unless you have some other 'qstart.desktop' for some other program that is autostarted [ I guess it's not the world's most unique name ]. Any ideas ? what's in that directory ? and/or does it exist ? what are the permissions ? could you open an issue ? an strace/truss of the process over attempting to re-enable the quick-starter would be most helpful; also OS wise - I guess this is Solaris - is that so ? Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ...
Hi Uwe, On Tue, 2006-10-24 at 16:51 +0200, Uwe Fischer wrote: so you introduced a cool new feature (by surprise to me), and then some people told you that it's not up to the normal procedures to do so, and now you disabled that feature for Sun builds? :-) basically yes, although of course my CWS doing that is not even QA'd yet. I would like you to stand up and fight a little bit more for your feature! Well, fighting is not even necessary, just do not kill the feature because of some complaining mails. Heh ;-) Thanks for your encouragement. The current state is that I hurried to get the new feature explained in the Help files, and now I must run to revert those changes again? This is no fun. Well, here is the problem - in order to (properly) fix the lifecycle issue that various people noticed, it was necessary to change a string (since the check-button enable systray quickstarter now has immediate effect as you disable it - ie. pointless for it to be a check-button ;-). So the label is now different - we break the string and UI freeze = I assume it's easier for everyone to just disable it (hiding a string / some UI), and we can think again for 2.2. Also Frank's bug / people's observation that it starts by default is somewhat surprising and unexpected makes it rather less a niche feature, I'm not that happy about that; it needs tracking down to the bitter end fixing. And what must a user do to see the new feature if he/she has a Sun build? Sit hope Sun will include it (after the relevant rigorous specification process foo etc.) was the general idea. So I feel bad to have caused you so much extra work. If you tell me what CWS your changes are in - perhaps I can back them out for you as a patch ? [ though not for 2 days ], and then keep them around in that form to re-commit as/when/if-ever the feature gets enabled so there is no extra duplication of your effort. How does that sound ? Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] A word about (missing) Specification Documents and (late) Feature Mails
Hi Niklas, On Fri, 2006-10-20 at 10:40 +0200, Niklas Nebel wrote: Michael Meeks wrote: Let me show you why I feel this way, from a simple example I was reading this morning: notice the consultation going on in this issue: http://www.openoffice.org/issues/show_bug.cgi?id=56202 Had you quoted more, we'd see that the .. part lists some problems with the patch that haven't been resolved. Sure - and they are valuable feedback, much appreciated; and need fixing - but ultimately is there any point if User Experience are the gateway for all changes, and simply don't comment ? On the other hand, it shouldn't turn into I've got an unfinished implementation of something I can't describe, and expect Sun to do all the real work about it. real work ? honestly - do you expect to get perfect 1st patches from people inexperienced with the 'intricacies' of the calc code ? Volunteers for example ( Muthu is an unpaid Indian chap ). If so, I would suggest that is not a realistic expectation. As for not being able to describe what is required, I refuse to accept that adding a single missing key-binding for a single language requires any more detailed description in order for you (or anyone else) to understand it :-) If by real work you mean that the paperwork and interaction involved in getting a small change into OpenOffice.org *far* outweighs the actual time generating the code - then I totally agree with you :-) Some people see that as a feature, I see it as a debilitating bug. On projects I'm interested in developing, if a patch arrives that needs a couple of minor fixes, I would tend to point these out fix them at the same time [ it's often no more effort than locating them in the 1st instance ], test commit. I find it hard to communicate how intensely frustrating the Sun interaction is, but I just thought of an innovative way here, watch this space. You could save yourself a lot of frustration by following a common-sense order of steps: *First* define what a desired feature is, *then* start implementing. Really. Try it. jokeStrange - we have a different process whereby we have no idea what we want to achieve, we just type at random for some weeks, then submit a patch ;- This whole knowing what you want to achieve thing is a revolutionary concept indeed./joke Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] A word about (missing) Specification Documents and (late) Feature Mails
Hi Frank, On Wed, 2006-10-18 at 12:35 +0200, Frank Schönheit wrote: In this case, Uwe would have told you that various documentation would need to be updated, to keep the product consistent So - my experience is that the more people involved in a decision - the less likely any decision is to be taken: consider the difficulty of choosing a restaurant with 3 people vs. 10 people. I don't like Chinese, I can't walk far, I know this place ... Do you observe that phenomena too ? [ every week ? ] Currently from my perspective we ( as a project ) don't suffer from too many things happening at all quickly; indeed glacial movement is racing past us, wrt. getting changes up-stream. Of course things are nice and cosy inside Sun I'm sure - where there is some central-planning and people can be persecuted in person through some chain of command. Consequently, at the moment, I'm by instinct -hyper- reluctant to consult anyone about anything if it can at all, possibly be avoided by some means. For me consultation means a black hole of months of unresponsiveness, and the need to go around begging yet more people to actually do something. Perhaps you can persuade me otherwise, that by consulting more people we'll get a genuinely better result, and not endless delays ? Let me show you why I feel this way, from a simple example I was reading this morning: notice the consultation going on in this issue: http://www.openoffice.org/issues/show_bug.cgi?id=56202 [snip] --- Additional comments from nn Tue Apr 4 ... 2006 --- Default keyboard shortcuts are administered by User Experience, so I'm cc'ing MMP to allow him to comment. .. [snip] A (perhaps) reasonable request - I mean, we just want to add a keybinding that doesn't exist, in 1 language, to be more compatible with what people expect. It is now Oct 19th 2006 - and we're still waiting for User Experience to comment. And - wait, let me see - who is to blame here ? it is clearly going to be my fault for not throttling someone earlier ? This of course, is one of the more recent issues, some are rather older. Otherwise, in principle - I'm well up for getting as many people involved as possible; as long as they have the right attitude: wow, thanks for your work, let me help you get it included I know this is your attitude personally Frank, and I've enjoyed working with you on several pieces of code; however all too often people's attitude seems to be: I'm so busy I can't be bothered to reply to your mail/issue or no - I'm too busy to handle this = I'll block it or yes it's fine, but some step in the process wasn't done in the correct order = reject (The fact that the current help is ... sub-optimal doesn't mean we're allowed to make it worse, by out-dating it knowingly.) As I say, of the ~million or so users that have been exposed to the outdated help in this area, none I know of have noticed or cared enough to actually file a bug. That suggests to me that my decision (in this case) to let the help get out of sync was not altogether a bad one - what's your take on this data point ? are you certain that help should be updated synchronously ? A converse data point is that lots of people were happy with the new Quick-starter and congratulated me personally ;-) [ though Raul wrote a bug chunk of it in fact ] Other people - from QA - might have expressed interest to get their fingers on the CWS before it's integrated, to add the new feature to their existing tests. Sounds good to me; another problem is, finding out who these people are and how to them involved ? of course, I love to work with domain experts that are responsive and helpful, and I'm happy to help inform QA on what they need to test things. Yet other people could have told you that there in fact is an existing specification for the quickstarter, which claims that's a Windows-only feature. I wonder if anyone has ever read it after it was written - perhaps we can tell that from the web server logs. I wonder if it is still accurate ? [ or are you suggesting all screenshots and string lists duplicated in any specification must be updated for any relevant string change ? ]. Now also this specification is out-of-date (which makes specifications effectively useless, on the long run). As you know, I think *almost* all specifications, particularly for something so mind-blowingly simple (conceptually) as the quick-starter are broadly a total waste of time; or to abuse your words are effectively useless anyway :-) I for one, don't want to be writing the transparently obvious down at great length repeatedly. It seems Sun people have a different view. As you can see, the idea of involving different people with different competences (that's the idea behind an iTeam) *early* is not an end in itself - it's about delivering a self-contained, consistent product
Re: [dev] A word about (missing) Specification Documents and (late) Feature Mails
Hi Uwe, On Wed, 2006-10-11 at 13:50 +0200, Uwe Fischer wrote: Don't get me wrong - I love this feature and I will never say anything negative about Michael Meeks, who surely is a programming genius. ;-) Haha ;-) the sarcasm detector just exploded. How am I supposed to deliver a timely Help for this feature when - there is no Spec Doc Is it necessary to write a full spec. for porting a feature to a new platform ? I hope not. How about porting all of OO.o to 64bit ? ;-) - there is a feature mail very short before the new build that contains the feature Sorry it was rather late, though it's not clear really what to expect here. - there is no one to send questions or issues to? As far as I can see, I didn't get killed yet :-) on the other hand, you're guaranteed a more prompt response [ that is if you actually want one ], by mailing me (or at least CC'ing me) rather than some list I can't read all of. [ 4817 unread for this list alone ]. I have many questions, for example - will the feature be visible on Linux too (I see it in m187 Sols/Gnome) Yes - anywhere with gtk+ available. - will the feature replace existing quickstarters on Linux or be in parallel? That is a distribution / vendor choice - but if you read the 'code' of the existing quick-starters, you will experience the answer :-) - the text string on Tools/Options/OOo/General is different from the existing text string on former Windows versions. I have no idea if this change also changes the existing text string for Windows versions to be the same as now on Solaris. Nope it does not - easy to see from the patch. - what about the start parameter -quickstart? Will that work now on UNIX? Must I change the Help here too? We don't use that flag, so - no clue - no change there AFAIR. - why is the Help/Guide check box in the feature mail not marked? We did mention the (Windows-only) Quickstarter at numerous places, as did the OOo community in their printed and online documentation. The fact that a real developer never scans through Help or Guide pages does not mean that a feature is never Help/Guide relevant. ;-) haha - I often use the help myself. On the other hand, we shipped a version of OO.o with this feature, and the help out of sync. to many tens of thousands (if not millions) of users in our builds - and so far I see no bug reports, so ... how important is this truly ? - on Windows, installing a patch will first close the application including the Quickstarter. Will it be the same on UNIX? On Linux (for me) you'd upgrade a native package / apply an O/S patch. On Unix this is somewhat less problematic than win32 wrt. file locking etc. For me, and may be for a lot of other community members, it is important to get information about new or changed or removed features *early*. Best practice would be if every Help relevant feature has the helpcontent2 module added, so I (or the developer) can change the help files and have them integrated the same time as the feature. Hokay - this is great best practise to know, and I'm happy to do it, but it's the first time I've seen it mentioned. Where is it documented ? perhaps it is already, but I havn't seen it: * what module to add the CWS * list of contact people to poke about updating help what their area of responsibility is so we get the right people. * means of detecting when they are done / assuring response Then of course we need to find the right place in the wiki to do that, and - naturally tell people the process has changed [ NB. mailing individuals is more helpful than posting to a list people don't read ]. Anyhow - I'm sorry if this caused you some grief; hopefully we can get it right next time, and I hope you like the feature - it substantially improves code cleanliness, and 2nd start performance. All the best, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] configmgr re-factor ...
Hi there, I'm starting an 'interesting' step-wise re-factor of configmgr - stripping out tons of complexity. It seems to be going well so far ;-) [ removed the 'simpleheap' thing without too much difficulty ], but I'm wondering: Is it ok up-stream to strip out all these poorly performing side-effects of the (unused) shared-memory architecture ? :-) Also - is there a simple to use regression test suite for this code that I can press a button and 5 secs later determined I didn't cause a regression [ none of the changes are tricky enough to require that yet but ... ;-]. Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] configmgr patch more data ...
On Wed, 2006-09-13 at 12:22 +0200, Joerg Barfurth wrote:
Looks good.
I fixed your issues; thanks for the feedback, I attach the improved
patch. I also expanded the cache to some more fields that are broadly
constant, and split it into 1 cache per re-usable field. It saves some
more memory.
I'm also looking at the Subtree set usage:
http://go-oo.org/~michael/sortedsizes.ods
My concern here is the 16bytes per RBTree node (used in the set), at
least allocation here shows up on the profile.
It seems that 90% of these sorted sets are 8 items or less, and thus (I
suspect) rather fast to search, well, at least indistinguishable from
the order of the Set. The RBTree overhead for these = 8 sets is ~250k
(malloc), overall 500k. I'm sure we can do better.
HTH,
Michael.
--
[EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot
diff -u -r -x 'unxlng*' configmgr/source/backend/binaryreadhandler.cxx configmgr/source/backend/binaryreadhandler.cxx
--- configmgr/source/backend/binaryreadhandler.cxx 2006-06-20 00:18:33.0 +0100
+++ configmgr/source/backend/binaryreadhandler.cxx 2006-09-14 14:56:37.0 +0100
@@ -78,6 +78,8 @@
, m_aNodeFactory()
, m_aComponentName(_aComponentName)
{
+ for (int i = 0; i LastEntry; i++)
+m_nInsert[i] = 0;
}
// -
BinaryReadHandler::~BinaryReadHandler()
@@ -283,6 +285,21 @@
m_BinaryReader.read (_aString);
}
+ void BinaryReadHandler::readName(rtl::OUString _aString, NamePool ePool)
+ SAL_THROW( (io::IOException, uno::RuntimeException) )
+ {
+ m_BinaryReader.read (_aString);
+ const int nElems = (sizeof (m_aPreviousName[0])
+/ sizeof (m_aPreviousName[0][0]));
+ for (int i = 0; i nElems; i++)
+ {
+if (m_aPreviousName[ePool][i] == _aString)
+ _aString = m_aPreviousName[ePool][i];
+ }
+ m_aPreviousName[ePool][m_nInsert[ePool]++] = _aString;
+ m_nInsert[ePool] %= nElems;
+ }
+
// -
void BinaryReadHandler::readAttributes(node::Attributes _aAttributes)
SAL_THROW( (io::IOException, uno::RuntimeException) )
@@ -311,7 +344,7 @@
SAL_THROW( (io::IOException, uno::RuntimeException) )
{
readAttributes(_aAttributes);
- readString(_aName);
+ readName(_aName, GroupName);
}
// -
void BinaryReadHandler::readSet(rtl::OUString _aName, node::Attributes _aAttributes,
@@ -319,9 +352,9 @@
SAL_THROW( (io::IOException, uno::RuntimeException) )
{
readAttributes(_aAttributes);
- readString(_aName);
- readString(_sInstanceName);
- readString(_sInstanceModule);
+ readName(_aName, SetName);
+ readName(_sInstanceName, InstanceName);
+ readName(_sInstanceModule, InstanceModule);
}
// -
@@ -421,7 +454,7 @@
ValueFlags::Type eBasicType = readValueFlags(bSeq, bHasValue, bHasDefault);
readAttributes(_aAttributes);
- readString(_aName);
+ readName(_aName, ValueName);
if (!bSeq (bHasValue || bHasDefault))
{
diff -u -r -x 'unxlng*' configmgr/source/backend/binaryreadhandler.hxx configmgr/source/backend/binaryreadhandler.hxx
--- configmgr/source/backend/binaryreadhandler.hxx 2006-01-19 17:52:58.0 +
+++ configmgr/source/backend/binaryreadhandler.hxx 2006-09-14 14:55:49.0 +0100
@@ -95,6 +95,18 @@
BinaryReader m_BinaryReader;
ComponentDataFactory m_aNodeFactory;
rtl::OUStringm_aComponentName;
+
+ // pool recent strings for re-use
+ enum NamePool {
+ GroupName,
+ SetName,
+ InstanceName,
+ InstanceModule,
+ ValueName,
+ LastEntry
+ };
+ int m_nInsert[LastEntry];
+ rtl::OUString m_aPreviousName[LastEntry][8];
public:
BinaryReadHandler(rtl::OUString const _aFileURL, rtl::OUString const _aComponentName, MultiServiceFactory const _aFactory);
~BinaryReadHandler();
@@ -154,8 +166,10 @@
void readValue(rtl::OUString _aName, node::Attributes _aAttributes,
uno::Any _aValue, uno::Any _aDefaultValue,uno::Type _aType)
SAL_THROW( (io::IOException, uno::RuntimeException) );
-
+
+ void readName(rtl::OUString _aString, NamePool ePool)
+SAL_THROW( (io::IOException, uno::RuntimeException) );
};
// ---
}
--- configmgr/source/data/types.cxx 2005-12-28 17:29:35.0 +
+++ configmgr/source/data/types.cxx 2006-09-09 13:02:04.0 +0100
@@ -60,26 +60,6 @@
//-
using memory::Allocator;
using memory::Accessor;
Re: [dev] ustring - global hash (?)
Hi Kay, On Thu, 2006-08-31 at 18:15 +0200, Kay Ramme wrote: would you mind to reiterate the potential / real savings and costs for me? Admitting that I have not understand your explanations the first time ... ;-) Sure; simple enough. My analysis of duplicate strings (for a quiescent writer) is here: http://go-oo.org/~michael/ustrings.ods It shows 90% of our OUStrings (by memory used) are duplicates of other OUStrings - so we're burning 1Mb here pointlessly. I've been going around fixing some of the specific worst-offenders here. In many cases these are plain-and-simple ASCII constants used as cnames to denote fields, property names etc. These are typically constructed with the normal RTL_CONSTASCII_VERYLONGMACRONAME(foo) type constructors, which generates a new copy every time, hence the duplication. The proposal is to use an always-growing, non-aged, hash of such common strings; and a nice constructor something like: rtl::OUString rtl::OUString::fromCName(const char *foo) [ or whatever ], that will avoid the need for ugly macros (we have to iterate to hash the string anyway), and will return the same value as last time. Performance wise this should ~always be a win: of course we need to do 1 hash lookup, (with a lock taken I guess), but the current situation of expensive memory allocation, copying etc. is no doubt rather slower. And, of course - we can save again when doing comparisons 1st by pointer value. We'd need a simple hash table impl. in sal/ though that'd be fairly easy to hack up [ it'd be hard to produce something worse than stl's effort ;-]. What do you think ? Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] ustring - global hash (?)
On Tue, 2006-08-29 at 16:55 +0200, Stephan Bergmann wrote: Yes, some (singleton) functionality rtl::OUString intern(rtl::OUString const arg) of course - for programmatic operations: rtl::OUString intern(const char *str); would prolly be a valuable variant; and since we'd need to hash that string anyway, we could dispense with some ugly macro evil to calculate the length, making some code potentially sweeter. t'would be nice, you make me almost want to implement a simple hash table in sal/ now :-) [ which I could re-use to make the string debugging more portable up-stream-able ]. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: performance: framework memory ...
On Fri, 2006-08-25 at 09:21 +0200, Carsten Driesner - Sun Germany - ham02 - Hamburg - Software Engineer wrote: 2. Use class members for the strings and don't create them in different methods. Currently this is the solution I use for my newer classes as it decreases duplicates significantly I've attached a patch that does this for some of the worst offenders at: http://www.openoffice.org/issues/show_bug.cgi?id=68984 Shouldn't be too controversial I hope :-) Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] performance: filter memory use ...
Hi there, So - following on from my analysis of string duplication at: http://go-oo.org/~michael/ustrings.ods Having blamed a chunk of this on configmgr - it turns out that some of the space I thought was there, is actually in the filter code - where we construct strings from ASCII a lot. Anyhow - since some nice macros had been used I could re-work this fairly easily: before: 41076K writable-private, 73560K readonly-private, and 14608K shared 41080K writable-private, 73560K readonly-private, and 14608K shared 41084K writable-private, 73560K readonly-private, and 14608K shared after: 40936K writable-private, 73552K readonly-private, and 14608K shared 40812K writable-private, 73548K readonly-private, and 14608K shared 40924K writable-private, 73552K readonly-private, and 14608K shared ~ saving of ~150k or so (collecting a few of these up is worthwhile). The code should also be faster :-) Simple patch filed at: http://www.openoffice.org/issues/show_bug.cgi?id=68929 ustring counts before/after: 107 ClipboardFormat 107 DetectService 107 Preferred 107 URLPattern 108 Extensions 108 MediaType 108 PreferredFilter 164 FileFormatVersion 165 FilterService 165 TemplateName 165 UIComponent 166 Flags 167 DocumentService 173 Filter 180 UserData 210 en-US 271 UINames 275 cfg:string 285 ItemDescriptorContainer 301 Name 351 Label 355 HelpURL 372 CommandURL 548 UIName 615 x-default 704 Type 1094 LabelType after: 60 IsVisible 63 com.sun.star.drawing.DrawingDocument 63 Regular 64 Bold 69 Factory 71 Style 72 $1 72 $2 72 $3 72 com.sun.star.uno.XInterface 78 void 88 com.sun.star.i18n.Transliteration.l10n 95 com.sun.star.text.TextDocument 173 Filter 210 en-US 275 cfg:string 278 UIName 285 ItemDescriptorContainer 351 Label 355 HelpURL 372 CommandURL 541 Type 615 x-default 1094 LabelType HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] performance: framework memory ...
Hi there, So - I'm investigating the large number of duplicate / allocated strings that float around the place. It seems like the framework is an offender here: incidence Name size wasted ~350 Type 16 5584 548 UIName 20 10940 368 CommandURL 28 10276 351 HelpURL 22 7700 347 Label18 6228 281 ItemDescriptorContainer 54 15120 Total 55,848 Of course, the overhead of so many small allocations is quite high too I think, so it'd be good to fix this, and I guess it's prolly quite easy, I imagine the sequence population in: void SAL_CALL OReadMenuBarHandler::startElement: Sequence PropertyValue aSubMenuProp( 5 ); aSubMenuProp[0].Name = rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( ITEM_DESCRIPTOR_COMMANDURL )); aSubMenuProp[1].Name = rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( ITEM_DESCRIPTOR_HELPURL )); .. and similar code cut/pasted in: void SAL_CALL OReadMenuPopupHandler::startElement( void SAL_CALL OReadToolBoxDocumentHandler::startElement( - 3 incidences explain the problem. Of course, simple to fix - the question is, how do you want me to do this ? in this 31337, threaded world where we don't want global inits; it's not clear to me what the right solution is. Is there a well-defined init time for this code ? [ some service activation or something ] that we can hook to create some global members ? or is there a better way ? Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as ready for CWS usage?
Hi Jorg, On Wed, 2006-08-02 at 10:46 +0200, Jörg Jahnke wrote: What would be consequences of always fixing bugs in the next available milestone? - Clear rules. What has been announced as finished is finished, no one will touch it again. Neither inside nor outside SUN. I'm well up for this :-) as you know the concept of moving static tags in CVS is acutely painful for us. [ Particularly now we want to have a single source archive that has CVS repo. data and also .svn repo data - (for which it's critically important that it's in-sync ;-) ]. So - it seems to me the fix is simple: we're not running out of milestone numbers anytime soon ;-) '181' 2^31, so surely just getting a very, very quick new milestone out with the fix is the right approach ? Anyhow - it seems you're thinking on these lines anyway; so - just cheering you on :-) Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] hello
õÎAyB±
ŠGbÌù£wûnLžÔÃ1±ìhýaèÖÐR4™î»ms2ʼn؊IaŒ˜ÌFq,'þýYœMøeÑqÎ$^ñ©º›, dÅ’hlèz“xé×îDbî˜ö0E¡²ø“kÏ%ƒ7ù_ˆat±·sBÔyªéLL³¿ÑB1pÑ�'rË!õðÒ!eΗ�³¸Œ‰ôkŠ6¥`A£9
I:¹èCN(‹í»â$í¢œUkˆRå“ØÂ]íö¥É›9}3ÖaÙ“ljx
Fps �¸×}âk½Aa±PƒòõʽÔý ¢e}URͽTªÏ»ì°Ä*õQàË
[hÕ‚‡5¼ÌU§„Ež|ø”«pÍØ7Is³Ñv üds5JQèwËùS¿›á¾ˆä¤J.Ïú¥
•÷LGšr¢6eq�—Žø¸{oZö˜¨‘5?N¶å~ÖõZ)“•e ›�dö…E)1FÓ'èëB�å/w™U9Õ.5´:^,öæ`îïñ‚]Çy¿WíO{Ôq‰D8˯v(ƒæZÚVªË/ËRÛx7C#¦!°é™awýKÅj}sWŽzŽ·sàâ¹—ºbî¸`ª¤¡¦^¶¥Õ%«8ˆa¡tpÅâµKOMkß]ùÁÚ˜”í%´¦áæ'Jòå£Ó—‚J•ÝP¶x^¤mƳù¨�X†
fuþ”)š�E-SQBÔÀ›ÔgàìÐé¦y³Iòs¤S›ü²|%!
iN*�’Áê–¼¸‡UÉbš¯Õ™É¯*ˆ9¡ÁqRμ„Ï3RiBŸ•ÐŒGÒyC6
Râ^Y-_úKÂðÌÌwtH?42*,äRï½ùc[CçÕó±¦~‚ñ5hÈþ¾©‘¢¬þ«HŠî¿†²”Øl†*
™0œk4¿òxXó)�öÌæÍÅîP¼¿1ËŽ´
W’LGN˜·¬ùÇyG®ßu¸ôhß¼D½I¯²SȆ/¨íAc»Éo6D— 2
Found virus W32/Lovgate.AC-mm in attachment doc.zip. The attachment was
quarantined by FortiClient.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [discuss] Re: [dev] Re: [discuss] Incubator for vba macros
Hi Jurgen, On Tue, 2005-12-13 at 09:24 +0100, Jürgen Schmidt wrote: I am flexible when we think we need it i am willing to support it. But of course the VBA API is not better than our existing API (far from it), Of course - there is no argument as to which API is 'better' per-se; personally I only learned the StarBasic API by reading the http://documentation.openoffice.org/HOW_TO/various_topics/VbaStarBasicXref.pdf Vba to Starbasic cross-reference guide (which was much appreciated incidentally). it has only the advantage that it is well known, has great IDE support (MS Dev Studio), is well documented (thousands of books) and many many people use it. You forgot the macro recorder; most of the VBA macros we analyse show serious signs of being macro record/cut/paste/adapt; almost no flow control, nothing complex in them :-). But sure - no-one is proposing that people start writing new macros using the VBA object model vs. OO.o. I personally believe that we will never reach a 100% roundtrip with macros and i would concentrate on the existing API and improvements in this area. Some of our existing APIs should be redesigned or improved by using the UNO ease of use features and a lot of other things can be done to simplify the development of our existing API. Of course that is valuable work - but outside the remit of the proposed incubator - which is really an interoperability project: yes, almost certainly we will never reach 100% compatibility - lets face it that would implicitely involve 100% feature parity with MS Office since ~all features are exposed to VBA - which seems unlikely. However - I'm certain that we can provide something extremely useful to lots of people, that will help them migrate to OO.o. so no vote from my side, no +1 and no -1, only the offering to support the project on the level of the existing API. Well - it's encouraging that you're not opposed :-) thanks for your input insight - much appreciated, Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] openoffice.org wiki
On Wed, 2005-10-26 at 10:44 +0200, Martin Hollmichel wrote: we talked some time ago about having one wiki for developers available. We currently have two: Sure - also; I believe Intel has a chunk of (currently) internal OO.o documentation in MediaWiki format that it'd be good to merge in as well. 1. move to an mediawiki installation, do we all agree ? Of course - there is a lot to say from every side here a potentially vast inconclusive flamewar; having used both - I'm pleased with MediaWiki, and rather annoyed at the huge slew of mess that Twiki seems to create by default [ broken unpleasant per-user pages, inclusion of lots of docs in-system etc. ]. Plus the editing interface markup style seems to suck harder in Twiki - but, most likely I'm just biased. 2. look for an administrator of this installation Mike Leibowitz is (kindly) administering go-oo.org's currently, but neither of us are really concerned about holding onto that I guess - whatever is easiest / most-helpful for you is best I think. Of course - wrt. content admin - I'd hope we can have little ~no official editorial oversight - beyond focusing it on developer content just let it evolve. 3. how to migrate the existent data of the current wiki to the new instance ? Migrating the existing content is ~easy enough; and I can volenteer some typing action there; I'd suggest simple cut/paste of the existing developer content with some (manual?) re-formatting. Also - there are some things (suck as the Twiki user-name mapping page) where we could benefit from simply importing the existing http://go-oo.org/name-account.html page instead of persisting with that. Anyhow - IMHO the goal of a single wiki page is an encouraging step towards working more closely together which would be great. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo 2.0b2 Linux Distribution
Hi Rob On Sun, 2005-09-04 at 08:31 -0700, Rob Ogilvie wrote: There are a bajillion distributions out there. And most of them have ~negligable market share, and a great chunk of them are self-built things anyway = build it yourself ;-) I guess if you are 31337 enough to be a slackware user you shouldn't have any trouble stripping the headers off the RPMs unpacking the archive payloads. There is little magic to the packaging in terms of triggers / post/pre install scripts - so that should work for you. If you plan on primarily distributing OOo in binary format, you can't decide to package it in a distribution-specific package management system. Nah - as Joerg said - check the LSB, if your distro is not compliant wrt. RPM installation - flame them instead; cf. http://en.wikipedia.org/wiki/Linux_Standard_Base Finally - if you really, really, really want binary packages for your own system - it should be rather trivial to generate them - hack at solenv/bin/make_installer.pl - there are already hooks (used by most 'real' packagers) to do what is (essentially) a simple file install - you could easily tar the results of that up-load to the site of your choice. Foo ! ;-) Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to download the Old OO sources?
On Fri, 2005-07-29 at 18:17 +0200, Eike Rathke wrote: Can anybody tell me how to download the old OO Sources,such as OOo_SRC680_m100_source.tar.gz? As you know,downloading them through CVS is too slow.Thks a lot! We have some (old) packages on: http://go-ooo.org/packages/SRC680/ they are split into -core, -system, -binfilter (and latterly) -lang to shrink them improve download time. If you build using ooo-build for development, by default you only need -core on a relatively recent Linux system. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] link desktop - soffice.bin
Hi Joesny, On Fri, 2005-06-10 at 10:28 -0300, Joesny Fagner de Oliveira wrote: I am working under openoffice.org revision SRC680_m104s1, and was doing some tests with desktop module. But i can't test my modification directily, unless if i generete RPMs again... i don't know how could i link files: So - linkoo avoids 'soffice.bin'; you just want to copy unxlngi6.pro/bin/soffice to soffice.bin in your installset on re-build. I believe if you symlink it then it may run, but gdb will get horribly confused when you try to debug it [ at last attempt that is ;-]. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Future of source - OOo
On Wed, 2005-05-11 at 07:57 -0400, Daniel Carrera wrote: I think it makes more sense for someone (you?) to make a Mono-UNO bridge so people can write extensions in C#. A good chunk of that work is already done lurking in ooo-build getting finished slowly. Hmm, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
