[dev] WriteNow 3.0 (Macintosh) (W4W)
Hi, I cannot seem to get openoffice to load an old mac writenow document. Do I need to install any special plugin to get this to work? James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Hi Niklas, On Wednesday, 2006-11-15 19:18:30 +0100, Niklas Nebel wrote: > One does. If we consider User Experience involvement with UI changes > important, we can't skip that step whenever they are too busy to look at > a specific issue. In that case they can at least say so. I think having a timeout should be for the cases where one doesn't receive any answer at all. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Hi Mathias, On Wednesday, 2006-11-15 18:24:43 +0100, Mathias Bauer wrote: > The exact length of the timeout should be nailed by the ESC. 2 weeks > seems to be enough IMHO. Depends on. If the person in question is on vacation it might not be enough. To prevent this situation enquiries should always somehow be made public, so someone may jump in or point it out. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Mathias Bauer wrote: 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. I see. I think at least no developer (neither Sun or non-Sun) will have any problem to agree here. :-) One does. If we consider User Experience involvement with UI changes important, we can't skip that step whenever they are too busy to look at a specific issue. Otherwise, we could do the same with QA: If they don't object within two weeks, a change is integrated. That would speed up things, too. :-) Niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Keyboard shortcuts for common diacritics
sure... Christian Lohmaier wrote: The other way round.. Activate deadkeys. Or use compose sequences or use groupshift/meta,... There are tons of different solutions and each of them is better than defining shortcuts in an application. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Michael Meeks wrote: > 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. I see. I think at least no developer (neither Sun or non-Sun) will have any problem to agree here. :-) The exact length of the timeout should be nailed by the ESC. 2 weeks seems to be enough IMHO. I hope that in cases where the person asked for a comment is helpful but isn't able to accomplish this in 2 weeks just because it is a lot of work to do nobody insists on a 2 week deadline. >> 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 ? Sounds good to me. Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Development at a Glance - Weekly Update CW46
Hi, here is the weekly update for calendar week (CW) 46: CW46 http://blogs.sun.com/GullFOSS/entry/development_at_a_glance_-1 Regards, Dieter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specifications - summary & suggestions ...
Michael Meeks wrote: > 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. Let's put it that way: it is not forbidden to use the spec as part of the workflow ;-) but of course it's also not mandatory. And at least for me the purpose of an iTeam never was to create a spec upfront but to continuously give input when a feature is developed where at the end of the development we have an implementation and a specification describing it sufficiently. So it also goes without a saying that in many cases an iTeam is superfluous and at the end was just a list of people that had to do their job (dev, QA etc.). Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - 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 Stephan, On Tuesday, 2006-11-14 15:45:46 +0100, Stephan Bergmann wrote: > - On Windows, Writer shows a correct glyph; cursor traveling and > selection work. On X11, Writer shows two boxes instead of a single > correct glyph; cursor traveling left/right works by treating the two > boxes as a single unit (but traveling up/down may bring you into the > middle of the two boxes), selection treats the two boxes as individual > units. The difference may be because, AFAIR, the Windows version uses the glyph layout available on Windows, whereas other platforms use the ICU layout methods. As the currently used ICU 2.6 is quite old and does not support the latest Unicode standard it might be interesting how the new ICU 3.6 behaves in this regard, CWS icuupgrade has it. It is freshly resynced to m193, the Hamburg inhouse build is ready for unxlngi6.pro, yet untested, though worked well with m187. > 2 The "Insert - Special Character..." dialog does not support > characters beyond U+. Not really surprising. > 3 From the OOo UNO API list I already posted, the following items are > problematic: > com/sun/star/i18n/XExtendedInputSequenceChecker: long > correctInputSequence([inout] string aText, [in] long nPos, [in] char > cInputChar, [in] short nInputCheckMode) > com/sun/star/i18n/XExtendedTransliteration: char > transliterateChar2Char([in] char cChar) > com/sun/star/i18n/XExtendedTransliteration: string > transliterateChar2String([in] char cChar) > com/sun/star/i18n/XInputSequenceChecker: boolean checkInputSequence([in] > string aText, [in] long nPos, [in] char cInputChar, [in] short > nInputCheckMode) I guess all these could be "replaced" with an additional method that takes a 32-bit code point instead of a char. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Unicode---Give us all of it!
Hi Michael,
On Tuesday, 2006-11-14 10:56:09 +, Michael Meeks wrote:
> 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:
Iterator returning a normalized 32-bit Unicode code point. Additionally
have some getLengthInUnicodeCharacters() or such that equals the count
of code points.
Eike
--
OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't send personal mail to the [EMAIL PROTECTED] account, which I use
for
mailing lists only and don't read from outside Sun. Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Calc, disable saving in Excel 5/95 format?
Hello Rich, it seems attachment was stripped, as usual - maybe you could put it up for download somewhere ? Sorry - my fault .-) Mathias solved it temporarly .-)) THX. I will put an article on our OOo wiki next time, whery I explain some generic steps, how filter deployment can work on OOo. Please stay tuned. Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Hi Frank, On Wednesday, 2006-11-15 13:43:22 +0100, Frank Schönheit wrote: > I'd prefer an ability to add feature mails in EIS which are not yet > sent. That is, I would like to fill out the form for the feature mail, > and press some "Send Later" button. The mail would then be associated > with the CWS, and only sent when the CWS gets > approved/nominated/integrated (whatever). Integrated. This would also (again) give some meaning to the "available from" field, which then could be automatically filled by EIS with the release target the CWS was integrated for. Currently the "available from cws soandso" may bear information for QA and people familiar with EIS and CWS integration, but the real release target would be more useful for the general public. > QA can still look at the > mails, and development can change them before sending, if necessary. So, +1 Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Specs. closer to a solution
Hi Kai, On Tuesday, 2006-11-14 11:47:18 +0100, Kai Backman wrote: > Yep, as soon as you guys have some form of agreement about the > timouts I'll splice everything in. I like Mathias text as well, I > think it will work almost unchanged. We already talked about it, and given the nice proposal from Mathias plus some "timeout" tweaking and some hand-holding steps here and there I think we're fine with it. So maybe we should just start the wiki page? It's much easier to read/edit that and have some additional discussion if needed than to read interweaved messages on the mailing list to get "the final clue". Please go ahead, if no one objects. Thanks Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Thanks. - 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, > At the risk of being caught ignorant: should feature/changes mails on > these lists be posted before the CWS is approved? I think that odds > aren't low that something might get changed after handing over the CWS, > especially in case of new developers. AFAIK policies require mails to be sent when the CWS does to QA - which in fact might not make that much sense. > Perhaps we can distinguish between "preliminary" and "final" > announcements, the former is sent when the CWS is handed over from the > developer, the latter when the final step ends with the CWS approval. I'd prefer an ability to add feature mails in EIS which are not yet sent. That is, I would like to fill out the form for the feature mail, and press some "Send Later" button. The mail would then be associated with the CWS, and only sent when the CWS gets approved/nominated/integrated (whatever). QA can still look at the mails, and development can change them before sending, if necessary. The additional advantage of such a feature - completely independent form the current discussion here - is that for large CWS, you do not need to manually track all the chances (esp. API changes) you did therein. You can write them when they happen, and they're all sent at once when the CWS is finished. 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] Localization of Open Office in Santali
Welcome to OpenOffice.org! You may be glad to hear that there is an OOo Localization project that covers exactly the area you would like to contribute to. For the beginning please have a look at: http://l10n.openoffice.org and http://native-lang.openoffice.org In case of questions on localization, please feel free to ask at the dev@l10n.openoffice.org list. Kind Regards, Rafaella Naresh Chandra Murmu wrote On 11/15/06 09:46,: Dear Sir, I am native speaker of Santali language and by profession, I am Scientist. I have already worked for Unicode Proposal for Ol Chiki Script which is used for writing Santali. Now I wish to get involved with Open office localization. Please let me know how to proceed? Santali is one of the 22 recognized languages of India. Probably this is first Indian Tribal language listed as Official language. Thanks in advance! With regards, -N. C. Murmu, CMERI, Durgapur West Bengal India - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Joerg Sievers wrote:
> Hi Matthias!
>
>
> Mathias Bauer wrote:
>> (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!).
>
> Good description in the last sentence.
>
>> (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.
>
> Be sure that your "spec" meets the 'three golden rules' which can be
> used for a review of the "specification"
>
> http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications
>> There is nothing "overweight" included and you have to look at these
> tasks otherwise the integration could (and it will, be sure) fail and
> will cost others time or break the testing, building or whatever in this
> case could happen...
I'm not so pessimistic as you are. ;-) But I agree that it helps
developers if we make them aware of possible problems that can appear
later on and how they can be avoided easily. So our rule set should
include the golden three words ("Complete","Clear","Simple") and the
link to the mentioned wiki page as a resource for explanations of the
meaning and the reason of them.
>> (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.
>
> There is already a tool how to announce feature changes:
>
> http://eis.services.openoffice.org/
>
> -> Changes mails
> -> "external" feature
> or
> -> "external" API change
At the risk of being caught ignorant: should feature/changes mails on
these lists be posted before the CWS is approved? I think that odds
aren't low that something might get changed after handing over the CWS,
especially in case of new developers.
Perhaps we can distinguish between "preliminary" and "final"
announcements, the former is sent when the CWS is handed over from the
developer, the latter when the final step ends with the CWS approval.
Ciao,
Mathias
--
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Michael Meeks wrote: > 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 (?). Which timeouts are you talking about? step(1) doesn't need timeouts as nothing is mandatory - everything is a recommendation to avoid problems later on. step(2) is a duty for the developer, he can decide about timeouts on his own. ;-) step(3) also doesn't need a timeout as nobody is waiting for anything/anybody. You might need to force the people involved to hurry up a bit if you wanted to get you work into a particular release, but that's nothing that can be handled by timeouts IMHO. 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. IMHO the project lead is the best choice here but possibly also the release committee we just have revived. step(4) once again is a duty for the developer. But perhaps I misunderstood something, so in this case please explain. > > 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 ? ;-] No, as we already practice it - just not in the same way as you wanted as to do. But inside a CWS and even sometimes stretched over several of them we already did it. > 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 ;-) IMHO this could be a good reason for an ESC meeting. Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Unicode---Give us all of it!
Michael Meeks wrote: Now - as you say, there is some poison chalice of endless ABI stability here, but if some big review of the code is underway, it'd be nice to add some #ifdef NO_DEPRECATED_API around the sal_Unicode * operator, and add a sal_WideUnicode [] operator instead (perhaps) NO_DEPRECATED_API is a nice idea, indeed. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Localization of Open Office in Santali
Dear Sir, I am native speaker of Santali language and by profession, I am Scientist. I have already worked for Unicode Proposal for Ol Chiki Script which is used for writing Santali. Now I wish to get involved with Open office localization. Please let me know how to proceed? Santali is one of the 22 recognized languages of India. Probably this is first Indian Tribal language listed as Official language. Thanks in advance! With regards, -N. C. Murmu, CMERI, Durgapur West Bengal India - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
