[dev] Quickstarter quirks (was: [dev] Specification Process Possibilities ...)
Hi Michael, 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 ]. Well, what I by semi-purpose :) did not mention so far is that I did not do a real installation, instead I just unpacked the RPMs. This is similar to what Ingo recently introduced with the archive format of the installation sets: A big zip just containing all files in the proper structure, which can be extracted and run. The fact that it's run at first start is probably caused by some higher layers. At least my experience on Windows is similar: When you do an administrative installation there (which effectively means: simply unpack the installation set, very similar to what I've done on Linux), then the quickstarter is enabled on first start, though it's not yet part of the AutoStart group. In short: There seems to be some higher-level configuration entry, defaulted to true, which tells to run the quickstarter, and which hits you when you do an unpack installation. I suppose this is what I saw on Linux, too. Any ideas ? what's in that directory ? and/or does it exist ? what are the permissions ? Hmm. It's a link pointing to some other CWS' installation (which does not exist anymore). Removing it (and my user data) gave me the quickstarter, again, created a new link (to my current version), and now the QS comes up whenever I start OOo. Also, now the option in tools/Options works as expected. Hmm, no, not as expected - from the wording, I would expect that the QS is started immediately. Okay, like specified. Ooops. :-P Anyway, seems the old link caused the problem. I suppose this is something which more people might be bitten by: at least developers doing 10 installations per day (or so), and those brave people always trying the latest developer snapshot. could you open an issue? Is installation by unpacking something you intend to support? Also, how can I encounter/verify this issue now that we disabled it in normal builds? :) 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 ? Linux (SuSE). Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] UNO STL
Eike Rathke wrote: Hi CLAIRE,, On Monday, 2006-10-23 16:16:09 +0100, CLAIRE, Narinder, Group Risk Mgmt wrote: When Building an uno component in C++ with a Makefile taken from one of the examples in SDK, which STL is visible, the native STL or STLport ? STLport. If STLport , then if the uno component links to a third-part library calling funtions that return or recieve STL containers, must that third party library also be built with STLport ? Yes. Generally you can't mix container objects of different STL implementations, as their implementation details may differ and especially iterators of one implementation working on containers of another implementation will most probably not work, or crash at its best. - If you can separate the third-party library STL usage from the SDK-related STL usage (e.g., by introducing an additional library that wraps the third-party library and does not use STL in its API), it *might* work to have two different STL implementations in the same process. - Similarly, if you do not need any of the STL-using API of UNO (parts of cpppuhelper, IIRC), it *might* work to tweak your SDK-based project to not use the SDK's STLport, but use another STL implementation instead. But all that is rather fragile and there are no guarantees. -Stephan Eike P.S.: As you're not subscribed to the mailing list you were posting to, you will miss replies that are directed to the list only. When answering, please reply only to the list (Reply-To header is set), not to my personal account. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ...
Hi Michael, 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. ... 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). What should I say - that's not the way it should be, that's not the way I expect it to be, and that's not the way I've been briefed to go. I agree with you that those hurdles experienced by contributors are a big reason for not attracting more developers. However, I see chances that we get changes to the better here, since my personal impression is that the awareness for all those hurdles, and the fact that they prevent a growing community, is raising. All I can seriously recomment is: keep fighting. Both for people from outside Sun as well as inside Sun :). 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. Continue persuation :) 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. 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. That if Sun QA wants to include all this process for Quality reasons, then -it- must shoulder the burden [ at least for volunteer contributions ]. ... 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. 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). 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. 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. You might want to question this idea and policy, but please not by silently undermining it. Having a formalised process (1 paragraph necessary?) for quickly including code into OO.o that is disabled in all Sun builds, and quickly getting fixes / changes into that etc. would be much appreciated. This is something we have been wanting for some years now; but no action. That's still not the way to go here. What I personally dislike about our specification/iTeam processes is the fact that a specification is a fire-and-forget thing. Unless we embed this into a context (e.g. a document management system which helps us keeping documents up-to-date, searchable, and
Re: [dev] Specification Process Possibilities ...
Michael Meeks wrote: [...] Having a formalised process (1 paragraph necessary?) for quickly including code into OO.o that is disabled in all Sun builds, and quickly getting fixes / changes into that etc. would be much appreciated. This is something we have been wanting for some years now; but no action. [...] Please do not go that way. In my opinion, we already have more than enough lines of code in general, and more than enough #ifdef-like lines in particular. We should attempt to keep those numbers small. It should be an exception to include something that is disabled in every standard build. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Wiki Extension: ParserFunctions
Stefan, Stefan Taxhet wrote: But I didn't take the time to read on and bother about '#'s and '#if's. could you do at least the fix regarding the 'if'? Otherwise it is unusable (and worthless :-( ). Greetings Stefan Thanks Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ...
Hi Michael, them: We need this burdensome process for Higher Quality ! us: But lets face it quality is still not good them: Then we need -even-more- burdensome process ! repeat ad nauseum. Nobody said, that it is needed to include _burdensome_ processes to get a higher quality. If all people who worked on such a big and complex project like OpenOffice.org could take enough care of quality on each new integrated code quality assurance, other control mechanism or processes are not needed. And there isn't a difference between new feature or a bug fix. But in the past years especially _I_ learned, that it is easier to bring in a mass of new features as to bring in stability and high quality into the product. The project OpenOffice.org is too complex, that somebody can have an overview about all dependencies. Because of the hard work to get a higher quality from one Update to the next one, some leaks in work flows were identified. And to avoid the such problems some processes like the New Specification Template were introduced. 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? 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. We still have problems in special areas, where people can say OpenOffice.org is still in Beta status. But the general work for private and business use the Office has a very high quality. I think this is one reason why OpenOffice.org is so successful. 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? That if Sun QA wants to include all this process for Quality reasons, then -it- must shoulder the burden [ at least for volunteer contributions ]. That's not the point. It isn't possible to check the quality of all integrated code by the Sun QA team. Therefore processes are defined (e.g. how to approve a CWS), that every community member and developers can help here. If there aren't any definition or tools to help making QA, it will not be possible to handle so much code changes. 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. If the quality of the code is bad, the QA cannot make out of it a good product. So the code must be better and the documentation about the changes, because then regression testing is more efficiently. That's one reason why the specifications are needed. Having a formalised process (1 paragraph necessary?) for quickly including code into OO.o that is disabled in all Sun builds, and quickly getting fixes / changes into that etc. would be much appreciated. This is something we have been wanting for some years now; but no action. 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? I heard some customers and they told, that they want to have higher stability and higher quality. But you will be right, additionally they said, they want to have feature xyz. But often these are features, which are very special for they needs and has nothing to do in an open source project like OpenOffice.org. That's why Sun and other companies make an own brand of OOo. Regards, Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ...
Hi, Frank Schönheit wrote: However, what I really *really* like about this process is the exchange of ideas and arguments. I respect the process. I encourage community developers and CJK developers to access the spec project wiki [1] and the spec template [2]. http://specs.openoffice.org/servlets/ReadMsg?list=devmsgNo=59 http://specs.openoffice.org/servlets/ReadMsg?list=devmsgNo=83 Can you help fix them? I hope you are subscribing [EMAIL PROTECTED] :) Thanks, khirano [1] http://wiki.services.openoffice.org/wiki/Category:Specification [2] http://specs.openoffice.org/collaterals/template/OpenOffice-org-Specification-Template.ott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning: operator += enforces hidden conversion
Hi Bjoern, Bjoern Milcke schrieb: I came across the following piece of code: String a; xub_StrLen n = 0; n += a.Len(); This breaks on Windows (due to -werror). Because of the warning: warning C4244: '+=' : conversion from 'int' to 'USHORT', possible loss of data (in the last line of the fragment) By the holy standard, x += y where x, y are short works by promoting x, y to int x', y', adding x' + y', converting int x' to short x'' and assigning x'' back to x. MSC chose to warn about this (about the potentially lossy converting int x' to short x'' part). I still think this warning doesn't make sense. Indeed this might be an undesirable or at least discussable decision in the C++ standard, because it is counter-intuitive. However it is well possible (I haven't researched about it in-depth), the decision to promote most values to at least int-size in arithmetic expressions, has resolved a lot of other problems, the standard would have faced otherwise. IMHO a usable solution would be: Compilers should not warn, or at least give the warning a different id, if all participants in such an expression have the same original type which the compiler in many cases should be able to recognise. If more projects follow the example of OOo (and probably a few other projects) to produce warning free code, hopefully in a few years compiler-manufacturers are more aware of such problems. ;-) Nikolai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Kazunari Hirano wrote: Hi, Frank Schönheit wrote: However, what I really *really* like about this process is the exchange of ideas and arguments. I respect the process. I encourage community developers and CJK developers to access the spec project wiki [1] and the spec template [2]. For issue 12719 I attempted to have a faster and more accessible specification process This involved developing the spec collaboratively in the wiki Unfortunately the spec team did not like this idea and have gone for an OOo template for designing specifications with This is perhaps better than the previous system, but I think there are still significant cases where using a wiki is a much faster route for people (particularly outside contributors) to use to collaboratively produce a specification. Unfortunately I did not have time to pursue this idea; fortunately the Sun team that took over the issue did look through our wiki-based spec and hopefully included some things - the issue is now fixed which is nice :-) But I would like to propose that this approach to spec generation be given more thought. Reasons: 1) Wikis are designed for this 2) It is easier for a person not heavily involved in OOo to go to a wiki page, make a few changes, edit it, and submit, then it is to get a document out of version control etc, open it in OOo, change it and submit 3) The spec process is apparently working well for those inside Sun, less well for those outside. If there were an easier route for those less involved in development to produce specs it could be run concurrently as an alternate mechanism (possibly with a final step of converting to the required template format, that could be automated) 4) This would perhaps be particularly helpful for outside contributers who are not coders 5) Less likely to break due to problems in the OOo template macros :-) This was done by having a wiki template that could then be filled out to produce the spec. Thoughts? David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Quickstarter quirks (was: [dev] Specification Process Possibilities ...)
On Wed, 2006-10-25 at 08:45 +0200, Frank Schönheit - Sun Microsystems Germany wrote: Hi Michael, [snipped] Hmm. It's a link pointing to some other CWS' installation (which does not exist anymore). Removing it (and my user data) gave me the quickstarter, again, created a new link (to my current version), and now the QS comes up whenever I start OOo. A quick question. Why is the quickstarter enabler kept in a config directory outside of the user's OOo stuff. I ask because when using m187 I turned off the quickstarter and disabled the start up option and your hint in another message poked my nose to locating this other directory. Here are some specifics: 1. FC5 and Gnome 2. OOo680m187 (Pavel) 3. .config in my $HOME contains: .config: total 36 drwxrwxr-x 3 gerry gerry 4096 Oct 24 13:51 . drwxr-xr-x 163 gerry gerry 24576 Oct 24 23:16 .. drwxrwxr-x 2 gerry gerry 4096 Oct 24 13:51 autostart .config/autostart: total 8 drwxrwxr-x 2 gerry gerry 4096 Oct 24 13:51 . drwxrwxr-x 3 gerry gerry 4096 Oct 24 13:51 .. lrwxrwxrwx 1 gerry gerry 47 Oct 24 13:51 qstart.desktop - /opt/openoffice.org2.1/share/xdg/qstart.desktop Once I found the directory, I was able to get OOo to re-enable qs by simply using $touch qstart.desktop -- G. Roderick Singleton [EMAIL PROTECTED] OpenOffice.org smime.p7s Description: S/MIME cryptographic signature
Re: [dev] Possible exploit potential in openoffice
Caolan McNamara wrote: On Wed, 2006-10-25 at 13:58 +0200, Stephan Bergmann wrote: After some analysis I just filed http://www.openoffice.org/issues/show_bug.cgi?id=70840. However, that issue is probably specific to OOo as built by Sun (and available for download from the OOo web site). If your OOo at /usr/lib/openoffice is instead built by some Linux distribution, your problem could be another one (if libuno_sal.so.3 is not RWX for you, it might also be that issue 70840 only addresses a first problem, and we have to address further problems once that is fixed). Also, we really should also add... .section.note.GNU-stack,,@progbits to the end of bridges/source/cpp_uno/gcc3_linux_intel/call.s similiar to the line at the end of bridges/source/cpp_uno/gcc3_linux_x86_64/call.s Yes. Can you file an issue? over here we just run execstack -c .../program/libgcc3_uno.so during packaging to workaround it C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Quickstarter quirks
Hi Gerry, A quick question. Why is the quickstarter enabler kept in a config directory outside of the user's OOo stuff. 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. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Possible exploit potential in openoffice
On Wed, 2006-10-25 at 14:53 +0200, Stephan Bergmann wrote: Caolan McNamara wrote: Also, we really should also add... .section.note.GNU-stack,,@progbits to the end of bridges/source/cpp_uno/gcc3_linux_intel/call.s similiar to the line at the end of bridges/source/cpp_uno/gcc3_linux_x86_64/call.s Yes. Can you file an issue? http://www.openoffice.org/issues/show_bug.cgi?id=70845 C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Quickstarter quirks
On Wed, 2006-10-25 at 15:08 +0200, Frank Schönheit - Sun Microsystems Germany wrote: Hi Gerry, A quick question. Why is the quickstarter enabler kept in a config directory outside of the user's OOo stuff. 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. Okay. Sounds reasonable. However, this new feature needs to be documented so I am looking for confirmation that your guess is so. 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? TIA -- G. Roderick Singleton [EMAIL PROTECTED] OpenOffice.org smime.p7s Description: S/MIME cryptographic signature
Re: [dev] Specification Process Possibilities ...
Hi Thorsten, Thorsten Ziehm schrieb: Hi Michael, them: We need this burdensome process for Higher Quality ! us: But lets face it quality is still not good them: Then we need -even-more- burdensome process ! repeat ad nauseum. Nobody said, that it is needed to include _burdensome_ processes to get a higher quality. [...] danke für das ganze Posting, das IMHO das Wichtigste genau auf den Punkt bringt! Ich hoffe, daß derselbe Aufwand, den Du ins Schreiben gesteckt hast, auch fürs Lesen aufgewendet wird. ;-) Gruß, Nikolai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ...
On 10/25/06, Nikolai Pretzell [EMAIL PROTECTED] wrote: Hi Thorsten, Thorsten Ziehm schrieb: Hi Michael, them: We need this burdensome process for Higher Quality ! us: But lets face it quality is still not good them: Then we need -even-more- burdensome process ! repeat ad nauseum. Nobody said, that it is needed to include _burdensome_ processes to get a higher quality. [...] danke für das ganze Posting, das IMHO das Wichtigste genau auf den Punkt bringt! Ich hoffe, daß derselbe Aufwand, den Du ins Schreiben gesteckt hast, auch fürs Lesen aufgewendet wird. ;-) Gruß, Nikolai I hope you realize that this post of yours also made it into the mailing list due to the Reply-To munging. :-) Einen guten Tag haben! (via Google's translation :-) Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ...
Hi Hirano, I encourage community developers and CJK developers to access the spec project wiki [1] and the spec template [2]. http://specs.openoffice.org/servlets/ReadMsg?list=devmsgNo=59 http://specs.openoffice.org/servlets/ReadMsg?list=devmsgNo=83 Can you help fix them? I just sent a ping to the responsible person :), asking whether he would agree that it is a bad situation those mail are unanswered. I hope you are subscribing [EMAIL PROTECTED] :) Yes. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Quickstarter quirks
Hi Gerry, Okay. Sounds reasonable. However, this new feature needs to be documented so I am looking for confirmation that your guess is so. 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? ROTFL. You know that this thread started because there *is* no spec for this Unix port of the existing feature, don't you? 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/. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
David Fraser [EMAIL PROTECTED] writes: ...but I think there are still significant cases where using a wiki is a much faster route for people (particularly outside contributors) to use to collaboratively produce a specification. Seconded. A wiki has a low barrier for entry, can cross-link/refer to/include verbatim other specs or documentation on the 'net, can be edited collaboratively - and, probably the biggest pro currently, can be searched in with whatever search engine you like. What's more, a wiki more explicitely expresses the fact that a spec (or feature documentation - a lot of the things we're currently calling 'specs' are actually after-the-fact documentations) is never finished, but a living document. I'm all for this, and David and others have set an excellent example that it actually works. Just my 2 cents... -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Quickstarter quirks
On Wed, 2006-10-25 at 15:52 +0200, Frank Schönheit - Sun Microsystems Germany wrote: Hi Gerry, Okay. Sounds reasonable. However, this new feature needs to be documented so I am looking for confirmation that your guess is so. 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? 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. 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/. So you are saying the *NIX version behaves in exactly the same way? -- G. Roderick Singleton [EMAIL PROTECTED] OpenOffice.org smime.p7s Description: S/MIME cryptographic signature
Re: [dev] Specification Process Possibilities ... what about a wiki?
Hi David, For issue 12719 I attempted to have a faster and more accessible specification process This involved developing the spec collaboratively in the wiki Unfortunately the spec team did not like this idea and have gone for an OOo template for designing specifications with This is perhaps better than the previous system, but I think there are still significant cases where using a wiki is a much faster route for people (particularly outside contributors) to use to collaboratively produce a specification. ACK. A spec is a living document, I don't think it's reasonable to expect it can be written from scratch in a perfect shape. A Wiki is much better suited to reflect this permanent change. This doesn't mean we can't freeze the spec once all stakeholders agree it's final, or call it make a snapshot, by moving the Wiki content to a .odt at some time. But I would like to propose that this approach to spec generation be given more thought. +1 I don't think that's the best approach for all cases, but certainly a good one for some. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Hi David, *, David Fraser wrote: [...] 3) The spec process is apparently working well for those inside Sun, less well for those outside. If there were an easier route for those less involved in development to produce specs it could be run concurrently as an alternate mechanism (possibly with a final step of converting to the required template format, that could be automated) [...] I happened to work with the specification template recently.[1] I didn't find that too difficult. Indeed, I was not unlucky like the posters on the list, encountering problems with the macro's. And I won't say the it is perfect. But other aspects of realising a new feature, give me much more problems than the spec-template. Futhermore, what use would people not heavily involved in OOo have in making specs? Regards, Cor [1] http://www.openoffice.org/issues/show_bug.cgi?id=20386 -- Cor Nouws Arnhem - Netherlands nl.OpenOffice.org - marketing contact - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] cpu looping in cupsd and soffice.bin
Hi, I experience exactly the same problem like you with cupsd and OpenOffice in a loop. I have also SuSE (OpenSuSE 10.0) and OpenOffice 2.0 (build 2.0.0.1). Any luck looking for help at SuSE? Randolf Andy Pepperdine wrote: On Monday 23 October 2006 14:42, G. Roderick Singleton wrote: [..] Andy, Have you checked with Novell or SuSE support? I ask because I cannot reproduce the problem under FC5 and cups-1.2.4. I'm not surprised that you cannot reproduce it; it looks like a very particular issue. But Suse is my next stop. Regards, Andy. -- View this message in context: http://www.nabble.com/cpu-looping-in-cupsd-and-soffice.bin-tf2482603.html#a7002663 Sent from the openoffice - dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] cpu looping in cupsd and soffice.bin
Joost Andrae wrote: workaround: The environment variable SAL_DISABLE_CUPS set to a value (eg. 1) disables cups use within OpenOffice.org. In that case you can manually configure your printers using OOo's printer administration tool spadmin which you can find within the program directory of OOo. Kind regards, Joost This work arround does nothing for me. I set this environment variable to 1, but still Openoffice loops with cupsd. Randolf -- View this message in context: http://www.nabble.com/cpu-looping-in-cupsd-and-soffice.bin-tf2482603.html#a7002861 Sent from the openoffice - dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Specification Process Possibilities ...
I would like some advise about when a Specification Document should be written. I have submitted quite a few enhancement requests for Writer most of which are at status=new, some of them have an assigned owner and some are still owner=requirements. I have 22 issues and enhancements submitted, and since the first, the historic 4292, in April 2002, one enhancement, I think, has been implemented. (my list of issues - http://qa.openoffice.org/issues/buglist.cgi?issue_type=DEFECTissue_type=ENHANCEMENTissue_type=FEATUREissue_type=PATCHissue_status=NEWissue_status=STARTEDemail1=dnwemailtype1=exactemailreporter1=1email2=emailtype2=exactemailreporter2=1issueidtype=includeissue_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=short_desc=short_desc_type=allwordslong_desc=long_desc_type=allwordsissue_file_loc=issue_file_loc_type=substringstatus_whiteboard=status_whiteboard_type=substringkeywords=keywords_type=anytokensfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=Reuse+same+sort+as+last+timeSubmit+query=Submit+query ) It is clear that if it were decided to implement a enhancement/feature it would speed up the process if I had written a specification document before hand. But would writing the specification document increase the the chances of the enhancements being accepted ? If no one is interested in the enhancement then no one will read the specification document and it will be a wasted effort? At what point in the QA process should one feel sufficiently encouraged to start writing the specification document ? Except for the bibliographic enhancement, no has ever asked me for more information regarding an enhancement/feature I have submitted. Or would producing a specification document at the start have help to reduce years of bickering and lack of resolve around some rather simple issues like Increase some field lengths in the bibliographic database @ http://qa.openoffice.org/issues/show_bug.cgi?id=16268 regards David -- --- David N. Wilson Co-Project Lead for the Bibliographic OpenOffice Project http://bibliographic.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specification Process Possibilities ... what about a wiki?
Hi Cor, On 10/25/06, Cor Nouws [EMAIL PROTECTED] wrote: Hi David, *, David Fraser wrote: [...] 3) The spec process is apparently working well for those inside Sun, less well for those outside. If there were an easier route for those less involved in development to produce specs it could be run concurrently as an alternate mechanism (possibly with a final step of converting to the required template format, that could be automated) [...] I happened to work with the specification template recently.[1] I didn't find that too difficult. Indeed, I was not unlucky like the posters on the list, encountering problems with the macro's. And I won't say the it is perfect. But other aspects of realising a new feature, give me much more problems than the spec-template. The spec template is just one aspect of the whole picture here. :-) The problem with the current specification process from my own experience and observation is that, it puts the wrong focus on the purpose that the project is intended to serve. In the ideal world, a specification is written to clearly define what a proposed feature is going to do, how it is going to work so that all involved parties (documentation, marketing, QA and development) can agree on how it is to be implemented before the actual coding starts. If it works as designed, it saves grief and unpleasant surprises from everyone, people involved from all different departments can schedule their work accordingly, and at the end of the day, everybody is happy. In a not-so-ideal world, things don't always go as planned. Requirements grow organically over the development life cycle of that feature, but the spec document may not always get updated. Once you have the first prototype, everybody's focus goes to that prototype and he or she makes his/her feedback based on that prototype, and based on that feedback, the developer continues to work on the implementation, demos it, gets further feedback, and it goes on until it reaches its final state. Ideally, the developer should also be responsible for updating the spec document to ensure that it keeps up with the requirement change over the development cycle. But such work is tedious, and it is easily neglected. Besides it being quite tedious, it is not clear at all (to my eye) how this large number of specification documents[1] are being used in the OpenOffice.org project as a whole, or people actually read them. I'd be glad to be educated in this area, and eager to learn how they are being used in actuality. I can give you my experience with writing a spec. I have written this specification[2] 2 years ago for a small feature I wrote for Calc. After I uploaded this document, the first feedback I received was (beside the very first encouraging and extensive feedback from Niklas[4]) a year later from one user who just happened to come across my spec document. He made a suggestion to change one aspect of how the algorithm works because he believed it was an error, but that happens to be a bug in the spec itself, because the code I wrote already correctly implemented it. To this day, these are the only feedbacks I received. The feature is still not yet integrated due to another issue, but I won't get into there. Back to the current spec template. I was probably too unfortunate to experience the problem with the embedded basic code (I still don't know how it worked for you, though), but posting a message on the [EMAIL PROTECTED] mailing list obviously does not help because no one seems to be on that mailing list, or no one reads the mails. To me, that project looks stalled. Unfortunately, writing a spec is a requirement for a feature that requires a UI change, such as the feature I'm trying to get integrated[3]. So, getting no response whatsoever means that, this feature has to wait until either 1) someone be kind enough to give me help figuring out what the problem is, 2) I have to go through all the Basic code myself and figure out how to fix it (there is quite a bit of code to go through), or 3) integrate it but disable it in the default build, to avoid UI change (no UI, no spec). My opinion is simply, why make the template this complex? In my view, what's important is the content that goes into the specification document, so I don't see the point of making it too unnecessarily fancy (and not work under certain conditions). If the feature involves no UI change, or simple enough to be described in a sentence or two, giving an overview of the feature in a plain text file should suffice. If it needs a screenshot or two, use Wiki or a simple Writer document. If the author is more comfortable with HTML, use that instead. Enforcing the format of a content when it is not very critical puts unnecessary burden on the contributor's shoulder. Being flexible here would make a lot of folks happier. Writing a spec alone is already boring. So, please don't make it even more boring. ;-) Of course, if the spec requirement
Re: [dev] documentation for filter flags?
Mathias Bauer schrieb: Allen Pulsifer wrote: Just to follow up on this question, what in particular does the NOTINCHOOSER flag do? In testing, and in examining the source code, it appears to do nothing. In contrast, the NOTINFILEDIALOG hides the format in all dialogs, including File | Open, File | Save As and File | Export. I'm using OOo v2.0.4 en-us under WinXP. NOTINCHOOSER excludes it from the filter dialog, the awful dialog you get when OOo can't find a filter. About the documentation: I'm sure we had one, but I can't ask the developer who should have provided it as he is on vacation until end of next week. I'm back .-) And here my answer. The list of filter flags was documented inside the Developers Guide. Please have a look on the chapter 6.2.4 Integrating Import and Export Filters of http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml;. Note: The meaning of Default was changed slightly inbetween. Old meaning was: default filter for saving (in case no other filter was specified via API) ... could be set via Tools-Options-Load/Save New meaning is: newest and most actual filter for this document type as e.g. AutoSave it needs to guarantee saving of documents without loosing any information (as e.g. ALIEN formats can have) I can just sum up what comes into my mind, hope I don't miss one: Import - should be self explaining Export - should be self explaining Alien - no zip container based format Own - one of the OOo file formats Template- deprecated Preferred - preferred filter for a particular type Asynchron - deprecated, only HTML-filter isn't synchron 3rdPartyFilter - implemented as a UNO component TemplatePath- filter for a documenttemplate Default - default filter for this document type NotInFileDialog - should be self explaining NotInChooser- as above Ciao, Mathias Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
