Re: [dev]
Andreas Saeger wrote: T. J. Frazier wrote: Andreas Saeger wrote: You are using Excel as application development platform. ... And why not? So do I. Stable, customizable, automatically cross-platform, and free. Excel is *what*? My thought was incompletely expressed; /mea culpa/ :-( I should have said, If you want to use Calc that way, why not? Hopefully, the list of attributes would lead the reader to apply them to the proper antecedent. * Menus and XML All the menus (and toolbars) in OO.o are kept in XML files. Interfaces are available to customize these to any desired degree. Considerable recent work has made this easier, for the benefit of extensions. So you've got to rewrite every single line of VBA code. Every line that deals with system interfaces? Most of them, yes. * Extensions You may want to investigate packaging your software as an extension. That avoids license problems, and makes user installation very easy. After your 2000 lines of VBA code changed to 3500 lines of StarBasic. The quantity of new code required for a platform conversion is dependent on the modularity of the system interface references. Very modular (professional) code requires little expansion or rework. * Incompatibilities The OO.o Basic language is nearly 100% compatible with other Basic variants. It is the Application Program Interface (API) elements that are only partly compatible. The underlying models of OO.o are not, and never were intended to be, compatible with Microsoft. To some extent, the API tries to bridge this gap. StarBasic is strictly procedural while talking to a 100% object oriented API (and only that particular API). It has bugs, some of them severe. It is slow. It comes with a tiny set of runtime functions. /Seriatim:/ * Basic is a second-generation, procedural language. I classify VBA, OO.o Basic, and (I presume) StarBasic alike, as procedural languages with object-oriented features. * A single, 100% object-oriented API is a major feature. The whole idea is to let the programmer worry about only one interface -- UNO -- and let UNO worry about the rest of the world. How well, and how thoroughly, UNO does this are clearly matters of concern, and debatable. * Bugs: Issuezilla lists 99 open issues for Basic, many of which are P4 and P5 enhancement requests; none are above P3. Personal priority assessments of individual bugs may vary sharply from these official assignments. * Slow? It's an interpreted language. Slow as compared to what? * Runtime functions: few programs, or programmers, use more than a small subset of the available functions. Of course, they use /different/ subsets . . . One nice thing about OO.o is that there are a number of routes to follow, to result in enhanced functionality, depending on the time, effort, and skills one is willing to bring to bear on a particular problem. * Further reading I commend to your attention the wiki page of the Documentation Project: http://wiki.services.openoffice.org/wiki/Documentation Small snippets of that documentation (corrections) are written by me. And by me, and hundreds of others; all contributions greatly appreciated. where you will find links to the Developer's Guide and the Basic Programmer's Guide. You may wish to investigate Category:Extensions on the wiki, as well. HTH I commend to your attention the big, old VBA solution linked in the top post. It will run out some day or rewritten entirely but never converted to some other spreadsheet application. Now it runs for every single client. A rewrite for OOo gives how many additional clients? That's a very good marketing question. How many potential clients run (or would like to run) on other platforms? How many would be grateful for the introduction to OO.o, and the reduced expenses that could follow? -- /tj/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Would open office work for us?
Andreas Saeger wrote: You are using Excel as application development platform. ... And why not? So do I. Stable, customizable, automatically cross-platform, and free. * Menus and XML All the menus (and toolbars) in OO.o are kept in XML files. Interfaces are available to customize these to any desired degree. Considerable recent work has made this easier, for the benefit of extensions. * Extensions You may want to investigate packaging your software as an extension. That avoids license problems, and makes user installation very easy. * Incompatibilities The OO.o Basic language is nearly 100% compatible with other Basic variants. It is the Application Program Interface (API) elements that are only partly compatible. The underlying models of OO.o are not, and never were intended to be, compatible with Microsoft. To some extent, the API tries to bridge this gap. * Further reading I commend to your attention the wiki page of the Documentation Project: http://wiki.services.openoffice.org/wiki/Documentation where you will find links to the Developer's Guide and the Basic Programmer's Guide. You may wish to investigate Category:Extensions on the wiki, as well. HTH -- /tj/ T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
Jens-Heiner Rechtien wrote: Migration to Mercurial == [snip...] Documentation: -- Main entry point: http://wiki.services.openoffice.org/wiki/Mercurial Björn has done a beautiful job of adding a TOC for the Mercurial pages. The one problem I see is, will potential users be able to find it? Please think about where developers would look for this info, then add links there. I added one on the main wiki page. -- /tj/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Getting localized text in a macro
Cor Nouws wrote: Hi Alan, Alan Yaniger wrote (19-10-2009 10:25) How do I get the localized names of paragraph styles in a Writer document? I can use the following macro code to get the *English* names of all paragraph styles in a document: oFamilies = ThisComponent.StyleFamilies oStyles = oFamilies.getByName(ParagraphStyles) mStyleNames = oStyles.getElementNames() but I want the translated names. The translated names are the property DisplayName of each member of the styles family. You have to loop over all the elements of the family to get the DisplayNames. Sorry for the cross-posting, but I got no response on the l10n list. This kind of question is best at its place on d...@api.openoffice.org So maybe for a next time ;-) Best regards, Cor Thanks, Cor. We'll try to mention this in the Basic Guide, on the wiki. -- /tj/ T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Improving HTML-output after import from MS-Word (again)
Larry, Sorry you are having trouble with the ml. If you can't get it straightened out yourself, ask for help on dev-web. Meanwhile, here's the response you got to your first try. HTH, /tj/ Holger Meyer wrote: I noticed this reply to your message on the list (from mba). Seems like you did not get it? larrydlefever wrote: per http://svn.services.openoffice.org/opengrok/xref/DEV300_m59/sw/source/filter/html/htmlatr.cxx#1013 there seem to be certain rules regarding when a P tag is output when using Save as ... in Writer (I tried to translate the German here into English -- I need help with that, incidentally): Ein P wird nur geschrieben, wenn - wir in keiner OL/UL/DL sind, oder - der Absatz einer OL/UL nicht numeriert ist, oder - keine Styles exportiert werden und - ein unterer Abstand oder - eine Absatz-Ausrichtung existiert, ode - Styles exportiert werden und, - die Textkoerper-Vorlage geaendert wurde, oder - ein Benutzer-Format exportiert wird, oder - Absatz-Attribute existieren A P is written only if: - we're not in a list of any kind; or - the paragraph we're in is in an unordered list; or - no Styles are being exported and a (lower distance?) exists or a paragraph-adjustment exists; or - Styles are being exported and the text-body format/style? was changed; or - a User-defined format is being exported; or - paragraph-attributes exist I want to know if I'd need to hack that native code there, in order to get cleaner HTML-output than I'm currently getting from OpenOffice. Yes. Incidentally, I've also tried Exporting as XHTML, but the resultant output is even worse than that from Save as ...: stuff that should not appear in a list does so, etc. Could you create an issue with a sample document showing the problem and assign it to sus? I've tweaked the Java-example servlet for document-conversion, so it takes an MS-Word doc as upload and returns (really just the file:/// URL of) an HTML-document. I do like so in my code: // Setting the filter name propertyvalue[1] = new PropertyValue(); propertyvalue[1].Name = FilterName; propertyvalue[1].Value = HTML (StarWriter); ... which I believe means, effectively, Save as ..., rather than Export, the latter involving a different area of the OpenOffice codebase, if I'm not mistaken. Whether SaveAs or Export is chosen just depends on whether you use storeAsURL or storeToURL. The difference is only that in one case the document takes over the new location while in the other it doesn't. The GUI stuff around these two function also uses different filters in both areas, but that's a limitation you don't have when using the API. All filters suitable for SaveAs can be used for Export also (but not the other way around as only filters for formats that OOo can load will be accepted in storeAsURL). So, what's the best way to make the desired improvements in the HTML-output? As both filters (the C++ one for HTML as well as the xslt based one for XHTML) seem to fail for you, the best way probably is the one you are more familiar with. If you know something about xslt, perhaps hacking the xslt for XHTML is better, because the native filter not only requires good C++ knowledge but also getting familiar with an unpredictable amount of OOo code (what exactly you will need to know depends on where your journey will take you). Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- /tj/ T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Error building on cygwin: Missing nsIAbLDAPAttributeMap.h
Bjoern Michaelsen wrote: T. J. Frazier tjfrazier at cfl.rr.com writes: My thought is to put the table itself at the top ... Yeah, maybe that would be better. Originally, I intended not having that stuff on the top because a big table might scare away newcomers. Go ahead, Ill have a look later (just make sure that you dont drop any footnotes ;-) ). Maybe you could also update the linux stuff to the same format. BTW, I too rarely do manual community builds on windows myself (Im working on linux and use buildbots whereever I can). Done. /*Please*/ have a look. -- /tj/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Error building on cygwin: Missing nsIAbLDAPAttributeMap.h
Bjoern Michaelsen wrote: Stephan Bergmann Stephan.Bergmann at Sun.COM writes: (Put Björn on cc, who might like to clarify in the guide which zips to download for which source revision.) Done: Put the link for current milestones in the Building Guide, and added the older links on the page about building older releases/milestones. Have Fun, Bjoern Björn, Did you miss the second link, down in the adding required files to the build tree section? I'd have fixed this myself, but do we want a better solution, with the link in only one place? -- /tj/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Error building on cygwin: Missing nsIAbLDAPAttributeMap.h
Bjoern Michaelsen wrote: T. J. Frazier tjfrazier at cfl.rr.com writes: I'd have fixed this myself, but do we want a better solution, with the link in only one place? I would prefer a link in one place too, but the links are sensible in both locations, I think (I would like to have the needed downloads at the top of the page), but I would also want those to identify what goes where. If you have a good solution for this, go ahead (maybe one could just name the requirements at the top and refer to the table below for source and destination locations?). My thought is to put the table itself at the top (with a brief introduction), and let all the explanations follow, with no other external links. From our point of view, it makes maintenance easier and more reliable. For the users, the table is what they're going to want to refer to, probably over and over; having it at the top makes it easy to find. If we tune the section headers so that they have the same names as the table entries, then the users can use the TOC to go straight to some individual explanation they need to look up. Or, on-page links to the sections would be easy enough. While I'm at it, I may move that very useful CLI-for-dummies tip up into the first description of Cygwin. All this is a fairly major reshuffle. If you have no major objections, I'll do it, but your critical review (of the plan, and the result) is very important: I've never built OO.o at all. -- /tj/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Consolidating build instructions for the community
Hi, Per, Per Eriksson wrote: Hi all, Thanks a lot for working on this. You've done a tremendously good job with the instructions. Bjoern, thanks a lot for all the hard work. Is it possible to get the Anno 2009 style on the TOC header as in the DevGuide? ;-) Actually, Clayton did all the work of converting the Guide TOC to template form, even updating the maintenance instructions I left on the Talk page of the Intro. His major reason was for uniformity among all the guides, so he'll have to answer your question. You should know, however, that transclusion works just fine. If you knowledgeable writing-folks (as contrasted with formatting folks like me) decide that information should be duplicated among some pages, it's easy to do. -- /tj/ Per P.S. I will add this as completed: http://wiki.services.openoffice.org/wiki/Development/Simplifying_entry_for_new_developers -- /tj/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Development Roadmap
Hi, Martin, Could I ask why these docs aren't available (and advertised!) as *.odt? Also available as PDF is fine, but /only/ PDF looks like our own product wouldn't do the job. /tj/ Martin Hollmichel wrote: Per Eriksson wrote: Hello, Do we have a roadmap like this for the current versions and branches? http://development.openoffice.org/releases/oo_branches.pdf we do have http://development.openoffice.org/releases/ooo_roadmap.pdf which is more up to date, I will also provide a new one, Do we have one that summarizes our continued development from start to present? :-) no, but it would really nice to get one. This would be very nice to have and look at. Per Martin -- /tj/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev]Re: Consolidating build instructions for the community
Bjoern Michaelsen wrote: T. J. Frazier tjfrazier at cfl.rr.com writes: Okay, guys, TOC template time,... Please go ahead, I am not really that skilled with wiki stuff. From what I read on transclusion when you mentioned it, it seems to be the right tool for the job. done -- /tj/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev]Re: Consolidating build instructions for the community
Bjoern Michaelsen wrote: Per Eriksson pereriksson at openoffice.org writes: I agree that striping OpenOffice.org and moving to documentation is a good idea. Bjoern feel free to do it. done. Okay, guys, TOC template time, or transclusion time, to get rid of all that redirect trash at the top of every referenced page. The TOC has to be changed on every BG page. Is anybody else volunteering, or shall I do something (transclusion or template, not sure which)? -- /tj/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Consolidating build instructions for the community
Bjoern Michaelsen wrote: Per Eriksson pereriksson at openoffice.org writes: Christian had a good point regarding simple instructions previously. As you mentioned, the instructions are similar. There are big possibilities that we want to add platform-specific notes, comments, references to other documentation (e.g. the Solaris documentation) that is platform-specific later, letting the content remain today would give us most options available, which I think is a strong benefit. I actually think that is misguided, because building instructions are changing fast. I have brought Windows and Linux instructions pretty much up to date and in sync. However, I also had to: - copy a lot of useful (platform independent) information from one article to another because it was missing there. - delete quite some outdated/misleading information that was only removed/updated for one platform. If nobody actively supervises the docs and keeps them in sync, then in 6 month a new dev will need to read the docs of _all_ platforms, if he does not want to miss something, because lots of platform independent information was only added/updated/removed on the article of one platform. Also the logical structure of the articles will divert and thus make it harder for a dev to transplant his knowledge from one platform to another (simply because he wouldnt be able to easily navigate the other articles because of the different structure). Having one article per platform would be a nifty idea - if we wrote a book and the build enviroment wouldnt be changing. But trust me: After reading the mess that were our build docs (scattered over way too many different places), I can assure you: Putting platform independent infos redundant in articles for each platform is a Bad Thing(tm). Have Fun, Bjoern +1 This is a very high-maintenance chunk of information. But are you ruling out transclusion? With sub-pages, and links on the Talk pages, for easy maintenance. BTW, thanks for all the hard work. It looks very well done. /tj/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev]
Per Eriksson wrote: - snip - In the meanwhile I will make sure to make the TOC available on all pages for navigational reasons ;-) Hi, Per I added a link to your Building Guide to the Documentation page on the wiki [1]. We have some nice TOC templates (see the Basic Guide or Writer Guide, for example) which you are certainly welcome to use. Or, if you like, I can take a crack at it, though it probably won't be finished before tomorrow. [1] http://wiki.services.openoffice.org/wiki/Documentation Best wishes on the project! /tj/ -- - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] High contrast mode
Philipp Lohmann wrote: (snip) So for changing the high contrast behavior I propose to change our code to use the formerly strongly discouraged HC flag and rely on its correct setting to decide what (e.g) icon set to render. Unless someone objects I will change the according code instances (of which there are quite a few :-( ). Opinions ? Kind regards, pl [1] http://www.openoffice.org/issues/show_bug.cgi?id=35482 +1 First, thanks for all the hard work. Judging from the comments on all the issues, you have gone the extra mile to try to do this right. Next, there are several related problems; honoring the HC flag is probably the right way to solve this particular one. Finally, your comments are quite right, that there will still be complaints. Probably not everyone will be happy, until we have a line in Tools Options that has a little spin box (three boxes?) to define when IsDark() returns True or False. But that is for the future, if someone cares enough to write an RFE for it. -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Underline thickness
Tantai Thanakanok wrote: To all , OpenOffice.org underline for Thai font is too thick compare to Microsoft Office. The issue (55341) was fixed but users in many organizations still comment that underline is too thick. I have read the code that calculate the underline size in outdev3.cxx. I found 2 possible solution to fix this. 1. change the calculation of underline. 2. get underline and thickness properties from font (issue 89284). Which solution is the better? Thanks. You may wish to add yourself as CC on issue 89284. /tj/ -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] help with openofice-3.0.1-64-bitCLFS-linux
Hi, Rene, Rene Engelhard wrote: lux-integ wrote: Test Complete ^^^ No environment file will be generated ^^^ There were no warnings however there appears to be no Makefile nor bootstrap.sh Of course not. Re-check your configure flags again, and please learn to read. iDo you you have --enable-check-only in the configure line by chance? AC_ARG_ENABLE(check-only, [ --enable-check-only Use this option option if you just want to check your environment. This option stops the generation of an env.set Usage: --enable-check-only=yes Regards, Rene [1] btw, it's not openoffice Just a suggestion for the RE's, from the old guy, who used to generate scripts like this, long ago and far away. We thought it useful to say something like: **--enable-check-only=yes** No environment file will be generated -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] help with openofice-3.0.1-64-bitCLFS-linux
Rene Engelhard wrote: Hi, T. J. Frazier wrote: We thought it useful to say something like: **--enable-check-only=yes** No environment file will be generated Is it not. It is redundant. People who used --enable-check-only should have read the description it at which time it would have been clear. Regards, Rene You are of course correct, that the suggested information is redundant; that is usually a pejorative term, especially in programming. However, what we are dealing with here is human-to-human communication-- from the script-writer to the script-user--and redundancy, or repetition, is an important part of human communication. We found such redundancy useful, because of the following logic chain: 1) Who are the most frequent users of obscure and arcane parameters? Why . . . we are! The RE's, themselves. 2) Who gets the dull job of verifying that such things work? The new guy, typically a Clueless Newbie (CN), who is already suffering from information overload. 3) Who is most likely to make an error in using such things? The CN, of course. Therefore, it benefits us directly, to make the learning process as reasonably painless as we can. 4) How much of our user-developer base could be called CN? The obvious answer is, Not many, at any one time. But the important answer is, /Everybody/ starts that way. Hence, minor efforts that make the process more user-friendly are very much in order. HTH, /tj/ -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] MediaWiki *import* function ?
Hi, tora - Takamichi Akiyama wrote: Hi, Rich wrote: I immensily enjoy the MediaWiki export function, but in order to make it the perfect WYSIWIG MediaWiki editor, it would also need a MediaWiki *import* function. Is anything like that currently planned ? If I tried to realize such a function that converts MediaWiki's format into OpenOffice.org format, there were some ideas: Idea 1: Implement it in the MediaWiki as its extension. Idea 2: Realize it as an offline tool. Idea 3: Incorporate it in the OpenOffice.org as an import filter or in a copy-and-paste function of OpenOffice.org. IMHO, idea 1 would be the easiest, reliable, robust way. With an extension of the MediaWiki, a link labeled download this page as an OpenOffice.org file might be one of the possible user interface implementations. The reason is that MediaWiki itself knows how to interpret MediaWiki format and how to produce its corresponding HTML format. So, what we might need to work to realize it would be just to write a code producing ODF format instead of HTML format. If we had implemented it in our OpenOffice.org, we would forever have to follow up MediaWiki's versions. Its history shows that its format has been being revised version by version and consequently it is easy to infer that its format would be continuously revised in the future. So, it is a MidiaWiki extension exporting its Wiki page into ODF format. I don't know if it is already available or not. :- Regards, Tora @Tora: thank you for the fine insight, as to where most of the problems lie. Do you think it might be useful, to consider a two-step conversion process, using XML as the intermediate step? That is, instead of ODF == Wiki, we could have ODF == XML, and Wiki == XML. The advantage I see is the division of labor. Both groups (MW and OO.o) would likely see those transformations as, not very efficient, but relatively simple. Neither group would have to deal with each other's oddities, only their own. Just a thought. /tj/ -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] OOo BASIC Calc extension - sheet functions in library other than Standard - how ?
Niklas Nebel wrote: On 03/17/09 14:08, Peter Eberlein wrote: Jan Holst Jensen schrieb: Peter Eberlein wrote: no, you cannot add functions to the Standard library using an extension. You'll have to develop an Add-in (in C++, Java or Python). if issue http://qa.openoffice.org/issues/show_bug.cgi?id=53615 (allow other libraries) is solved, things will become easier. It is an issue from 2005, so it seems I shouldn't hold my breath for a solution... ? Ask Niklas... No quick solution in sight. We don't want to load and search all libraries, and we don't have any additional information available besides the function name. Niklas Basic supports the syntax: library-name-dot-function-name, like MyLib.MyFunc. Maybe Calc could, too? Basic Runtime isn't smart enough to try to load the library for you, but Calc could be made that smart. -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi, Frank (and thank you very much for the explanations), Frank Schönheit - Sun Microsystems Germany wrote: Hi T. J., I would *kill* for a little techno-babble here ... Okay, I see your point here. I am still not convinced that transporting the information via css.Exception.Message is the best idea ever, and won't cause problems later on, but I definitely see your point. And I see yours: you are worried that the proposed additions will establish squatter's rights on the field, and be hard to evict, should that become desirable in the future. A definite possibility. .. But logging is a longer-term enhancement, No. Logging facilities are available, and the same script which produces a add file/line info to exceptions patch could equally easily produce a add logger calls patch. Sounds wonderful, and should keep everybody happy. 3.0.2? 3.1? [ ;-) ROFL ] /tj/ -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Mathias Bauer wrote: Frank Schönheit - Sun Microsystems Germany wrote: When we talk about seldom, hard to reproduce errors, then let's introduce a logger which is permanently switched ON, or at least switched ON for log levels = LogLevel.SEVERE. (by default, loggers are OFF, i.e. do not log any event, regardless of the LogLevel.) Everything that must be switched on doesn't help - if an error is hard to reproduce it usually would be gone after switching on the logger after the fact. OTOH, if we had logged the necessary information as part of the exception, the user could save or send it and help us fixing the problem. Mikhail's suggestion is not meant to be a replacement for our suboptimal error handling! But it imposes additional restrictions on a future somewhat-more-optimal solution, thus making it more difficult to design/implement, thus making it even more unlikely (than today) to ever happen. No, it just adds something that can be removed later easily. It does not impose any design constraints on other solutions, especially it does not influence any designs for a better error handling (as it is no real error handling at all). For instance, by putting file/line into the exception message, we will close the door for putting other meaningful information into Exception.Message, because in two years from now on, some people will say that adding other content will break the file/line info feature ... Sorry, I can't take that serious. I don't care for what people will say in a few years, in fact adding line/file information can be removed easily again and it does not prevent adding other stuff in the future. Sure, if you want, you can call it a stopgap solution (that's not the same as a hack!). If you are so interested in getting the real thing, just do it! ;-) But please remember: the most important feature for us is that it must be something that doesn't need activation. If you needed to switch it on, it's too late for those problems we intend to attack. Without having the bigger picture how good error handling should look like, how can we know the suggested solution will fit into this bigger picture, instead of preventing it? As I wrote, this is not about error handling (IMHO a user centric design), it is about user level debugging assistance ( ULDA[TM] ;-)), the stuff you need desperately if things go haywire and you don't have a clue. So far I don't see any reason not to follow Mikhail's suggestion. At least in all projects except dba. ;-) Ciao, Mathias May I agree, wholeheartedly? From my own long years of dealing with users (some of them very angry), I conclude that the *error* is what bothers them, not the error *message*. They just want to get their work done. A little techno-babble is only a small point. Yes, it is possible to overwhelm the user with techno-babble--if we dump 50 or 60 lines of stack trace on them. Adding file-name and line-number doesn't qualify as overwhelming. And, please do not underrate our users. If we were writing a teaching program, aimed at grade-school kids, I would agree that we would need to keep things as simple as possible. But our demographics (from the surveys) show a huge proportion of adults, 20-60 (and a few old geezers like me). They can cope. Consider the opposite case, where user and programmer are _under_whelmed by lack of information. A real case: Line 1: Error saving the document filename : Line 2: Error writing file. I would *kill* for a little techno-babble here (for once, I get to wear the angry user hat). Then I could report the bug, with a chance that somebody could fix it, even without a reproducible case. Notice how useful the wrapper/script solution is, even for those who don't want to use its output. The script produces a nice list of patches (or certainly can be made to), which the programmer can use to check the adequacy of each exception--and then discard! Logging errors is an excellent idea. Keeping such logs short enough to avoid burdening the file system, or performance, but long enough to be useful, is only a small problem, with several possible solutions. But logging is a longer-term enhancement, while wrapping is available quickly, and the two are not mutually exclusive. I suggest doing both. -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] cvs co -r DEV300_m2 swext
Nguyen Vu Hung wrote: ... And I am trying to to add --disable-qadevooo and --disable-mozilla to configure. The page, http://wiki.services.openoffice.org/wiki/Building_OOo_with_Cygwin_on_Windows#Setting_up_the_build_environment states that --disable-mozilla fails with dependency problems. It recommends using --disable-build-mozilla \ in configure, instead. I'm too new at building to know if this might help. /tj/ -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] cvs co -r DEV300_m2 swext
Nguyen Vu Hung wrote: 2009/2/13 T. J. Frazier tjfraz...@cfl.rr.com Nguyen Vu Hung wrote: ... And I am trying to to add --disable-qadevooo and --disable-mozilla to configure. The page, http://wiki.services.openoffice.org/wiki/Building_OOo_with_Cygwin_on_Windows#Setting_up_the_build_environment states that --disable-mozilla fails with dependency problems. It recommends using --disable-build-mozilla \ in configure, instead. I'm too new at building to know if this might help. /tj/ I am building under Linux x86, not WIndows. Understand, but Cygwin creates an artificial Linux environment under Windows. A problem in such an artificial environment might be a problem in a real Linux environment, too. Or not. Best of luck. /tj/ -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] extending the OpenOffice BugBounty Programm
Martin Hollmichel wrote: Hi, last year we initiated the bug bounty program ... Are there any other ideas to make the Program more attractive ? or should we stop this effort because it's hopeless ? May I suggest that some of the bounty money, and/or equivalent time and effort, might be better spent on lowering the entry barriers for newcomers? Consider our target audience, those we're trying to attract. Are we limiting our search to the pool of the Linux/SVN-capable? Or, do we want to fish in the (much larger!) sea of Windows developers? The logic here is, why are they developing under Windows? If we're offering money, we should offer it to the money-hungry. Windows developers would be expectably running Ms's latest-and-greatest, Windows Vista (or W7 pre-releases). If they decide to take a look at the code (Do I want to get involved with this?), they hit an immediate barrier: the SVN folks only boast a client for WXP. A little of our money here, or just a few friendly words, might help. (The developer reaction we want to avoid is, Oh, these kids are locked in their Linux playpen. Forget it!) Removing the next barrier -- allowing (and documenting!) OO.o development under Windows -- involves significant (but not massive) effort on our part. It should be readily doable (assuming a solution for the SVN problem), since both the compilers and the product run under WV. Resources expended on fixing particular bugs will fix those bugs, once. Investing in process improvement should help us forever. -- T. J. Frazier Melbourne, FL (TJFrazier on OO.o) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
