Re: [dev] Calc, disable saving in Excel 5/95 format?
Andreas Schlüns wrote: ... If that is fine for you I could tell you how you can deploy this change as an extension. Of course packages are the best way to make such changes. Because the share layer will might be changed if the next update will be installed (!) ... your changes there will be lost then. A package can be installed using Tools-Extension Manager Please use the attached file to disable the MS Excel 5.0 filter. it seems attachment was stripped, as usual - maybe you could put it up for download somewhere ? If you wish to make changes inside the package, you can unzip it (internaly it's a normal zip file). Open the XCU file and edit it. Ciao, Mathias Ciao Andreas -- Rich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Unicode---Give us all of it!
Michael, Michael Meeks wrote: There's no chance then of switching to UTF-8 as an underlying string representation :-) and saving a measurable chunk of our string overhead ? this is certainly possible by introducing a new string (I mean exactly _one_ string), which IMHO should address some other points I investigated into (see http://wiki.services.openoffice.org/wiki/Uno/Binary/Analysis/String_Performance). This new string should also be opaque, so that internal data representation could use the most beneficial format available (which might be UTF8). Unfortunately, this would be incompatible and quite a big chunk of work. Interesting mail anyhow, Regards, Michael. Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Calc, disable saving in Excel 5/95 format?
Rich wrote: Andreas Schlüns wrote: ... If that is fine for you I could tell you how you can deploy this change as an extension. Of course packages are the best way to make such changes. Because the share layer will might be changed if the next update will be installed (!) ... your changes there will be lost then. A package can be installed using Tools-Extension Manager Please use the attached file to disable the MS Excel 5.0 filter. it seems attachment was stripped, as usual - maybe you could put it up for download somewhere ? Take the one from http://www.mytempdir.com/1050938 It disables the Excel export filters as requested. 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] any taker on tools-customize-keyboard dialog ?
Hi, I just stumbled across issue Customize field badly-spaced, can't adjust, http://www.openoffice.org/issues/show_bug.cgi?id=71464. I can imagine that a possible adjustment of the design of that dialog is not too difficult for newbies to step in (http://graphics.openoffice.org/source/browse/graphics/svx/source/dialog/cfg.cxx) and also would be a good example that it might be possible to change UI without involvement by Sun ? (by following the new spec template in the wiki, http://wiki.services.openoffice.org/wiki/Category:Specification) any takers on this ? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Unicode---Give us all of it!
Stephan, from my point of view, we should have originally followed what the glibc does with wchar_t (see http://www.gnu.org/software/libc/manual/html_node/Extended-Char-Intro.html), unfortunately switching to this obviously is incompatible and a lot of work, so your suggestion sounds quite reasonable. Kay Stephan Bergmann wrote: Unicode---Give us all of it! Unicode encodes characters in a codespace that ranges from 0 to 0x10. Much of the OOo code base operates on UTF-16 code units that range from 0 to 0x: - C/C++ code based on sal_Unicode. - Java code based on Java char. - UNO based on UNO CHAR. It is obvious that a single UTF-16 code unit cannot represent all of Unicode. Thus, UTF-16 is designed in such a way that each Unicode character can be represented in UTF-16 as an ordered sequence of at most two code units: Characters in the ranges U+--D7FF and U+E000-- are represented by a single UTF-16 code unit (of the respective numeric value). Characters in the range U+1--10 are represented by two UTF-16 code units, a high surrogate in the range 0xD800--DBFF followed by a low surrogate in the range 0xDC00--DFFF. In turn, it should be obvious that treating single UTF-16 code units as representing Unicode characters does not work. However, since most actually used Unicode characters are in the range U+-- (and can hence faithfully be represented by a single UTF-16 code unit), this problem is not apparent in all situations. This will gradually change as Unicode characters in the range U+1--10 are used more and more frequently, especially in East Asian locales. And this should be motivation to enhance OOo so that all parts of it work flawlessly with all of Unicode. In Java 5, this problem has been addressed by augmenting functionality based on Java char single UTF-16 code units (e.g., String.charAt) with functionality based on Java int (0--0x10) Unicode encoded characters (e.g., String.codePointAt), and by using functionality based on java.lang.String UTF-16 code unit sequences. Similar solutions are needed for C/C++ code and UNO APIs. 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. C/C++ Code -- The approach here has two parts: 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). Find all the places in the code that need to be adapted. Java Code - No Java code within OOo that would need to be adapted has been identified. (Any necessary adaption would be complicated by the fact that OOo shall be compatible with Java 1.3.1, so that much of the functionality offered by Java 5 would not be available.) UNO APIs Replace (if unpublished) or supersede (if published) any API that uses CHAR with a corresponding API that uses STRING. Find attached a list of all occurences of CHAR within the API (types.rdb) of SRC680m193. How to proceede --- In a first step, I will try to identify and gather as many places in OOo that need to be adapted, but I need your help for that: IF YOU KNOW OF ANY PLACE IN OOo THAT NEEDS TO BE ADAPTED, PLEASE LET ME KNOW. Once all places have been identified, we can see how to address the task of adapting them accordingly. -Stephan com/sun/star/accessibility/XAccessibleText: char getCharacter([in] long nIndex) com/sun/star/awt/KeyEvent: char KeyChar com/sun/star/awt/KeyStroke: char KeyChar com/sun/star/awt/SimpleFontMetric: char FirstChar com/sun/star/awt/SimpleFontMetric: char LastChar com/sun/star/awt/XFont: sequenceshort getCharWidths([in] char nFirst, [in] char nLast) com/sun/star/awt/XFont: short getCharWidth([in] char c) com/sun/star/awt/XFont: void getKernPairs([out] sequencechar Chars1, [out] sequencechar Chars2, [out] sequenceshort Kerns) com/sun/star/awt/XTextEditField: void setEchoChar([in] char cEcho) 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)
[dev] Specs. closer to a solution
Hi Mathias, So - I think your summary here is great: On Wed, 2006-11-08 at 14:41 +0100, Mathias Bauer wrote: ... snip various good points... So perhaps we can describe it so (with less details ;-): (1) While developing your feature: discuss feature with people on IRC, mailing lists and whatsoever to your liking; it is *recommended* (though not mandatory) to contact the project lead as early as possible and discuss with QA and UserEx also (not to ask for approval but to avoid problems by early contact!). (2) While development happens make sure that at the end you deliver a spec. This could be just an issue in IZ, a web page or a document, details can be described elsewhere. BTW: I consider having an Issue in IZ mandatory as we need to have a reference for cvs commits. (3) Get necessary builds (perhaps by using build bots) and hand builds and spec over by announcing them somewhere(we must define where!) so that QA, translation and documentation can start working on it. (4) React on feedback given by them, be it changing the spec, fixing a bug etc. One thing - we managed to loose the timeouts here :-) since non-responsiveness has been a bug-bear for some years, and is one of those things that may vary substantially over time depending on mgmt imperatives focus, I really want those in there. In order to have a 'fair' timeout, it's necessary to have a time-stamped, reliable, agreed communication medium and length of timeout: a mailing list is fine for that I guess; but it should be specified. Possible an early 'features@' post is sufficient (?). On the other hand - the real strength of your outline is that it is not too rigid / specific: and can be iterated later and expanded as needed to cover unforseen cases [ wow, have I converted you to an iterative process development model ? ;-] So - where do we go from here ? I believe Kai volunteered to write some of this up in the Wiki somewhere as a conclusion, so we actually move to the decision making phase after the lengthy discussion ;-) Anyhow, thanks for your time, Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] new project: Windows Vista support
Hi, we just started a little new project Windows Vista support. Goal of this project is to make OpenOffice.org ready for running on Windows Vista. Vista is offering some new features an Application can make use of. Some of them are listed on http://wiki.services.openoffice.org/wiki/WindowsVista. For a more complete list of Vista features you can visit www.microsoft.com/windowsvista/getready. Another good stating point are the Windows Vista Logo Programs (works with Windows, certified for Windows Vista and their test specification (linked in the wiki). We are looking for people which would like to participate in this project. Possible tasks are: * Review and create requirements * Run and test OpenOffice.org on Vista * Develop for SystemIntegration for Vista. A new platform Windows Vista have been created in IssueTracker to track efforts for this port. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Unit testing ...
Hi guys, On Wed, 2006-11-08 at 11:27 +0100, Kay Ramme wrote: yes, definitely. What about a staged approach to that: first include all unit tests in a regular build, but _only_ perform them with a magic env var set (like the debug=true stanza)? good idea, that would at least make it obvious how to trigger the tests ... Right, knowing how to run these tests (and that they exist) is at least a large part of the problem. Of course, if more people run them then we get more tests, and the tests don't tend to bit-rot so quickly. I looked at the nice list of tests on the architecture page, dived straight into one: http://wiki.services.openoffice.org/wiki/Uno/Cpp/Module/CPPUhelper/test I tried the 1st test, since the instruction list for the 2nd set of tests looked long scary ;-) [ and presumably would be better expressed as a simple 'check:' dmake rule instead of a hand-typed recipe ]. The result: $ cd cppuhelper/qa/propertysetmixin/ $ dmake ... snip a surprising amount of successful building ... g++ -fmessage-length=0 -c -Os -fno-strict-aliasing ... -o test_propertysetmixin.o /opt/OpenOffice/src680-m187/cppuhelper/qa/propertysetmixin/test_propertysetmixin.cxx /opt/OpenOffice/src680-m187/solver/680/unxlngi6.pro/inc/cppunit/TestAssert.h: In static member function ‘static _STL::string CppUnit::assertion_traitsT::toString(const T) [with T = rtl::OUString]’: /opt/OpenOffice/src680-m187/solver/680/unxlngi6.pro/inc/cppunit/TestAssert.h:100: instantiated from ‘void CppUnit::TestAssert::assertEquals(const T, const T, CppUnit::SourceLine, const _STL::string) [with T = rtl::OUString]’ /opt/OpenOffice/src680-m187/cppuhelper/qa/propertysetmixin/test_propertysetmixin.cxx:407: instantiated from here /opt/OpenOffice/src680-m187/solver/680/unxlngi6.pro/inc/cppunit/TestAssert.h:50: error: ambiguous overload for ‘operator’ in ‘ost x’ /opt/OpenOffice/src680-m187/solver/680/unxlngi6.pro/inc/stl/stl/_ostream.h:96: note: candidates are: _STL::basic_ostream_CharT, _Traits _STL::basic_ostream_CharT, _Traits::operator(unsigned char) [with _CharT = char, _Traits = _STL::char_traitschar] near match ... Of course, it's possible that my environment is just twisted up in some strange way of my own construction ;-) however the install from this build works I believe so ... Naturally it's unfair to infer that the unit tests are all broken under-used on the basis of the 1st one tried ;-) but ... having a standard way to run all included unit tests [ eg. at the end of a BuildBot build ] would be really rather useful. Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Unit testing ...
Michael Meeks wrote: [...] http://wiki.services.openoffice.org/wiki/Uno/Cpp/Module/CPPUhelper/test I tried the 1st test, since the instruction list for the 2nd set of tests looked long scary ;-) [ and presumably would be better expressed as a simple 'check:' dmake rule instead of a hand-typed recipe ]. The result: $ cd cppuhelper/qa/propertysetmixin/ $ dmake ... snip a surprising amount of successful building ... g++ -fmessage-length=0 -c -Os -fno-strict-aliasing ... -o test_propertysetmixin.o /opt/OpenOffice/src680-m187/cppuhelper/qa/propertysetmixin/test_propertysetmixin.cxx /opt/OpenOffice/src680-m187/solver/680/unxlngi6.pro/inc/cppunit/TestAssert.h: In static member function ‘static _STL::string CppUnit::assertion_traitsT::toString(const T) [with T = rtl::OUString]’: /opt/OpenOffice/src680-m187/solver/680/unxlngi6.pro/inc/cppunit/TestAssert.h:100: instantiated from ‘void CppUnit::TestAssert::assertEquals(const T, const T, CppUnit::SourceLine, const _STL::string) [with T = rtl::OUString]’ /opt/OpenOffice/src680-m187/cppuhelper/qa/propertysetmixin/test_propertysetmixin.cxx:407: instantiated from here /opt/OpenOffice/src680-m187/solver/680/unxlngi6.pro/inc/cppunit/TestAssert.h:50: error: ambiguous overload for ‘operator’ in ‘ost x’ /opt/OpenOffice/src680-m187/solver/680/unxlngi6.pro/inc/stl/stl/_ostream.h:96: note: candidates are: _STL::basic_ostream_CharT, _Traits _STL::basic_ostream_CharT, _Traits::operator(unsigned char) [with _CharT = char, _Traits = _STL::char_traitschar] near match ... Works fine for me on SRC680m187 unxlngi6.pro with the Hamburg GCC 3.4.1. Please file an issue telling more about your env (GCC version etc.). -Stephan - 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, 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). best regards, Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
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... (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 Then you will find your announcement in allfeatures@openoffice.org and also the QA, DOC etc. will able to find it. - The wording in the menu sould be changed because they have been used 1:1 from Sun's EIS - The announcement can also be written manually but the needed information maybe is missing then... Cu, 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] Keyboard shortcuts for common diacritics
...or if you're working on Linux you might set NODEADKEYS within your X configuration to allow the input of characters like áàéèî etc... Kind regards, Joost Can't you just pretend to your desktop environment (GNOME, Windows, etc) that you have a French keyboard? At least on Windows it's easy to add keyboard layouts, and keyboard layouts are program-specific, so you can in one open Writer window use a French keyboard layout, and still use the US layout in all your other windows. You might want to write the French key symbols, where different, with some suitable marker on your keyboard if you can't remember them by heart ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Keyboard shortcuts for common diacritics
ti 2006-11-14 klockan 10:38 +0100 skrev Thomas Lavergne: I am Thomas and use OpenOffice at home and at my work place with a classic, 104-key PC US Keyboard. I sometimes write documents in French (my native language) and it is a pain in the neck to use accents because I need to open the Insert/Special Character menu and select my é from the array. Can't you just pretend to your desktop environment (GNOME, Windows, etc) that you have a French keyboard? At least on Windows it's easy to add keyboard layouts, and keyboard layouts are program-specific, so you can in one open Writer window use a French keyboard layout, and still use the US layout in all your other windows. You might want to write the French key symbols, where different, with some suitable marker on your keyboard if you can't remember them by heart ;) --tml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Bad PRJNAMEs
Frank Schönheit - Sun Microsystems Germany wrote: Hi Stephan, Attached are two quick and dirty scripts that worked for me (within Hamburg build environment on a Linux box) to find all the places where PRJNAME is probably set wrongly (see below). Feel free to fix those you feel responsible for. In case nobody already volunteered to fix the zillions of offapi-located occurances, I do so. (which probably is better than lots of people adding this module to their own CWS.) thanks Frank I volunteer for udkapi, bean, jut, jurt, cppu, javaunohelper, odk, rdbmaker Juergen Ciao Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Keyboard shortcuts for common diacritics
Dear all,
I am Thomas and use OpenOffice at home and at my work place with a
classic, 104-key PC US Keyboard. I sometimes write documents in French
(my native language) and it is a pain in the neck to use accents because
I need to open the Insert/Special Character menu and select my é from
the array. I would love OO to allow for some shortcuts to my favorite
'diacritrics' (http://en.wikipedia.org/wiki/Diacritic) to speed my
typing. Some of my colleagues still stick to the other word
processing software because of that feature.
I went to the developer's page on the web site but could not decide if
this feature was: already implemented (I use 2.0.3), in project (which
sub-project) and I have no clue whether the OO community does or does
not want this sort of shortcuts to be implemented?
I was thinking of the classical shortcuts like {Ctrl '} for the cute
accent, {Ctrl `} for the grave one and perhaps {Ctrl ^} and {Ctrl
} (for the umlaut).
I can code in C++ but I really have no clue where to start with (and
which sub-project to contact). But again, perhaps you do not want these
shortcuts and perhaps they are already implemented somewhere.
Cheers,
Thomas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Unicode---Give us all of it!
Stephan Bergmann wrote: [...] How to proceede --- In a first step, I will try to identify and gather as many places in OOo that need to be adapted, but I need your help for that: IF YOU KNOW OF ANY PLACE IN OOo THAT NEEDS TO BE ADAPTED, PLEASE LET ME KNOW. Once all places have been identified, we can see how to address the task of adapting them accordingly. Items I have identified so far: 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: - 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. - 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). - 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). Also, Windows soffice often crashed while doing these tests. 2 The Insert - Special Character... dialog does not support characters beyond U+. 3 From the OOo UNO API list I already posted, the following items are problematic: com/sun/star/accessibility/XAccessibleText: char getCharacter([in] long nIndex) com/sun/star/awt/KeyEvent: char KeyChar com/sun/star/awt/KeyStroke: char KeyChar com/sun/star/awt/SimpleFontMetric: char FirstChar com/sun/star/awt/SimpleFontMetric: char LastChar com/sun/star/awt/XFont: sequenceshort getCharWidths([in] char nFirst, [in] char nLast) com/sun/star/awt/XFont: short getCharWidth([in] char c) com/sun/star/awt/XFont: void getKernPairs([out] sequencechar Chars1, [out] sequencechar Chars2, [out] sequenceshort Kerns) com/sun/star/awt/XTextEditField: void setEchoChar([in] char cEcho) 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) com/sun/star/io/XTextInputStream: string readString([in] sequencechar Delimiters, [in] boolean bRemoveDelimiter) com/sun/star/style/TabStop: char DecimalChar com/sun/star/style/TabStop: char FillChar com/sun/star/text/TextSortDescriptor2: [property] char Delimiter com/sun/star/text/TextSortDescriptor: [property] char Delimiter 4 http://www.openoffice.org/issues/show_bug.cgi?id=47752: Switch on support for supplementary Unicode characters in the sal/textenc Big5HKSCS encoding (already implemented, but conditionally switched off until OOo supports supplementary characters well). 5 http://www.openoffice.org/issues/show_bug.cgi?id=71515: A minor issue when writing supplementary Unicode characters to ODF. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Unicode---Give us all of it!
Hi Kay,
On Tue, 2006-11-14 at 10:53 +0100, Kay Ramme wrote:
Michael Meeks wrote:
There's no chance then of switching to UTF-8 as an underlying string
representation :-) and saving a measurable chunk of our string
overhead ?
this is certainly possible by introducing a new string (I mean exactly
_one_ string), which IMHO should address some other points I
investigated into (see
http://wiki.services.openoffice.org/wiki/Uno/Binary/Analysis/String_Performance).
An interesting paper.
This new string should also be opaque, so that internal data
representation could use the most beneficial format available (which
might be UTF8). Unfortunately, this would be incompatible and quite a
big chunk of work.
Well - of course, a big chunk of work is less work if we break it down
do it slowly while doing other things [ like this string re-work
task ;-]. As a first step, (perhaps) while doing this change we should
remove:
operator const sal_Unicode *() const SAL_THROW(()) { return pData-buffer; }
const sal_Unicode * getStr() const SAL_THROW(()) { return pData-buffer; }
And replace them with an inlined [] operator, or better an iterator
API:
* Pro:
+ no performance impact
+ useful for identifying problems with sal_Unicode usage
+ doesn't break ABI compat for existing plugins
+ helps wrt. privatising the internals
* Con:
+ some source/API compat breakage
This then would give us some flexibility to (perhaps) do more
interesting things later with our internal string class.
Just a thought,
Michael.
--
[EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Specs. closer to a solution
On 11/14/06, Kai Backman [EMAIL PROTECTED] wrote: On 11/14/06, Michael Meeks [EMAIL PROTECTED] wrote: 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 ;-) 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. I agree. I like Mathias' proposal also. I'll cast my vote for Michael's timeouts proposal, too. Sounds reasonable. Kohei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Keyboard shortcuts for common diacritics
On Tue, 2006-11-14 at 10:38 +0100, Thomas Lavergne wrote:
Dear all,
I am Thomas and use OpenOffice at home and at my work place with a
classic, 104-key PC US Keyboard. I sometimes write documents in French
(my native language) and it is a pain in the neck to use accents because
I need to open the Insert/Special Character menu and select my é from
the array. I would love OO to allow for some shortcuts to my favorite
'diacritrics' (http://en.wikipedia.org/wiki/Diacritic) to speed my
typing. Some of my colleagues still stick to the other word
processing software because of that feature.
I went to the developer's page on the web site but could not decide if
this feature was: already implemented (I use 2.0.3), in project (which
sub-project) and I have no clue whether the OO community does or does
not want this sort of shortcuts to be implemented?
I was thinking of the classical shortcuts like {Ctrl '} for the cute
accent, {Ctrl `} for the grave one and perhaps {Ctrl ^} and {Ctrl
} (for the umlaut).
I can code in C++ but I really have no clue where to start with (and
which sub-project to contact). But again, perhaps you do not want these
shortcuts and perhaps they are already implemented somewhere.
Why code when
http://documentation.openoffice.org/HOW_TO/various_topics/Howto_special_char.pdf
offers solutions. I use the dead key method on my system for French and
German.
--
G. Roderick Singleton [EMAIL PROTECTED]
OpenOffice.org
smime.p7s
Description: S/MIME cryptographic signature
Re: [dev] Keyboard shortcuts for common diacritics
Hi Joost, *, On Tue, Nov 14, 2006 at 05:40:53PM +0100, Joost Andrae wrote: ...or if you're working on Linux you might set NODEADKEYS within your X configuration to allow the input of characters like áàéèî etc... 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. ciao Christian -- NP: Deftones - Headup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Keyboard shortcuts for common diacritics
Hi Thomas, On Tue, Nov 14, 2006 at 10:38:50AM +0100, Thomas Lavergne wrote: I am Thomas and use OpenOffice at home and at my work place with a classic, 104-key PC US Keyboard. I sometimes write documents in French (my native language) and it is a pain in the neck to use accents because I need to open the Insert/Special Character menu and select my é from the array. Set up an alternative keyboard layout and switch between them, or modify/extend your current layout. http://www.microsoft.com/globaldev/tools/msklc.mspx ciao Christian -- NP: Deftones - Headup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
