Re: [discuss] question about OpenOffice
On 9/7/10 10:58 AM, Niels van Beek wrote: Dear Sir / Madam, One of our customers use OpenOffice, they have decided to use SharePoint 2010. Works OpenOffice with SharePoint 2010, is there integration possible? contact Oracle for further information, they have a SharePoint Connector. Juergen Kind Regards, Niels van Beek - To unsubscribe, e-mail: discuss-unsubscr...@openoffice.org For additional commands, e-mail: discuss-h...@openoffice.org
Re: [interface-discuss] UNO representation for BmpColorMode
Frank Schönheit - Sun Microsystems Germany wrote: Hi Stephan, Why use a constants group instead of an enum? *Sigh*. Since I seem to remember we once had guidelines saying enums are Bad (TM), since enums are not extensible. Does this not hold anymore? i am not aware of such a guideline and of course it doesn't make sense from my perspective. Furthermore i would say it depends on the use case, if you know that the list of values will growing in the future a constants group is probably the best choice. But if you know it will be fixed set of values i would always prefer an enum because API's using this enum type gets type safe and more intuitive by simply reading the API's. Just my 2 cents Juergen And if a constants group is adequate, please use long instead of short---long should be the canonic way of representing integers in UNO, and short arguably could have been left out of the design entirely (similarly to the unsigned types). Admittedly, I like short better than long, since it saves a few bits - which hasn't any real-life benefit, probably. However, short would be consistent with all the other hundreths of constant groups having shorts - which for my taste is slightly more convincing than we simply don't need it :) Ciao Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[discuss] misused email
Hi, it seems that my email is misused to spread some viruses around the world. Sorry for that but this spam doesn't come from me. Juergen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [interface-discuss] XResourceBundle/Loader
Frank Schönheit - Sun Microsystems Germany wrote: Hi Jürgen, Exactly my opinion and i hope that we can answer this question in the context of the general toolkit question. If we will go forward for example with a XUL approach for UI components we should use the XUL resource system. I was more looking for a solution which can be used within the next few months ... ;) I would say it is perfect for components where the UI is done by a generic approach intern like menu items or toolbars for Add-Ons or in the future localized display names and descriptions for Calc Add-In functions. But probably not for complete dialogs. Admittedly, I'm currently only looking for localized strings, not for a UNO API for *all* the functionality of our C++ resource system. However, still I'd consider storing those strings in the configuration a hack (see the other mail). Given that in Java, as well as in XUL, localizing of strings is often done via properties files, would it be reasonable to add support for properties files (basically text files with a list of name=value pairs) to OOo, and create an UNO API for it? This should be future-proof: No matter which other toolkit we'll use later on, chances are good that it will also (need to) support such kind of localized strings. Having the overall picture (where we want to go in the future) in mind can help to find the right solution for your localized strings now. I agree that property files maybe can help here. Juergen Ciao Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [interface-discuss] XResourceBundle/Loader
Joerg Barfurth wrote: Hi, Frank Schönheit wrote: currently, no way exists fore mere UNO components to access localized resources, i.e. data stored in OOo's *.res files [1]. That's Bad (TM), since it forces UNO components to use unlocalized error messages, for instance. I'm not sure OOo's res files are the best thing to use for components. At least they seem better suited to strictly office components, than for any other component that can run in a URE. Exactly my opinion and i hope that we can answer this question in the context of the general toolkit question. If we will go forward for example with a XUL approach for UI components we should use the XUL resource system. FWIW the configuration database can automatically retrieve data for the current UI locale. This has been (ab)used by component authors to provide localized messages. I can't say whether we consider that a good thing, but as one data point, even the OOo command names (for menus or toolbar tooltips) are localized this way now. I would say it is perfect for components where the UI is done by a generic approach intern like menu items or toolbars for Add-Ons or in the future localized display names and descriptions for Calc Add-In functions. But probably not for complete dialogs. Juergen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [interface-discuss] multiple inheritance interfaces, and method ambiguity
Stephan Bergmann wrote:
Stephan Bergmann wrote:
Jürgen Schmidt wrote:
Frank Schönheit wrote:
[...]
So, the question remains: Is it feasible to do what Jörg suggested:
Extend cppumaker so it disambiugates methods of interfaces which are
inherited indirectly multiple times? E.g., let cppumaker generate
class XFormControlModel
: public XUnoControlModel, public XFormComponent2
{
...
// disambiguate XPropertySet
// inherited from both XUnoControlModel and XFormComponent2
virtual Reference XPropertySetInfo SAL_CALL
getPropertySetInfo( )
throw (RuntimeException) = 0;
virtual void SAL_CALL setPropertyValue(...) throw(...) = 0;
virtual Any SAL_CALL getPropertyValue(...) throw(...) = 0;
...
};
needs to be evaluated ...
sounds good
[...]
The problem with this approach is that it changes the vtable layout for
some compilers (GCC and the Solaris compiler seem to be affected), so
that the cpp_uno bridges would have to be adapted on those platforms,
which has two drawbacks:
For one, this would be an incompatible change (however, there currently
is only one affected interface in the OOo UNO API,
com.sun.star.xforms.XDataTypeRepository, which is unpublished). For
another, it would increase the (time and code) complexity of cpp_uno and
cppumaker, would make cpp_uno depend on compiler details even more than
it already does.
Thinking a bit more about the problem, there appear to be four options:
1 Leave everything as is and force C++ client code to do the
disambiguation.
2 Make the changes proposed above, ignore the potential
incompatibility, and extend the cpp_uno bridges.
3 Instead of adding pure virtual disambiguating functions as proposed
above, add specially-named non-virtual inline functions to the
cppumaker-generated classes, like
class XFormControlModel: ... {
...
inline ReferenceXPropertySetInfo call_getPropertySetInfo() {
return static_castXUnoControlModel*(this)-getPropertySetInfo();
}
...
};
That way, the cpp_uno bridges (and the service implementations) are not
affected, only client code needs to change getPropertySetInfo to
call_getPropertySetInfo in case of an ambiguity (which the compiler will
flag).
4 Make the cut and change the C++ UNO language binding in an
incompatible way by using virtual inheritance for interfaces. Ideally,
this would only be incompatible in that C++ code has to be recompiled,
but nothing else changes. It might be worthwhile to think this through
further (potentially identifying other areas that could be improved when
taking this---significant---step).
I would prefer the 4th option because it would be exactly that what we
want and for the long run it would be the clean one. Everything else is
to work around this problem which could be solved in a clean way with
this build compatible change (hopefully only). 1-3 make the UNO
programming not even more intuitive and is one more specialty which the
user have to learn, needs to be documented ...
Ok, we would break our binary compatibility promise but i think it would
be the right decision even when we check further improvements as Stephan
has mentioned.
C++ UNO extensions need to be rebuild then for the next version but that
can be happen also when we change the compiler (not necessarily but
possible)
Juergen
-Stephan
-
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: [discuss] Re: Why do you force me to use M$ Excel???
Matt Needles wrote: John W. Kennedy wrote: Esfandiar Agah wrote: Hi, All I've ever wanted since openoffice saw the light of day is a simple click and pick to get the equation of the regression line in a chart. Can you be a little more specific? I certainly had no trouble making a regression line in OOo last year when I was keeping daily watch on my weight while undergoing radiation therapy. No, no, no. He wants the EQUATION of the line to be shown as a caption for the line, a feature of MS Excel for many years. He has two choices, he can implement it himself (it's open source) or he can submit an official feature request and let the community vote for it (a high vote count can be a good indicator for a fast implementation) and when somebody else volunteer to implement it the feature will find it's way into the product. Life can be so simple ;-) Juergen - 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: [interface-discuss] multiple inheritance interfaces, and method ambiguity
Frank Schönheit - Sun Microsystems Germany wrote:
Hi,
using the new UNO features, in particular multiple inheritance, to
excess :), I stumbled upon the following problem:
Let's say we have
interface XBar1 {
interface XPropertySet;
};
interface XBar2 {
interface XPropertySet;
}
interface XFoo {
interface XBar1;
interface XBar2;
}
Now, in the UNO C++ language binding, consider:
Reference XFoo xFoo = getSomeFoo();
xFoo-getPropertyValue( somePropertyName() );
This yields a compiler error that getPropertyValue is ambiguous.
My first attempt to resolve this was
xFoo-XBar1::getPropertyValue( somePropertyName() );
This compiles fine, but yields a linker error that the symbol
XPropertySet::getPropertyValue cannot be found. Thinking about it, the
linked is probably right to reject my stupid attempt :), but then I
still have my problem.
Okay, a working alternative to resolve this is
static_cast XBar1* ( xFoo.get() )-getPropertyValue(
somePropertyName() )
This compiles and links fine. However, it has the disadvantage that
users of XFoo must *know* at least one base interface of XFoo which
unambiguously provides the XPropertySet functionality - which is
inconvinient.
Yet another alternative is
Reference XPropertySet xFooProperties( xFoo, UNO_QUERY_THROW );
xFooProperties-getPropertyValue( somePropertyName() );
This relieves the user from knowing the base class hierarchy of XFoo,
but the penalty is additional runtime costs. Also, it contradicts the
intention of the new UNO features, which were introduced to *save* the
syntactic and runtime overhead of all those queryInterface calls.
Although i haven't a satisfying solution for you, the new UNO features
were introduced to eliminate most of the queryInterface calls not all
;-) You have to use queryInterface still for optional interfaces.
And of course if you re-declare the ambiguous interface methods and
handle the ambiguity in your implementation it should be no problem for
the user.
In IDL you can't get this situation because the idlc complains if you
inherit more than once from XPropetySet (directly or indirectly).
In your implementation you have to take care of this depending on your
specific inheritance hierarchy or base classes, helper classes.
Juergen
So far, I didn't find any satisfying solution to this problem.
Did I overlook something?
Are there better solutions in place ATM?
Are better solutions at least possible in theory (by, say, changing the
generated C++ header for XFoo to include a disambiguated
getPropertyValue method)?
Thanks Ciao
Frank
PS: Interestingly, the Java language binding does not seem to suffer
from this problem.
XFoo foo = getSomeFoo();
foo.getPropertyValue( somePropertyName() );
compiles fine ...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Excellent article
Hey, since the beginning of the SDK we have such a simple example that exactly does what you want on a given directory ;-) sdk/java/DocumentHandling/DocumentConverter.java - compile the sample (using the SDK env, necessary to include the UNO simple bootstrap classes. Otherwise you have to include the class files on your own and have to make provide the required manifest entry) - and run it with java -jar DocumentConverter.jar ./test MS Word 97 doc ./converted_files where - ./test specifies the source directory (all documents in this directory will be converted) - MS Word 97 = filter name - doc = extension for the converted files - ./converted_files specifies the target directory where the converted files are stored This example can be simply improved to be more comfortable ;-) Juergen Laurent Godard wrote: Hi Louis, File Wizards Document Converter not working? :-) that's how I usually answer the question when it comes up. But many large corporations/government offices seem anxious about converting thousands, if not tens of thousands, of docs. the batch way that is decribed is the implementation of OOoConv i did in 2003. The working site for transformation is actually down but the source code is available here. http://oooconv.free.fr/oooconv/oooconv_en.html a GUI local tool, enhancing the document converter is also available http://oooconv.free.fr/batchconv/batchconv_en.html all are free LGPL softwares a python version, and XML-RPC, will be released soon as a more professional approach ;) (the sooner as i can :( ) Laurent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Missing feature - Issues with Find Replace
Hi Ian, you bring up some good ideas (i have missed some of them as well) and the best way to bring them in the product is to submit feature requests. Macros are good for rapid prototyping and for special user related functions. But you requested very common features and it would be best to integrate them in the existing functonality, implement them in C++ and integrate them in the existing findreplace dialog and/or extend this dialog. From a macro or component perspective you would have to repalce the existing dialog with a new implementation or create a second special findreplace dialog for the new feature which of course would be confusing from a user experience perspective. So please attach your macro to the feature request that the people who will write the specification get an idea how it should work exactly. The anomaly of \n is simply a bug from my point of view and you should submit an issue for that Thanks Juergen Ian Laurenson wrote: To make life easier for people migrating to OpenOffice.org and to get around some of the limitations in the find and replace I have written a macro called IanndFindReplace available from: http://homepages.paradise.net.nz/hillview/OOo/ The instructions for installing in OOo2.0 need updating but if you look at the instructions for installing libraries for the KeyHandler, you should be able to work it out. However, I think that it is time that my macro is retired and that similar features be part of standard OOo. Namely: * Ability to select regular expressions so that they don't have to be remembered or looked up in help; * Work across paragraphs and not just within paragraphs; * Fix the anomaly of \n being line breaks in Find but paragraph breaks in Replace; * Ability to search for and replace character and paragraph styles at the same same time as an expression for text; * Define the styles for the replaced text. E.g. If replacing a paragraph break be able to say which paragraph style the resulting merged paragraph will have - the first paragraph or the second. My macro can't do the following but these features should be included: * Extend the concept to any formatting e.g. be able to find H2O where the 2 is subscripted as opposed to all H2O or conversely to find H2O and to apply the subscript in the replace; * Include groups in replace. (A group is a bracketed expression in a regular expression and this would allow you to find some text but only change a part of it within the found context). * Change the API so that Find can work on a text range. I hope that this message will generate some discussion around the issue, so that a clearer picture of what people want for Find Replace and how it could work. Maybe my macro could be a starting point for discussing some alternatives. Then maybe I (if I can find the time) or someone else can implement a well thought out and discussed improvement. Thanks, Ian On Tue, 2005-12-20 at 13:36 +, [EMAIL PROTECTED] wrote: In the Find and Replace function, there is no way to replace paragraph breaks. I know you can do the remove paragraph marks from one-line paragraphs in the Autocorrect feature, but that is not what I mean. Often, I find myself working with documents that have extra line spacing below the paragraph in place of Twp paragraph marks. This is not suitable for posting to many web sites or bulletin boards, wheer double line feeds are required. In Word, WordPerfect, Appleworks, etc. it is possible to replace single paragraph marks with double ones in the Find and Replace feature. For OpenOffice to be ready for prime time basic features such as this need to be available. In fact, one should be able to do this with all formatting characters. For example, manual like breaks often have to be either deleted en mass or replaced with paragraph marks. Neither of these is possible in OpenOffice. As a professional writer and editor, I need these features and cannot work effectively without them. Thanks, James E. Smith João Pessoa, Brazil - 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: [discuss] OOo macros
Louis Suarez-Potts wrote: Hello Ian, On 2005-12-22, at 02:44 , Ian Laurenson wrote: On Wed, 2005-12-21 at 15:25 -0500, Louis Suarez-Potts wrote: [snip] These seem to me to be quite reasonable! In the meanwhile, if your macros are not already prominently promoted, now is the time. Ideally, of course, we could host the macros, but if licensing is an issue, then simply a link should seem a good start. The macros are LGPL licensed so I don't think licensing is an issue. I have signed a JCA (I hope it was received as I got no confirmation). So I think the legal issues are covered. Good; then let's post macros to the site. :-) We don't have a Macros project as such but I'd be happy to consider creating it. I think the extensions project should also host this kind of extensions. Macros comes often as a complete library and deployed as an UNO package. As far as i can remember we want collect and provide this kind of extensions their. extensions project = developing extensions, hosting extensisons, QA for extensions or better classification of extensions, marrthem as final, beta or whatever, ... Juergen Russ (and now James) at ooomacros.org have done a great job in hosting macros, but I confess I never quite felt sure when one of my macros was ready to be released - so having them on a site where I could pull them or rapidly update them was/is important to me. Okay. I like their site too, and I just wish the license allowed for greater commingling. So, for now, a link to http://homepages.paradise.net.nz/hillview/OOo/ would be greatly appreciated. Okay. I can think of a couple of places to link it from-- documentation, if Scott and Gerry are agreeable, Support, and even indirectly, from the download pages. But I'm serious about creating a macros project. I think it would be really useful. Cheers, Louis - 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: [discuss] Missing feature - Issues with Find Replace
Hi Ian, great job, i think your summary and the collection of all relevant issues in this area can and will speed development of the new features or at least fixing of the addressed problems. Juergen Ian Laurenson wrote: Hi Jürgen, Reply in-line. On Thu, 2005-12-22 at 09:42 +0100, Jürgen Schmidt wrote: you bring up some good ideas (i have missed some of them as well) and the best way to bring them in the product is to submit feature requests. I agree, but what I want is some discussion first so that a clear specification can be put together. At the end of this email are 57 related issue numbers and summaries - I would much rather that developer time was spent reading one specification that has been discussed and hopefully had some consensus from the community than wading through all these issues. Macros are good for rapid prototyping and for special user related functions. But you requested very common features and it would be best to integrate them in the existing functonality, implement them in C++ and integrate them in the existing findreplace dialog and/or extend this dialog. Agree entirely! I see all of my macros in this light - it is the spirit in which I developed them. Quick prototypes for discussion so that a better solution can be properly developed and included. In the meantime they act as a stop gap for that issue. From a macro or component perspective you would have to repalce the existing dialog with a new implementation or create a second special findreplace dialog for the new feature which of course would be confusing from a user experience perspective. So please attach your macro to the feature request that the people who will write the specification get an idea how it should work exactly. I have attached it to issue 18375. The anomaly of \n is simply a bug from my point of view and you should submit an issue for that It has already been added see issue 29829. Thanks Juergen Some related issues related to find replace: Issue Description 2944 Find Replace within selected text/cells 2997 Allow search and replace of character styles in Find and R 7372 Enhance Find Replace for formatting in Calc 9749 Find Replace' never finds the Drawing Object Text. 10156 Find Replace. Option to start at beginning 10157 Find Replace: Add back find *button*. 10158 Find Replace: Add Find then Replace and just Replace. 10160 Find Replace: Add MS style pattern matching 10161 Find Replace: Add count to find all 11698 Make Find Dialog Box More Robust 15616 Find (and Replace) does not ignore custum hyphens 17188 Find and Replace doesn't take case of original word in to ac 18375 Request drop-down list of special characters in find box 19193 find dialogue: button: goto next occurence of match 19392 Last occurence of Find Replace doesn't get updated on scre 19492 Allowing Find/Replace to find or replace new lines 19720 Find dialogue: return to original caret position if Find al 20100 Find/Replace diolog losting the cursor focus 23545 index entries - find next similar entry - after current one 23750 unify format and Atrributes in find dialog 23759 Find and Replace eats too much memory (crashing most systems 23792 find replace : insert special character lack full unicode 25177 Regular expressions in find and replace many combinations no 25772 Find Repace - Replacement of capitals 28913 Need more regular expressions to ease Find and Replace 29829 Findreplace handles paragraph marks and line breaks strange 30939 Non-intuative way to change formatting in Find/Replace 31172 Find and Replace not accepting direct inputing of unicode ch 32685 Find Duplicate cells in Column or Row 33772 Strings in fields can not be found with FindReplace 35093 Find and replace all on selected cells is misleading 37586 Find dialog stays in the way of the text you found 39453 Find Replace Menu is too big and uncomfortable 39557 search for should (optionally) find typographic quotes as 40024 Add wild cards to ease Find Replace without RegularExpres 41315 Find and replace in multiple openoffice documents 44196 Find erases the users data 44238 Find should highlight found string 44688 Searching with regular expression ^$ does not find empty cel 45574 Find panel layout adjustment 47165 Some extended help texts in Find Replace dialog lost 48533 FindReplace does not set default Search for string 49341 Find/Replace confuses Turkish character ı with Englısh i 49380 enable find and replace buttons when 'Search For' box is emp 50183 allow finding places referring to a, well, reference 50510 ^$ freezes writer (Find replace) 50879 Find and Replace doesn’t work within textbox. 50953 Find/Replace dialog: More options on by default 51010 Find and Replace in Formula Editor 51653 Find/Replace not displaying properly 53113 find consistent shortcut key for Navigator for all modules 55186 Overlapping hotkey (~O) in English FindReplace dialogue 55220
[discuss] Re: [dev] Re: [discuss] Incubator for vba macros
Hi, i agree 100% with Laurent, it means a second API and that of course is probably not what we want. But the question is how we can address all the VBA programmers to migrate to OpenOffice and it's complete different API model. Does it make sense to have a migration layer on top of the existing API for exactly the VBA and Basic programmers in general? I am not sure, the main API focus will be still on the UNO API and we will go forward with this approach. The VBA wrapper API is implemented in UNO as well and makes use of the existing API. That means it would be one abstaction layer higher and of course one indirection more which means slower than the normal API. From my point of view this kind of wrapper API should be used for migration only and everything else should use the existing UNO API. It can be designed as an extension package and people who want use it can install this package optionally for example. I am flexible when we think we need it i am willing to support it. But of course the VBA API is not better than our existing API (far from it), it has only the advantage that it is well known, has great IDE support (MS Dev Studio), is well documented (thousands of books) and many many people use it. I personally believe that we will never reach a 100% roundtrip with macros and i would concentrate on the existing API and improvements in this area. Some of our existing APIs should be redesigned or improved by using the UNO ease of use features and a lot of other things can be done to simplify the development of our existing API. so no vote from my side, no +1 and no -1, only the offering to support the project on the level of the existing API. Juergen Laurent Godard wrote: Hi Noel Thanks for your proposal and your presentation I'm aware that VBA macros are a problem on a migration and something has to be done. So you're proposal is welcomed Nevertheless, I'm afraid that using VBA paradigm inside OOo will more hurt than solve the problem. VBA has 2 parts : the language and the objects I'm not talking about the syntax here. Some compatibility efforts have been done in this directon and can be improved. The problem, imho, is on the API level Giving VBA support as you propose is implementing a new API for objects. You will then have two ways for defining objects : the OOo API one, The MS VBA one. It will be more difficult to understand things as these two objects, will have difference : a VBA cell is different tha an OOo one. How does this interact ? Is a VBA macro allowed to mix both API ? Is python script allowed to use VBA objects and OOo objects ? Are VBA macros only restricted to MS File format (i see no technical reasons for this) For me, at the end, it will be the end of any scripting language except VBA one. Forget OOoBasic, python, Beanshell or javascript. VBA is widely spread due to MS file format domination. Many people do know how to create VBA macros and then it will end with a big proportion of this language. A lot of documentation exists and we will be asked more and more to implement VBA subtilities But, VBA is not free ! OOo Project has no influence on its specification and it can be changed without any warning (look at the difference between MsOffice versions) Moreover, what about legal issues ? Are we sure there are any patent on this ? Are we allowed to implement an interpreter ? Noel, I'm really enthousiastic by you project in a technical point of view. But, i have to say -1 for the resons i gave, unless we build some policies like (only proposal, ideas not worked) - restrict vba to ms office file format (not opendocument or addons) - translate the VBA source code to OOo API to only have to deal with one model So -1 for me But totally open to discussion Regards Laurent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] openoffice with screenreaders
Hi Chris, i am no accessibility expert but maybe you can help to improve the accessibility features by doing some tests and provide direct feedback on what is missing or what can be improved. Regards Juergen chris bruinenberg wrote: hey I am a blind user. I have been trying out openoffice and i really like it but i have a question. Openoffice works good at reading text but is there a way to make it read the tool bars any better. I really like your product. thank you for your time! Chris _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ - 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: [discuss] Writer 2.0 suggestion
Hi Bill, it sounds like a valid feature request to me. Go ahead and submit it as a feature request. - Juergen B Terramorse wrote: I have been trying to use 2.0, and there is a really big hurdle or missing feature for me (or is it a bug?): When using the sliders to change paragraph indents or margins, they do not snap to a grid or increment and are therefore impossible to use accurately. The only accurate way is to enter values into the dialog boxes. I have turned on Grid and Align to Grid in options to no avail. This is just awful, and I can't imaging committing to the product with the ability to snap to some logical increment, such as 1/4 inch, 1/8 inch, 0.1 inch. Ideally the snap increment would be user-definable, like a CAD program. Doing layout, setting up paragraph styles and arranging documents is just not possible without it IMHO. MS Word 2000, where we stopped, does snap to 1/8 increments, and when you hold down the ALT key it disables the snap function, the slider moves freely and the dimension is graphically shown (like 1.38) - Very nice. I keep thinking this must be a bug - how could you design a graphics program (which most APP's is) without this ability. Can you tell that I am an Architect? Please add in! I'd love to switch, but this is a deal-breaker. Bill - 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: [interface-discuss] Re: [interface-announce] info/CWS skeletonmaker : new class ::cppu::BaseMutex
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Jürgen,
cppuhelper/basemutex.hxxbr
class BaseMutex
{
protected:
mutable ::osl::Mutex m_mutex;
};
If we would have naming conventions across projects, and m_mutex would
have been named m_aMutex, then ::comphelper::OBaseMutex - which serves
exactly the same purpose - could have been easily removed. This way, we
simply have duplicated code :-\
i agree, i wasn't aware of this comphelper::OBaseMutex and i will adapt
the new base class in comphelper.
In a second step i will deprecate the comphelper::OBaseMutex and in a
final we should remove the comphlper::OBaseMutex
- Juergen
Ciao
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [interface-discuss] Re: [interface-announce] info/CWS skeletonmaker : new class ::cppu::BaseMutex
Jürgen Schmidt wrote:
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Jürgen,
cppuhelper/basemutex.hxxbr
class BaseMutex
{
protected:
mutable ::osl::Mutex m_mutex;
};
If we would have naming conventions across projects, and m_mutex would
have been named m_aMutex, then ::comphelper::OBaseMutex - which serves
exactly the same purpose - could have been easily removed. This way, we
simply have duplicated code :-\
i agree, i wasn't aware of this comphelper::OBaseMutex and i will adapt
the new base class in comphelper.
In a second step i will deprecate the comphelper::OBaseMutex and in a
final we should remove the comphlper::OBaseMutex
- Juergen
i have changed the member in cppu::BaseMutex and have inserted a comment
in comphelper::OBaseMutex that this class is deprecated and should not
longer used with a pointer to the new cppu::BaseMutex which should used
instead.
In a next step i will exchange all occurrences of comphelper::OBaseMutex
with cppu::BaseMutex and will then remove the comphelper::OBaseMutex
(separate new cws, OO.org 3.0 timeframe).
- Juergen
Ciao
Frank
-
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: [discuss] REFERENCE: Envelope Creation, Address Merge and Printing
WRW-FC4-1 wrote: OpenOffice Personnel, During daily OO use I find that no 'envelope' related capability exists. This is not typically an issue as I employ 'print to .pdf' function to send most documentation. However, the inability to create, address and print a simple envelope within OO2 'beta' causes me to wonder if this project will become suitable replacement software for home or business use. Envelope manipulation is VITAL! One would expect the new OO2 'Open Document format' (.odf) to replace ADOBE's (.pdf), but you must be able to create, address and print a common envelope for 'snail mail' use. Very surprised about this issue within OO, (A 'Show Stopper' issue to me!) WR'Bill'Walling, President - STC with the menu entry Insert -Envelope you can open a dilaog to insert an envelope in the open document or in a new document. You can further select a database and can selcect and insert database fields as address fields in the address section, can specify the format, the position and so on. I would say they that everything you have requested is still in place and can be achieved with the current version. Maybe your concern is that it can't be find from somebody who is not familar with the product and that we can maybe improve the usability of this feature ;-) -Juergen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Poor choice of macro language
Daniel Kasak wrote: Chris Benatar wrote: snipped I am sure that OO.o software is some of the best written code around but it seems that not enough thought and effort has been given to the overall concepts and target groups. I am well aware that the choice of language was largely determined by the huge influence of Sun Microsystems which is to be expected, but the problem however still remains - you are throwing gibberish (from the users perspective) at the users and they run away. Just found this thread. Better late than never. I completely agree. I've spent literally days agonising over scripts that would have taken my 5 minutes in VB Word / Excel. For example I made a script that pulls data from a database, based on data entered in a dialog, and dumps it into a text document. It took multiple attempts ( between which I gave up and swore never to return ) and probably 5 days ( combined work ) of frigging around to get it to work. I've since decided that anything needing Macros needs MS Office. Everything else can use OpenOffice. For database apps, I've rolled my own solution with Gtk2-Perl. If people want OOBasic to get some traction, it *needs* to be easy to do things like: Range( ActiveCell, ActiveCell.Offset(5,10) ).Select Selection.Copy Sheet(SomeSheet).Activate ActiveSheet.Paste If people have to refer to use 10x the code and refer to garbage like: com.sun.star on every line, then they're just not going to use it. Perhaps someone should set up a study similar to the usage studies that compare tasks under Word OO Writer ... but instead of getting end-users to do some formatting and a mail merge, get some programmers to do something like the above ( or the parent's post ). The simple fact is that most people don't care how much cooler OOBasic is than VB, or how much more you can do, or how much better designed it is. Most people just want to do simple scripting, and for that, OOBasic is the worst language for the job. Even in my days of Cobol at uni, I've never been OOBasic as a programming language is quite simple and similar to VB. What you mean is the API which of course is completely different than the API from MS. I agree that we can make things easier, we have learned a lot and we will address these things in the future. Even for OOBasic we will introduce more syntactical suggar (as MS did it) to make things easier. Juergen so frustrated with a programming language, as when I was copying and pasting values in OOBasic. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OOo HTML export gives inefficient CSS
Hi, sorry for the late response but i have probably overlooked this mail. It is very interesting but let me give you some info how the html is generated. The developers guide used flat xml format, a special filter writing all xml streams into one stream. The html code is generated by using a xsl transformation (the same xslt is used internally for xhtml export) + some scripting. The xslt simply transform the styles and definitely doesn't know anything about automatic styles. Your measured difference is really significant and i want to take a closer look on it. Can you send me your changed css file so that i can take a look on it. Thanks Juergen Shez wrote: Others have commented on how OOo produces rather convoluted markup when exporting SXW files as HTML, but since the pages usually look fine I'd never really worried about it until yesterday, when I discovered that the morass of CSS produced can actually cause a 25x performance hit on page load times! Here's the details... I just downloaded the OOo SDK which contains the developer guide in the form of a number of large HTML files. The fact that the linked CSS stylesheets contain a myriad of styles named P1, P2 .. P38, T1..T20 etc in addition to more normally-named styles betrays that these HTML files started life as SXW files that were then saved as HTML. When I started using the documentation I found the pages loaded into my browser very slowly. I thought at first it was just their size (many of the files are 10,000 lines long), but then I began to wonder about the huge CSS files they were using, which typically contain about 200 rules for up to 1000 named styles! Some rules apply to over 100 named styles, most of which seem to be redundant. So I replaced the supplied CSS files with a minimalist one of my own devising, containing just 10 rules for 15 key styles. The resultant HTML pages looked just as good (in fact better, if I do say so myself!), but the astounding thing was the difference in load times. Here are my timings for fully loading two sample pages into IE5 on a 500MHz Win98 machine: OOo CSS My CSS File name size 20 sec 2 sec DevelopersGuide.htm (251KB) 55 sec 2 sec profUNO.htm (590KB) I think you will agree the difference is astonishing. Yet the only thing I changed was the external stylesheet. These load times make all the difference between being able to flit back and forth between sections at will, and having a document which is barely usable. The moral is that OOo's HTML export really does need cleaning up! Part of it is OOo's tendency to make lots of internal auto-styles (e.g. P1, P2, etc for paragraphs) and then save all of these rather than just the named ones chosen by the user. (And I can't help wondering whether all these masses of styles might also be a factor in OOo itself being so sluggish, after all the XML rendering task it faces is much the same as the HTML rendering task of a browser.) To some extent though, better exporting would also require more disciplined use of styles by the user to ensure that autostyles were not required. For instance in the above Developer's Guide, I found that many code examples which should logically have had the .CODE paragraph style instead used a mishmash of doppelganger autostyles whose names changed name from line to line within a single block of text. Whether this is because of a failure of OOo to automatically retain the prevailing style name from paragraph to paragraph, or because of haphazard authorship, I don't know, but it leads to a situation where behind visually homogenous sections of rendered text lies a confetti-like HTML source in which nearly every line has a different paragraph style name. This in turn has ramifications for Writer documents themselves and the difficulties some people have had in using and altering styles, getting unexpected effects, etc. -Shez. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Poor choice of macro language (Object Model)
Ian Laurenson wrote: On Wed, 2005-06-01 at 10:06, Mathias Bauer wrote: Ian Laurenson wrote: * In Writer searching is at a document level thus coding for searching within a selection is extremely tedious and the resulting code is slow. Interesting, can you provide an example that shows the problem? oSearchDescriptor = thisComponent.createSearchDescriptor oSearchDescriptor.setSearchString(the) oFirstSelection = _ thisComponent.getcurrentController.getSelection.getByIndex(0) oFound = thisComponent.findNext(oFirstSelection, oSearchDescriptor) As FindNext is only a method of the Writer component and not of a text range, if the search string is not in the selection the code continues searching until either the end of the document or the string is found, where upon you need to check if it is inside the range with something like: i agree that sometimes the generic interfaces are not enough (here XSearchable, where the first parameter of findNext only specifies the start point). I can only say please communicate the weakness of API's and/or submit RFE's so that we can try to improve it. I know that we have such weakness in a lot of areas of the API. But i also know that it is not easy to improve it that it would be sufficient for all use cases. Especially missing documentation (e.g. properties, interfaces) are bad and can be fixed simply. Juergen bFound = (thisComponent.getText.compareRegionEnds(oFound, _ oFirstSelection.getEnd) -1) But this is an over simplification as the text ranges may not belong to the same text range (e.g. in Table), and the end of a text range is determined by the direction of the selection. For a more complete and working example see: IannzFindReplace.sxw available from: http://homepages.paradise.net.nz/hillview/OOo/ * Having an enumeration for PageLayout that doesn't include an option for none when you simply aren't concerned about duplex printing. Sorry, I don't understand this. Can you show it with a few code lines? I was referring to: http://www.openoffice.org/issues/show_bug.cgi?id=3910 This issue is about the difficultly to avoid having a blank page automatically inserted to make sure that odd numbered pages are always right facing pages. All of the enumerations for com.sun.star.style.PageStyleLayout are about left and right facing pages, there is no way of specifying that left and right facing pages are to be ignored, which is relevant for simplex printing or as a desirable option for electronic printing. A much higher priority for me is having more in the API such as the ability to easily have docked/floating windows in extensions. This is a feature we have considered for the next release. The biggest obstacle is that we lack a proper GUI toolkit, but at least we should be able to offer all controls you can use in a basic dialog also for docking/floating windows. As an example, we could use the xml description of a Basic dialog and declare it as a floater or a docking window. Docked/floating windows is quite an important issue for me. Is there anyway that I can create a component with this functionality now? or Should I look into helping to change the source code for this issue (this would be my first attempt at writing OOo source code - so I may need some help)? or Should I just be patient and wait? Thanks, Ian - 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: [discuss] Running OO.o macros in other word processors?
Hi, the most important thing is the UNO API from OOo. UNO the underlying component model will be extracted from OOo soon so that it should be possible for other applications to use it as well. The whole API is defined in IDL and OOo provides one possible implementation for this abstract API. So if other applications want to be able to run OOo macros they can provide an implementation for this API too. Furthermore they have to provide a BASIC runtime. Probably there is much more to do but without the mentioned things you won't be able to run macros either way. And of course the best thing would be to implement the API from scratch because otherwise you have to reuse more or less the whole OOo ;-) Juergen M. Fioretti wrote: Greetings, OpenDocument can be used by any Office suite or other software, but what if a file also contains OO.o macros? What if developers of KOffice, AbiWord, whatever... wanted to add this support to their program? Is it possible? How? How much big of a task would it be? Which kind of work should be done? Which part of the OO.o codebase should be imported? Is it possible license wise, to use it into a GPL program? Or should it be implemented from scratch? If so, where are the specs? Which other technologies does it depend on? Java, anything else? In general, what is the relevant documentation to read, for a developer? And the proper mailing list where to ask further questions? Any comment is appreciated. Ciao, Marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Running OO.o macros in other word processors?
Alexandro Colorado wrote: Language for OOo can be done on OOoBasic, C++ Python and many other bindings, Novell is working on the C# binding and is going quite good. OOo has already a C# binding for CLI on the windows platform. Novell works on one for Mono and of course nothing has contributed back to OO until now as far as i know ;-) Juergen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] On the acceptance of an OO.o extension installer
M. Fioretti wrote: Daniel, 2) note that I and Nicolas are not even asking that you or others give up UNO packaging. We are saying please find out and consistently do whatever is necessary so that it is _also_ easy for _others_ to ah, you mean we should think about your problem (ok not only yours) and should do the work for you that you can easily use it. So work OpenSource, interesting ;-) Why don't you start to write a tool to convert UNO packages in rpm's and contributes this tool to the SDK for example. I will give you advise for the UNO package stuff, with rpm's your are probably more familar than i. Firsd idea: 1. simply put thre UNO pakcage in a rpm 2. find a common directory where the UNO package will be installed from the rpm 3. post install script to run unopkg on the package for OpenOffice, StarOffice, KOffice or whatever is installed or specified Ok, some changes in other places are probably necessary, but sao what that should b eeasy. Juergen (automatically) make a native Linux package of your contribution. Ciao, Marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] On the acceptance of an OO.o extension installer
M. Fioretti wrote: On Fri, May 13, 2005 09:12:07 AM +0200, Jürgen Schmidt ([EMAIL PROTECTED]) wrote: First idea: 1. simply put thre UNO pakcage in a rpm 2. find a common directory where the UNO package will be installed from the rpm 3. post install script to run unopkg on the package for OpenOffice, StarOffice, KOffice or whatever is installed or specified My first gut reaction to this is why one should require unopkg and whatever it needs to just install some OpenDocument templates?? but I'll leave Nicolas and other packagers much more expert than me to comment on this. Thank for your input though. ok, i meant primarily the macro and component (add-on) stuff which is of course more specific for OO. But of course deploying templates with UNO packages would be an interesting idea as well. BTW, what are the dependencies of unopkg? Does it by any mean pretend that all of OpenOffice is installed? yes, unopkg needs a complete installed OO. But this can change in the future in conjunction with an URE (UNO Runtime Environment). Juergen Ciao, Marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
