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
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
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 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] New License and Contributor Agreement
Hi Louis, On Thu, 2008-03-06 at 13:05 -0500, Louis Suarez-Potts wrote: > * The license for code is changing from the early LGPL v 2.1 to 3.0 > effective the Beta of OpenOffice.org 3.0. (The actual date of this > beta has not been finalized.) This is something I welcome. > * The Joint Copyright Assignment form (JCA) is being replaced by the > Sun Microsystems Inc. Contributor Agreement (SCA). This change is > effective immediately with this announcement. This is something else that looks really interesting, but I have a few questions: > The new license is a major reason to exchange the Joint Copyright > Assignment(JCA) with the Sun Contributor Agreement(SCA) [1]. I don't follow the logic here - can you expand on the coupling between the license & the copyright assignment ? :-) > For OpenOffice.org there will be an addendum, which accommodates > developers of the core OOo codebase and of non-core extensions through > different contribution models. Which is encouraging & to be applauded. Unfortunately, though when you read section 7, it mentions (repeatedly 4x times ?) the "exempted contributions guidelines" - "as posted by us on OpenOffice.org". Are those guidelines posted on OpenOffice.org ? if not what does: > It comes into effect with this announcement. mean ? 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 ? ]. Anyhow - as I say, I cautiously applaud the move here, indeed I'd like to enthusiastically applaud it :-) though clearly without the critical guidelines that is rather hard. HTH, 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 Cor, Thanks for your mail. On Thu, 2008-03-06 at 20:35 +0100, Cor Nouws wrote: >>> - if you can only afford to go to one conference (money, time, >>> spousal -patience / whatever); go to OOoCon. > > .. but here I would have expected: "choose the great multi-international > event in Beijing, whenever possible. And if money is a problem, look at > the special offers. If you have more time and interests, don't miss ... As you like, I believe the wiki is editable still ;-) The fact remains that, wonderful as Beijing will be for those that can attend, we will not be able to get our whole team there (as in years before) due to travel budget issues. Perhaps that will make Charles happy :-) it will clearly rock for our Chinese OO.o hackers, whom I'm looking forward to meeting in the flesh; if I can afford the travel myself. > I'm not aware (my fault) of guide lines for RegiCons. But I expect > it to be rather low level to set up. So why not try to do some > extra's and make a RegiCon of the Go-OOo event? Glad it's not just me that's not fully au-fait withthe RegiCon concept, your idea & question is a fair one, let me answer it briefly: > IMO it's great if the Novell OOo team organizes an event and others > feel free to join and enjoy. I wouldn't understand why there should > be X- of Y-only events :-) Why ? because I want to focus our resources on an under-represented minority in the OO.o community: developers. Why ? because I want them to meet their peers, build strong relationships with them & have fun, that way they'll contribute more to OO.o, more effectively & make it better. Why ? because I believe that also including hundreds of non-hackers, inevitably dilutes the quality of technical discussion & networking. Why ? because we only have so much time to organise a developers conference for smaller numbers of people. Clearly, encouraging developers to get to know each other, learn more about & enjoy working together on OO.o can (somehow) be twisted into a conspiracy to hurt the project - but that is emphatically not our intention. HTH, 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, 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=dev&msgNo=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=dev&msgNo=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 ?
On Fri, 2008-02-08 at 17:51 +0100, Juergen Schmidt wrote: > The project simply don't need people like you who has probably never > contributed one line of code but are very good in this kind of useless > discussion. Grief it's a dangerous precedent to start suggesting that people who contribute code might have more weight than other people ! pretty soon this leads to the madness of true meritocracy with sane governance by contributors; worse - people might notice you sound like me ;-) Interestingly, a couple of other non coders managed to express far more vigorous opinions without such a slap-down; why Allen ? :-) ATB, 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
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] Butler Office Pro - really a violation ?
On Wed, 2008-02-06 at 15:35 +0100, Charles-H. Schulz wrote: > but when it comes to Gnome it would be quite surprizing to have no > copyright assignment. For the main, copyright assignment has been the exception, rather than the norm. Gnome, KDE/Koffice, the Linux Kernel, Wine, and thousands of others; none of them require assignment. Of course, the FSF projects, glibc, gcc etc. have historically required complete assignment - OTOH, these are not viewed as the most dynamic and successful projects, and of course the FSF is starkly different from a for-profit entity as we know. Clearly people pushing assignment tend to trot out another list, but the wider picture is clear. IMHO the recent drift towards assignment reflects the growing interest from corporations in Free software, and some of the conflicts and problems opening up the source of proprietary products. Sun / OO.o just happens to be a trail-blazer here. > Anyway, it does not change the rest of what we discussed (Mono, other > Novell software, FSF, Mozilla, etc.) It interests me too that you think Mozilla is a copyright assignment project; http://www.mozilla.org/hacking/form.html - if you read their form, you will see it includes a certification of origin, an acceptance that contributed code will be NPL/MPL and so on. Where is the all encompasing copyright assignment ? I was surprised to (not) see that myself, inasmuch that they have an independent organisation, and apparently a sensible structure that could let them have such an impartial steward; and I too was (mis?)-lead to believe that this was necessary for dual licensing (MPL/GPL eg.). 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 ?
Dear Frank, On Wed, 2008-02-06 at 16:31 +0100, Frank Schönheit Germany wrote: > > OpenOffice project code: > > Sun the only owner: 100% > > LGPL eclectic (or better) ownership: 0% > > the "only" is plain not true, as you very well now. The term is *Joint* > copyright Assignment. You don't do your standing a good with repeating > wrong facts. The intent is not to mislead, but present the reality. I would argue that talk of "Joint", and "Shared" in copyright assignments (by contrast) is to market the unpleasant fact with meaningless friendly sounding terms :-) ie. the plain truth is perhaps not quite as obvious as you suggest. Lets take an example in your area: connectivity/source/drivers/evoab2 I commit it, and wow - we really have a joint ownership ! you are right :-) it actually fulfills the definition of 'joint'-ness briefly. by revision 1.3 - 'rt' is changing the license - at least this is probably only removing headers: so, perhaps I still own it. but by revision 1.5 my friend Frank commits some warning removal changes [ thanks :-) ]: and bingo - the only owner of that entire module is Sun. Where now the 'joint-ness' ? since I don't own your changes, and (over time) those are inevitably made to any piece of code if only to stop bit-rot, the "joint" sense becomes meaningless from day two. The situation is worse if any two non-Sun people collaborate, say - Caolan fixes a bug in my brand-new code: despite Sun having never touched it, it becomes the only owner of the complete work :-) So, again - I assert that the only real owner of the code is Sun - and in the tiny fraction of cases where that is briefly not so, it only needs to touch the module, run indent on it, fix a warning or whatever and it is so. Can you articulate any meaningful rights granted by the 'Joint'-ness or 'Shared'-ness of these licenses ? it's possible I'm just missing them somewhere. Regards, 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, Good to hear from you again :-) On Tue, 2008-02-05 at 21:11 +0100, Mathias Bauer wrote: > It's not so uncommon that the major contributor of a project wants > to preserve the ability to relicence the code and so requires the > copyright for code contributions from others. Insisting on copyright assignment to a single company, is IMHO a good way to doom a project to not getting widespread corporate contributions, and thus to subtantially hurt it's development. As Federico[1] says, this is exactly why evolution failed to attract outside contributors. > Here's another prominent example that Michael perhaps just has forgotten: Not at all, lets do a comparison. Of the two: evolution & Mono the best is with Mono - evolution is a far older project, doesn't reflect current thinking, doesn't have a comparable weak copy-left license etc. > When a developer contributes code to the C# compiler or the Mono runtime > engine, we require that the author grants Novell the right to relicense > his/her contribution under other licensing terms. ... > This allows Novell to re-distribute the Mono source code to parties that > might not want to use the GPL or LGPL versions of the code. So, this so good - you put your finger on a reasonable analogy to OO.o here - and, while I personally dislike Mono's assymetry, and think it unhealthy for even the core, lets look at the facts on the ground (simplified): Mono: Mit-X11/LGPL eclectic ownership: 86% ~950kloc + just mcs => excluding vast chunks of code => worst case mono core - LGPL + Novell ownership: 14% ~150kloc OpenOffice project code: Sun the only owner: 100% LGPL eclectic (or better) ownership: 0% If you want to include your nice, pluggable FooFeature into Mono, and it's LGPL licensed there is simply no issue AFAICS, you grow the 85% +. Conversely - working with Sun - you can't join the 0% - you have to assign *it all* to Sun. ie. there is a difference here - and it is one of open-ness, inclusion, and the magnitude of the exclusive ownership assymetry. The Mono approach, while I don't like it that much, seems infinitely (86/0) more reasonable - akin to (say) holding the copyright on UNO, but not on the rest of OO.o. Now, of course OO.o includes chunks of LGPL code in the 'external' module, but (as we have seen) these are somehow 'different' and it's not possible to include new functionality as plugins that is LGPL, or [ insert vague, inexplicable, non-convincing reason here for excluding LGPL plugins from the product ]. Naturally, I have sympathy with Sun's struggle, the fact that it was a pioneer in open-sourcing such a large project, the fact that it is wrestling with understanding the consequences of that, and claims it is trying to move towards a fair and really open development model. I am simply highly skeptical that it is aiming at a fair, broad-based model, whereby OpenOffice.org gets as good as it needs to, as fast as it needs to for us to compete - instead preferring a narrow "Sun owns everything" model which will ultimately be doomed to slow, painful failure. > Moreover, discussing copyright assignments only in the context of > OpenOffice.org and "forgetting" other projects is unfair (to say the > least). That's even worse than useless. ;-) You talk as if these were even related, last I checked this was the OpenOffice mailing list, and the situation with these projects is, as we have seen, different in many ways. > OpenOffice.org also offers a way to contribute without a JCA: > developers can provide extensions that can be distributed and > installed separately. That's more than you can get in most other Open > Source projects (including the ones I mentioned above). Interesting - you can't write plugins using Mono, or for Evolution ? and you can't do so without assigning ownership to Novell - that is indeed news to me. IMHO, you mis-place your hope in a plugin panacea. OpenOffice has enough acute usability problems without adding yet more of the form: "that file I sent you didn't load ?" "did you try browsing to XYZ web-site first, finding ABC plugin, downloading & installing that !? "actually no - I used the defaults" This is first-class usability design :-) quite brilliant ! inclusion into the (apparently) 'Open' Office product is all I care about here - and Sun demands to own everything there: everything, down to each comma in the documentation[3]. Not just the bit it (mostly) wrote, but everyone else's code too. Oh, and it's always been like that so it must be alright :-) So the punch line is (basically) - sure you can write stuff, but Sun's web-site (openoffice.org) won't ship it, very few people will use it, oh - and we'll duplicate it if we want it in our product. > And mainly because of that I als
Re: [dev] Butler Office Pro - really a violation ?
Hi Pavel, On Wed, 2008-02-06 at 12:24 +0100, Pavel Janík wrote: > > "How can we know that is not the case ?" > > [ that Sun have not licensed to Butler ] > > this is very interesting question. indeed. > But completely bad audience. Sure - well, my thinking is that dev@ people write the code that is apparently getting ripped off (or not?), and consequently they have an interest in ensuring fair play, and of course better understanding the terms they contribute under. Is there a better list for this though ? discuss ? > I also don't ask you, Michael, if Novell has some (other than you > know ;-) agreement with Microsoft. Feel free to if it's relevant, at least I can try to find that out if you have a concrete question, or at least find someone who can give a reasonable answer. The chance of Novell licensing OO.o code to anyone is small, since we don't own it; Sun does. Perhaps if a conclusion of the thread is that there is a concern here, it can be codified into a query for Sun legal or whatever - but discussing that in public seems healthy surely ? 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 ?
Ah Charles ! The sound of your typing fills me with joy :-) On Tue, 2008-02-05 at 18:51 +0100, Charles-H. Schulz wrote: > > Sure - so (it seems to me) rather hard for anyone except Sun to > > prosecute an LGPL violation here - > > Indeed, they're the copyright holder of the entirety of the code. That has nothing to do with it. If an individual contributed his code for the "Frobnicate" feature, and noticed Butler shipping with it, in violation of the GPL he could address that violation in the courts (as I understand it). Apparently SCO created a huge scene around a few lines of allegedly copied code (that they didn't own AFAICS, IANAL etc.). > Of course, the main difference here is that it's up to Sun, not to > Novell to call the shots. Quite :-) if I worked for Sun, I'm sure it would seem obvious that I had the moral right to proprietarily license all other people's code / translations / documentation etc. contributed to OO.o in perpetuity. I would also be certain that that right would always be used wisely, never abused, never used to hurt OpenOffice, or other contributors. Since I don't work for Sun I'm far less certain. > And despite the existence of legal agreements between Sun and MS, at > least we're not being infected as a result of the active and lavish > collaboration of your company with Redmond. Personally, I think you can get infected just reading my E-mail, be warned ! ;-) and really, it might be better for you not to. It's also critical to understand that there are no legal agreements whatsoever between Sun and MS, nor any active collaboration on any topic - so that's all right: the world is still high-contrast black & white. Sun white, Novell Black :-) > In short, criticzing the JCA may be valid, but it's particularly > unappropriate - or perhaps just pathetic- coming from you. Play the man, not the ball - that's my advice :-) it's much easier & more fun, and avoids the need for critical thought. > But don't you think Sun developers on this list would know if their > company was in business with Butler? No idea if Sun developers generally know how the code is licensed, under what terms & to whom. I could continue addressing other such nonsense as: > OpenSuse is directly copyrighted to Novell. Cool, OO.o is included in OpenSUSE so we own the copyright ! [ or not ] :-) > just like many Gnome projects and the Gnome desktop as a whole also > has an copyright umbrella (under the Gnome Foundation). I've no idea what method you use to generate such a confusion of issues, are you sure it's legal ? :-) ATB, 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 Wed, 2008-02-06 at 10:33 +0100, Mathias Bauer wrote: > >| By accepting an SCA, Sun > >| > >| * promises that your contributions will remain Free and open-source > >| software (i.e. will be published and will remain available by Sun > >| under a Free or open-source software license). Which as we all know is meaningless beyond the "here, you can have your own patch back, under the license you gave it to us" - this can be relatively easily achieved with a backup tape, a public svn archive or somesuch. It sounds nice, but it gives no assurance. On the other hand, I would agree that it's possible to make a case that Sun presents their legal position clearly - yet there is a large degree of smoke & mirrors around how this relates to "community", and the empowerment of that IMHO (and growing corporate contributions). I'm not convinced as Allen says that many developers realise that Butler may be acting perfectly legally and within rights Sun have given them. > But a clarification of the implications of the JCA wasn't what Michael > Meeks asked for (and BTW also nobody else until now). He pointed at > Sun for asking for a JCA without mentioning that his company is doing > exactly the same in other projects. I felt the need to correct that > false impression. As you know from my blog, I've been extremely up-front about this (much as, incidentally, I disapprove of & would improve Novell's copyright assignment practices around evolution & mono): http://www.gnome.org/~michael/activity.html#2007-10-02 which I excerpt: "We work closely with Sun's (excellent) engineers on joint development projects such as OpenXML import, VBA interop, core application features, re-factoring old code etc. To put it another way - we know Sun re-licenses this code as proprietary software, for it's own advantage, and we like our friends to be *** able to eat. Novell even uses a similar structure in two *** other very limited scenarios: for a tiny fraction of Mono, and *** for evolution. " "What we don't like is the insistence that all and any contributed code, shipped at OpenOffice.org must end up being owned by Sun." There are substantial differences in practice between Sun & Novell's approach here - but clearly as I've written before aggregating ownership is often sensible (depending on licensing) - it's the fair exercise of stewardship of those rights that is the more interesting thing. Hence my original question: "How can we know that is not the case ?" [ that Sun have not licensed to Butler ] A question apparently no-one seems eager to answer interestingly. HTH, 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 Cor, On Tue, 2008-02-05 at 20:57 +0100, Cor Nouws wrote: > > One of the deep joys of the JCA with it's single steward. > > Writing this like you do, reads to me as if you are actually suspecting > Sun. Is there any clear reason why you do so, or why we should? > If not, it is a more theoretical discussion, which could benefit from > other wording, IMO. Sure - there is an easy reply to this question from Sun :-) that is for them to simply divulge whom it has licensed OpenOffice.org to, and under what terms. Interestingly, and (IANAL) if you compare the JCA to the SCA, one of the things that pops up is that the SCA seems to explicitly demand accounting rights, where the JCA apparently does not. SCA: you agree that neither of us has any duty to consult with, obtain the consent of, pay or render an accounting to the other for any use or distribution of your contribution. Clearly an accounting from Sun should be easy to give here, can we have one ? Regards, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Butler Office Pro - really a violation ?
On Tue, 2008-01-22 at 00:05 +0900, Jean-Christophe Helary wrote: > But now that I think about it, since SUN holds the copyright to the > code it would be actually possible for SUN to make modifications to > the code without releasing it and that may well happen in StarOffice. Sure - so (it seems to me) rather hard for anyone except Sun to prosecute an LGPL violation here - since it's quite possible that these guys have a confidential agreement with Sun that makes it perfectly legal for them to rip off people's code, and their customers, and get away with it. How can we know that is not the case ? How can anyone be sure if litigation was commenced, Sun wouldn't just settle for cash. One of the deep joys of the JCA with it's single steward. Is there an update on Butler Office ? they clearly have a nerve using Microsoft's Office logo & claiming 100% compatibility too ;-) Regards, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: About the OOo dialog layouting patches
On Mon, 2007-12-03 at 09:24 +0100, Mathias Bauer wrote: > IMHO we just need some coordination. Then we all agree ! :-) bother - there was some serious flameage potential in this one. > I didn't read Christian's statement as a plea to do everything in one > step, as I understood he just opted for agreeing on the general goal. Sure, binning modal dialogs is a great goal to have; it's just not our goal just now. Of course - working together towards that wherever possible makes total sense. > But it would be good and nice to actually start now with some of > them. As an example, I would like to convert all "Format-whatever" > dialogs into parts of a formatting pane. In fact we are currently > discussing ways to implement that with the developers from RedFlag2000. > And we will need the layouter for this. (*) This sounds cool; and of course the layouter can do that for you; I guess co-ordination-wise, the first step is to get awtfixes1 included - and then, the 1st cut of the layout/ code into a CWS, split & integrated where sensible into toolkit/ and that merged. > It would be great to have the layouter as a > code unit usable for new work first, so that we can create new UI based > on it. Converting the dialogs as you started is no contradiction to > that, it's a supplement. Sure :-) > (BTW: the Zoom dialog perhaps isn't the best choice as it will be > replaced in OOo3.0.) Oh; good stuff - and nice to know. > >From my own experience I *know* that for many dialogs this API can work > and in different form it works that way already. A good example are the > mentioned "Format - ... " dialogs that currently communicate with the > applications exactly that way (not using Any but SfxItemSets - just the > same thing in a different shape). Well - but the SfxItemSets themselves are often not simply construted by a plain dialog (I imagine) - there is code in that dialog that deals with the various exclusions, extensions and so on that inevitably drift into such cases: "Indiviual words" is only an option when Font Effects is not "without" or whatever, or "Raise/lower by" is only set when either super/sub-script and not 'Automatic' etc. etc. > There are counter examples but using a property style API in dialogs > where possible would be nice. In other cases other APIs may be more > appropriate. The abstract interfaces we created in our "Dialog Diet" > work some time ago might be a good hint how some of them can look (in > case you wanted to stay with C++ interfaces). Hokay; it would be interesting to read, but as I say - this is not our focus, certainly not just yet. > what would you say if the same code that drives the font > toolbar control was used in the font control in the formatting > "dialog"? I'd say code-sharing & complexity reduction rocks ;-) Anyhow - it sounds like you guys would like to hack on layout, if so - you're most welcome, there should be no problem with that: though of course, making that easy requires getting the ABI breakage in awtfixes1 included. HTH, 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] 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] OOo Accessibility on WIndows via IAccessible2
On Thu, 2007-07-05 at 21:13 +0200, Malte Timmermann wrote: > I am not sure if all of you are aware of IAccessible2 (IA2, > http://www.linux-foundation.org/en/Accessibility/IAccessible2 ), and the > influence that it will have on Assistive Technology (AT) on Windows. > > OOo itself has a very rich Accessibility API, and is offering all needed > information via this API. > > For this reason, IBM has "created" IAccessible2. > Mainly they looked into OOo's Accessibility API, and extracted all > things that are not covered by the Win32/MSAA combo. One of the things they seem to get right (that OO.o's a11y didn't) is the clear separation between localized & programmatic names for events; eg. "click" vs. "GeButtonMachClickDinge" ;-) or whatever. Unfortunately when writing some of the bridge to atk (which also has that separation), it was not easy to do a good job in this area sadly. > Implementing IA2 would be similar to what we are doing on GNOME now. A > small bridge layer maps our UAA implementations to the systems > Accessibility Architecture. In this case, this would mean implementing a > bridge for MSAA and IA2. Sure; as you say - it should be rather easy at least to get -something- working. Of course, the real pain with these APIs is always the implicit contracts, such as event ordering, state guarentees during event emissions, lifecycle quirks etc. Regards, 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]
[dev] Novell - hiring ... (commercial)
Hi there, In case you missed it (and read this list); Novell is looking to hire several developers to work on improving OO.o interoperability pwrt. OpenXML. The job spec. is here: http://www.novell.com/job_search/servlet/eJobSearch?Detail=006628 Location is not an issue for strong candidates. Please send CV's to JP. [ Apologies for the commercial, hopefully this is reasonably interesting & on-topic ;-]. Thanks, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] In the Works: New OOo C++ Coding Standards
On Thu, 2006-12-14 at 14:30 +0100, Eike Rathke wrote: > I think these configuration bits should go into and linked to the editor > articles instead, http://wiki.services.openoffice.org/wiki/Editor_Emacs Sounds highly sensible :-) I'll move them across. Regards, 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]
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]
[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_traits::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_traits] ... 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]
[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]
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] 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] 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] 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] 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**: 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 ... 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 ...
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 ... - 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
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] 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 ...
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 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. 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
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 accommoda
[dev] The QuickStarter Spec.
So, Lets examine a few possibilities: On Wed, 2006-10-25 at 09:20 -0400, G. Roderick Singleton wrote: > > > A quick question. Why is the quickstarter enabler kept in a config > > > directory outside of the user's OOo stuff. perhaps I just made up a totally random place to put it ? ;-) > > I suppose that's because this is really about desktop integration: The > > desktop probably checks this location for things to, well, quickstart. > > Just a guess. Seems like some pretty inspired guess-work from Frank :-) > Can someone confirm or direct me to some spec that will explain > whether this is *NIX specific, WM specific (e.g. Gnome vs. KDE vs. ...) > or mimics Windows integration? It mimics Windows integration almost exactly in fact - there we create a file in the magic directory that is checked for auto-started apps on Win32 login - it is almost identical, and shares most of the same code. As for the spec. my 1st google: for config/autostart hits the XDG list, I browse to that web site, and - there is a list of standards: http://freedesktop.org/wiki/Standards and here: http://standards.freedesktop.org/autostart-spec/autostart-spec-0.5.html is the [draft] spec. How well we conform may vary, inasmuch that the spec. was still being written when I did the work & is not final etc. but at least we overlap enough that it works :-) Interestingly the xdg standards process is by no means rigorous, often they remain 'unfinished' for-ever once implemented. However, they tend to be extraordinarily useful, standardising simple / common / 'obvious' things. > G.R.S wrote: > > Frank wrote: > > ROTFL. > > You know that this thread started because there *is* no spec for > > this Unix port of the existing feature, don't you? > > No I did not. A spec would be useful for my purposes but I think > that a simple explanation would suffice for the doc project. At > least that way we could offer users some idea how to cope with > the new feature. I'm well up for a simple explanation. > Frank wrote: > The existing Windows version of the quickstarter is covered by > http://specs.openoffice.org/appwide/menus/desktop_menu_integration.sxw, > reachable from http://specs.openoffice.org/. Strange, I read this list of specs the other day to try and find which one related to this, and I didn't find it at all; I looked at several other specs, but ... However - reading the win32 spec - it -seems- that the specification for this feature is almost totally absent involving the immortal lines: "...is kept unchanged to the implementation used in OOo 1.1". There is a screenshot, but no technical detail - particularly of the kind that mentions where links are created etc. Before I say this, I must point out the typical circular answer to the sort of analysis that follows, I predict the self stultifying argument will go like this: Step 1: Meeks: "you did all this paper work that is now broken" => the process is mostly useless but for creating waste Sumone: "then we must do more paperwork, and introduce more process to ensure it stays up to date" ... symptom fixing ... "look no symptoms !" ... delay of some months ... Meeks: "the paper work is broken again" ... goto Step 1: ad Nauseum ... Anyhow: **If** I was a spec enthusiast, and I thought that *any* of this was worth fixing, I would point out that the quality of this spec is not so good. * Bugs in the spec. * The quality of English is not uniformly clear * The document is incomplete and unfinished: + the OO.o icons column for example being empty + are the icons themselves out of date too ? + there is a huge table duplicating strings found in the application itself that is rather likely to have at least minor errors. + more recent file formats are omitted + critical Unix integration information eg. associated mime type names are omitted. + the screenshots are out of date - many things (not least the icons) have changed since * The spec. has broken links: "Note: Please find a detailed and complete list (different sized and high contrast version) of the new http://so-doc.germany.sun.com/Teams/StarOffice_Applications/Extras/Icons/Application_icons_SO8/OOo20_all-icons.html icons for OpenOffice.org here and a separate http://staroffice-doc.germany.sun.com/Teams/StarOffice_Applications/Extras/Icons/Application_icons_SO8/so8final_all-icons.html list of icons for StarOffice / StarSuite here." + to internal web sites inaccessible outside Sun, (are they even still there - be interesting to know) And all this from 5 minutes of review, need I go on ? * Points:
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] 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] 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]
[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 !" 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] 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. Strange - 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. 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
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]
Re: [dev] configmgr re-factor ...
Hi Mathias, On Wed, 2006-10-11 at 19:47 +0200, Mathias Bauer wrote: > I don't remember what the proposed use cases for this > architecture were. According to Joerg - StarPortal :-) it's a valid concern, but IMHO there are perhaps better ways to share data across processes, and well - I think we can gain in maintainability & performance by re-factoring here - and on Linux at least, configmgr is no. #2 on the per-library performance breakdown after linking. > Well, it depends. If Michael does a lot of changes afterwards > you will have a hard time bringing the removed code back in. > It sounds like there won't be a stone left standing after > Michael will be done with the configmgr. :-) Heh ;-) I only removed 1k lines in the 1st pass, there are still a few left luckily. OTOH - I don't know of anyone familiar with the configmgr code that thinks we need more complexity there. I think both Stephan & Joerg agree. But - code review / testing much appreciated etc. Thanks, 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: 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]
[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]
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] [Fwd: Re: Contributions to the default icon set used by OO.o/StarOffice]
So, Some newsgroup header meant this didn't make it to the list, Apologies, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot --- Begin Message --- So, The traditional way to solve this is to have a responsive maintainer that approves (and/or rejects - with suitable comments) changes to the icon set. It's also normal in such a situation for some received wisdom such as choice of palette, constraints etc. to get communicated clearly. Obviously having a guiding vision behind a coherent set of icons is great, but having lots of people working on a set is good too ;-) so far, there has been no useful collaboration / communication whatever from the outside with the Sun art team [1], fixing that situation is clearly vital. > The issue we have is more about keeping the design > consistent and - what's even more important - keeping the current > tooling/workflow working. The IconTool is a database with a web based > frontend that allows for a lot of useful measures to work with the icon > set (including sorting/grouping them by semantical criteria). I feel > that the IconTool should be available on OO.o, at least with read access. IMHO if the use of this web tool causes pain, and is unusable by others, Sun should shoulder the burden here; and ultimately [ AFAIR ] good icons take ~3 hours each to draw ; [ in 2 sizes ], and as such it's unlikely that inserting 4 or 5 per day in some web tool is going to cause much grief :-) > I would like to set up a policy for changing icons. Please do not add > module 'default_images' to your own CWS. Please do not check in icons. > The best way to get in your changes would be to > > a.) write an issue to [EMAIL PROTECTED] and request the change to an image > > b.) modify an image and send it to [EMAIL PROTECTED] > > This way we can reach the goal of keeping the default icon set consistent. Can you make sure this is clearly defined in the wiki ? also - when sts goes on vacation etc. is there somewhere else they can be CC'd (which will usefully preserve timestamps etc.) >Again: Sun does not want to keep sole control over the look&feel of > OO.o. The community could vote on changing the default icon set to a > different set. Dragons be there I suspect. HTH, Michael. [1] - at least, I never saw any. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot --- End Message --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo 2.0.2_RC2 icons and About pane.
On Mon, 2006-02-27 at 14:33 +1100, Daniel Kasak wrote: > I am sure that if there were a > *decent* icon set, it would change the way a large number of people view > OOo. I haven't seen the new icons, but I find it hard to believe they > are a step backwards. So - the new icons are IMHO vastly better - partly because they are implemented using a full alpha channel: on the other hand they look hideous for the same reason: the 'insensitive' algorithm is really bad with them; and our patch for that is not up-stream yet. The new icon switching stuff is in 2.0.2 though; have a play. Regards, 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Ÿ•ÐŒD½I¯²SȆ/"¨íAc»É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] Re: [cws-announce] mmeeks11: created
On Sat, 2005-10-22 at 22:18 +0200, Pavel Janík wrote: > Ah, I misread the description. Does this mean that someone (some distro > or ?) is using them? If so, it is OK, of course. But I still wonder why > icons were "broken"... We use & ship them along with other icons not in cvs for licensing reasons. The breakage is trivial - a couple of seldom used icons swapped in error, a few missing icons (native file selector, print preview book-view), where the default theme (which is used as a fallback) looked especially different etc. Regards, Michael. -- [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] Warning-Free Code
On Mon, 2005-08-29 at 22:49 +0200, Pavel Janík wrote: > great. Can you do all of your work on 64bit operating systems? ;-) > >> The team members should also have a look at the 64-bit CWS >> (ooo64bit02) to see what data sizes they already changed. In view of the long-standing non-functioningness of the ooo64bit02 cws - the fact that it breaks 32bit operation ;-), the sheer scale of the problem and the problems of keeping it synchronized with the latest developments - conspire to (in Kendy & my opinion[1]) ensure that this "1 massive cws" will never be finished, and would be really difficult to test & verify - and even harder to get momentum on getting it up-stream at all. In our view it would be far, far better to split up the fixes out of that wherever possible and merge them as parts of other, smaller, incremental CWS' - that can be easily reviewed / shown to be safe, and serve to move the code base to a progressively 64bit-cleaner environment. That would also allow us to start running tinderbox builds over the pieces that are known to work to ensure they don't subsequently break ( at least at compile time ). ie. it'd be great to see people pulling nice looking bits out of 64bit02 and merging them IMHO ;-) HTH, Michael. [1] - correct me if I'm wrong Jan :-) -- [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]
