Re: [dev] Unicode---Give us all of it!
Eike Rathke wrote: 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. Thanks for the hint, I will poke at CWS icuupgrade then. 2 The Insert - Special Character... dialog does not support characters beyond U+. Not really surprising. I am not looking for a list of surprises. I am looking for a list of to-dos. ;) 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. Not necessarily; see my original post that started this thread, where I argued that a string is sometimes better than a character: A related problem is that Unicode combining character sequences like U+0041 LATIN CAPITAL LETTER A followed by U+20E3 COMBINING ENCLOSING KEYCAP shall be treated as single characters in certain applications. (For example, if you can specify the bullet symbol that shall preceed each list item you enter in a word process, combining character sequences could be useful choices for such a symbol.) This indicates that an application's concept of 'character' is often best represented by a programming environment's concept of 'string.' -Stephan Eike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Specs. closer to a solution
Eike Rathke [EMAIL PROTECTED] writes: Please go ahead, if no one objects. Seconded. This is going to be iterative refinement. ;-) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Niklas Nebel [EMAIL PROTECTED] writes: 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. :-) Hi Niklas, well, I guess the issue here is that UX has proven to be much more of a bottleneck than QA in the past. See that quoted issue in one of the first mails of this thread forest, where UX did not respond for ~.5 years. And while I think that UI cohesiveness/usability is important, I would compromise it (temporarily), to have otherwise useful and properly QAed features integrated - in the case an UX feedback request has timed out. And besides that, with documents like http://wiki.services.openoffice.org/wiki/OpenOffice.org_Guidelines and http://wiki.services.openoffice.org/wiki/UI_Style_Guides devs and QA should be able to design/verify good-enough UI in the first place - I would be very surprised if any UI atrocities would survive a proper QA cycle then. Given all this, I also second the timeout proposal. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Niklas Nebel wrote: 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. :-) If they are too busy doing other things I assume that they don't see the issue as important enough to work on it. In this case I don't see a problem going on without them. We can't make UX the single point of failure as currently where gazillions of issues are going mouldy being assigned to requirements and some patches aren't looked at because we are waiting for input from UX. If we ask developers to work on patch integration we also can expect some readiness for cooperation from UX. And a possible response in a 2 weeks time frame could be I don't have enough time for all the details but I don't consider this to be critical so please go ahead. In case they don't have time but consider it to be important something is going wrong and must be escalated. The importance of UX input is overestimated in many cases (IMHO). This is different for QA where I don't expect that we can do without. But QA can be done by people outside of Sun as all necessary tools are available for everybody. I don't see this possible for UX at the moment. 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
Eike Rathke wrote: 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. Vacation can't be an excuse for being unresponsive. This is a team effort and project leads or team managers should be able to monitor this. At least that's what happens in development. Why not in other teams also? I already mentioned that it should be clear that it can't be expected that a problem is always solved within 2 weeks. One reason for this might be vacation. So my constraint that automatic timeouts shouldn't take effect if people are responsive but just don't finish their work in 2 weeks should become rephrased: if UX doesn't give any answer in 2(?) weeks the developer(s) should be allowed to proceed without them. 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] is it possible to switch off auto-numbering via api for already opened documents
Christoph Lutz wrote: Hi, On 11/10/06, Mathias Bauer [EMAIL PROTECTED] wrote: Now I would like to know If I can switch off the autonumbering (Tools-AutoCorrect-Options/apply autonumbering) for an already opened document via api. Writing the configuration directly has no effect on already opened documents. Which entry did you change? in the node /org.openoffice.Office.Writer/AutoFunction/Format/ByInput/ApplyNumbering I set the property Enable to the new value Boolean.FALSE (in java). Does this setting have any effect on documents opened later on? 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] How to create OOo Basic scripts via API
Hallo, I've checked the Dev Guide and the IDL docs but I can't seem to find any services/interfaces that allow me to create/edit Basic scripts included in a document via the UNO API. It would be nice if someone could point me in the right direction. Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Unicode---Give us all of it!
Stephan Bergmann wrote: [...] 1 I installed a font that contains appropriate glyphs (code2001.ttf from ) into a SRC680m192 share/fonts/truetype, imported an UTF-8 encoded text file that contains U+010300 into Writer, copy/pasted that text to various places, on both Windows and X11: With CWS icuupgrade (currently SRC680m193) the situation for X11 changes as follows: - 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. Selection works now. - Behavior in the edit engine (tried a text box in Draw, and File - Properties... - Description - Comments) is the same as Writer (on each of Windows and X11, respectively). Correspondingly, selection now also works here. - Behavior in a text control (tried File - Properties... - Description - Title is that two boxes instead of a single correct glyph are shown, and cursor traveling and selection treat the two boxes as individual units (on both Windows and X11). No changes here. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Question: UNO and D-Bus
Hi all, D-Bus is quickly spreading as an universal way to talk between applications on the Unix systems, and more particularely (but not only) the Linux platforms: HAL, GNOME, Avahi, udev, Beagle, Qt and KDE already use it. It is being ported to Windows and has bindings to many programming languages and environments. D-Bus is designed to be efficient and easy to use (remind CORBA ? ;-) ). It is mostly used on one same machine, but can be transported by TCP/IP. It has authentication mechanisms but no encryption so far (it must be tunnelled if outside of a firewall-protected area). http://freedesktop.org/wiki/Software_2fdbus UNO is powerful, portable, and at the core of OpenOffice.org, but it has the disadvantage of not being used outside of OOo. http://wiki.services.openoffice.org/wiki/Uno/Article/Understanding_Uno UNO does not compare exactly to D-Bus, since UNO is a full component model while D-Bus is more a matter of remote method invocation. However, they can be used for the same thing: remote control of an application. Here is my question: What are the plans to make OOo scriptable through d-bus? Sorry in advance if this is already answered somewhere, I did not find it. -- Quelle est la différence entre un rêveur, un fou et un psychanalyste ? Le rêveur construit des châteaux dans le ciel, le fou y habite, le psychanalyste encaisse les loyers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] updating database form controls on events
Hi tofergus, option two was to find the parent of the control which would presumably be the form and search for the required peer item. this also appears impossible as the control is not actually a FormComponent. I suppose that your event is sent by the control, not the control *model*. Only models are part of the form component hierarchy. So, try querying your event source for css.awt.XControl, and ask for its model. That one should have a parent, which is your form. my current thinking is that, if i get the component context then i could instantiate (via XMultiServiceFactory) the Forms service and thus the Forms root. if this is the correct route if isnt't. The forms collection is already present, so re-creating doesn't make sense. unfortunately, as the database document does not seem to support the the DrawPage interface (presumably because the actual form appears to be a writer document) i am unable to figure out how to obtain the Forms root The text document is, IIRC, an XDrawPageSupplier, which should give you access to the (one and only) draw page of the document. 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] Specs. closer to a solution
Hi! Niklas Nebel wrote: 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. :-) Best would be: No QA, no Doc, no UserEx, just hackin' code ;-) I agree in making the processes transparent, liveable etc. for all stakeholders but it has to be also an agreement of them the we don't want to give the quality away we have already reached - means: no regression, no work hinderers (build and process breakers) anymore. Just for information: If the automated GUI testing can not be started on a [to be released] build we loose ~50% (over all modules, in some we have 95% in others less) testing code coverage. Do we all agree that it makes no sense to break this testing process which also being used by porting-dev to get things done on other platforms!? We all can also agree that we should invest in making it faster. Same for specifications: Yes, make it faster but don't give up the content needed by one of the stakeholders/customers of this document. And we already know which groups need which information. Time is never a valid reason to waste quality. Yours, Jogi -- === Sun Microsystems GmbH Joerg Sievers 20097 Hamburg Quality Assurance Engineer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Specs. closer to a solution
Joerg Sievers wrote: Hi! Niklas Nebel wrote: 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. :-) Best would be: No QA, no Doc, no UserEx, just hackin' code ;-) Hehe, paradise is lost. At least when we started to get users :-) But we didn't talk about QA or documentation *work* here, we are talking about cases where exactly this does *not* happen and what we should do in these cases. I agree in making the processes transparent, liveable etc. for all stakeholders but it has to be also an agreement of them the we don't want to give the quality away we have already reached - means: no regression, no work hinderers (build and process breakers) anymore. I didn't read any proposals here that we wanted to leave that path. OTOH I really would like to open another discussion (means: a new thread) about what developers could do to make GUI testing or parts of it unnecessary in some defined cases. This will save us some time in QA so they will have more time for other CWS where perhaps more testing would be desirable. Do we all agree that it makes no sense to break this testing process which also being used by porting-dev to get things done on other platforms!? Yes, for me that goes without a saying: we shouldn't lower the QA barriers. AFAIK the problems for volunteer developers we had in the past wheren't causes by too exhaustive testing but by no testing happening at all. We could do us all a favor if we could avoid this situation in the future and if all people involved developed a positive attitude towards community contributions - even if they are presented in a less than perfect way. 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] An attempt of a summary: specification process possibilities
Hi, to go a step further: Do we need such feature mails at all? Couldn't we instead offer RSS feeds (per project?) which list the most recently integrated CWSs and their feature descriptions? I could imagine that a developer can edit the feature description at any time he likes and, at the time the CWS with the feature task(s) gets integrated, the information about the feature(s) gets available in the appropriate RSS feeds. If someone is interested in the feed, then he can subscribe to it and gets informed when updating the RSS feed. No mails at all. Would this be feasible? Would it be better than the current way? Or is the idea just nonsense? Regards, Jörg Eike Rathke schrieb: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Hi Jörg, to go a step further: Do we need such feature mails at all? Couldn't we instead offer RSS feeds (per project?) which list the most recently integrated CWSs and their feature descriptions? It's a matter of taste and/or working habit whether you want to read a Feed or a mailing list. I wouldn't remove the mails completely (finally, they have the advantage of being archived in the OOo project), but I like the idea to additionally offer them as feed. I could imagine that a developer can edit the feature description at any time he likes and, at the time the CWS with the feature task(s) gets integrated, the information about the feature(s) gets available Yes!, please let's have this! 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] Unicode---Give us all of it!
Hi Stephan, On Thursday, 2006-11-16 10:29:12 +0100, Stephan Bergmann wrote: With CWS icuupgrade (currently SRC680m193) the situation for X11 changes as follows: - 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. Selection works now. Fine. Glyph still shown as two boxes? Might be some work for Herbert. - Behavior in a text control (tried File - Properties... - Description - Title is that two boxes instead of a single correct glyph are shown, and cursor traveling and selection treat the two boxes as individual units (on both Windows and X11). No changes here. Sounds like the control doesn't use the i18n breakiterator. Thanks for testing. 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!
Michael Meeks wrote: 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 ? That would be nice for several reasons. The biggest drawback of this solution is that the C++ UNO Language Binding would be changed incompatibly and all in-process C++ components using it must at least be recompiled to work in the OOo version that contains the new string class. So we shouldn't dismiss this option but we also should handle it with care. 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] An attempt of a summary: specification process possibilities
Hi Bernd, On Thursday, 2006-11-16 16:08:34 +0100, Bernd Eilers wrote: The questions where I am currently unsure about are the following: 1.) can automatically move all featuremails/api-changes from state draft to state finished when the state of the CWS moves to state 'ready for QA' or should we do that when the state of the CWS moves to 'integrated' If integrated. or if should we not do any automation at all and leave it up to the developer to change the state of the featuremail and apichange only? After integration the feature as desribed by the featuremail is final, if it wasn't, a new CWS would be created and the feature be changed, with a feature changed mail, if needed. There is no sense in keeping the featuremail in draft status and burden the developer with having to remember to set it to final. 2.) Can there be a case where a feature mail is finshed but must still be changed You never know, it might happen. For example if a description is wrong or important information missing. and what should happen in this case regarding the mailinglist, resend the featuremail? Yes. If for 1.) we would decide to declare things final only at integration Problem 2.) is not there because a change in the feature would be done in a new CWS and a new featuremail would be needed there for it. True if the feature needs changing, not true if only the featuremail needs changing. On the other hand QA must have information about the feature when the CWS is 'ready for QA' and we can not require that anyone in QA get´s familar with RSS feeds. If the featuremail is a feature of EIS, assigned to the CWS and a task and readable for everyone, the information may always present via the web interface. No need to make it available only in RSS feeds. Maybe this can be resolved by having 3 states 'draft', 'published' and 'final' and moving to published with sending to mailinglist when state changes to 'ready for QA' and moving to 'finished' with or without publishing to mailinglist also when CWS state changes to 'nominated'. No, that's just confusing. The featuremail gets final and is published when the CWS is integrated. We don't need extra states that complicate things. Maybe with the possibility for the developer to send out extra draft mails before integration, if needed. 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]
[dev] Re: How to create OOo Basic scripts via API
Matthias B. wrote: Hallo, I've checked the Dev Guide and the IDL docs but I can't seem to find any services/interfaces that allow me to create/edit Basic scripts included in a document via the UNO API. It would be nice if someone could point me in the right direction. Matthias Hi, Matthias B. Sub mkNewDocWithMacro() oDoc = Stardesktop.loadComponentFromURL(private:factory/swriter,_default,0,Array()) oDocLibs = oDoc.BasicLibraries oLib = oDocLibs.createLibrary(testLib) sCode = REM * BASIC * Chr(10) sCode = sCode REM inserted by Sub mkNewDocWithMacro() Chr(10) sCode = sCode Sub test Chr(10) sCode = sCode Msgbox Sub test has been called,64,Library test Chr(10) sCode = sCode End Sub 'msgbox sCode,64 oLib.insertByName(Module1,sCode) REM this is not changed automatically: oDoc.setModified(True) End Sub Does this help? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] is it possible to switch off auto-numbering via api for already opened documents
Hi, Writing the configuration directly has no effect on already opened documents. Which entry did you change? in the node /org.openoffice.Office.Writer/AutoFunction/Format/ByInput/ApplyNumbering I set the property Enable to the new value Boolean.FALSE (in java). Does this setting have any effect on documents opened later on? no, unfortunately not! -- I added it as another example to #71235 there seems to be no property set that allowes me to change the setting for already opened documents like ViewSettings is for all properties regarding the view. Ciao, Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
