[dev] contribution
hi, I would like to help this (these) project(s). I have skills as both a programmer and a technical writer. If you have needs in either area, let me know. Lawrence Quinn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Help required to start work
Dear Development support of Open Office We want to join the open office project. Our language is Urdu and the project will be under the supervision of the research center CRULP (Center of Research for Urdu Language Processing www.crulp.org http://www.crulp.org/ ). This center is in National University of Computer and Emerging Sciences Lahore Pakistan. Can you please guide us how to register our language and start submitting patches. Waiting for response Regards Ahmed Muaz Research Assistant
Re: [dev] Re: Openoffice bean throwing error while saving in old file format.
priyanka schrieb: I have gone through all the sample code I could find, and I still get a com.sun.star.task.ErrorCodeIOException... i want to save this code just as an Openoffice document ..it still gives the same exception ... xStorable.storeAsURL(C:\\test.odt,storeProps); You have to provide a URL, e.g. file:///C:/test.odt. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Ruediger, Rüdiger Timm wrote: That's a joke, isn't it? From my point of view of course it has to be (according to your numeration) 1. 4. 5. 2. 3. Why would you copy additional stuff into binfilter? We did enormous efforts to get that monster stripped, and you plan to blow it up again. as you may know, we _love_ to blow up and to double the amount of code every year, this is one of our favorites, isn't it? :-) Seriously, the goal certainly is _not_ to unnecessarily increase code size. Ideally binfilters would be well formed Uno components, independently build and deployable. To eventually reach this goal, we need to make it independent of the rest of the office. Or let me phrase it the other way, if we are going to keep binfilters dependent on other C++ parts of the office, we could just have kept the original approach, to never change the application cores incompatible wrt to the old binary file format. Why? If someone does incompatible changes he must do all necessary adaptions in modules above. Regardless of the name of those modules. Why change code in 'sw' but leave 'binfilter/bf_sw' untouched? See above. Keeping binfilter dependent on other C++ code is -a- a maintenance issue, and -b- forbids certain kinds of changes, we want to do. OK, there may be rare cases where no one is able to adapt stone aged binfilter code with reasonable effort. But that is an evidence of incapacity and should be the strict exception. As said above, there are cases where binfilter would hinder the renewal of other code. This is and was the original reason to factor out the binfilters. This is the way we want to go. It was an error in the first place, to ever expose our internal binary formats. binfilters purpose is to correct this error! At least that's my understanding. Please correct me where I am wrong. I tried :-) Rüdiger Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Mathias, Mathias Bauer wrote: I think the problem is that you can't give a fixed order for 2,3 and 4. This must be checked for every single case. Perhaps Kay should point this out in the wiki. I disagree here. Actually the right order is 2,3,4: 3 certainly comes after two, as copying parts of a module is superior to copying the whole module. 4 is after three, as the _goal_ is to make binfilter independent. But IMHO it's clear that option 1 is by far the best and should be aimed for as often as possible and that option 5 should be considered only in desperate cases. Certainly. Copying just some pieces is IMHO OK as well. Especially as these pieces are the things which are going to be changed in the non binfilter code, otherwise there wouldn't be any need to copy. Ciao, Mathias Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Heiner, Jens-Heiner Rechtien wrote: Thorsten Behrens wrote: b) move _all_ modules below binfilter into that module, possibly after stripping them to the necessary minimum. Build it once, and tuck it into a safe place (comes close to a, but is smaller integrates with OOo3). Unrealistic, because rebuilding the binfilters might be necessary for all kind of reasons: compiler changes, base line changes, bug fixes, new platforms etc. Over long it would be part of the regular build again, now only bigger than ever before. Good point. We try to stay ABI compatible but fail once a while ... :-( Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] OOo Wiki: Categories Overview
Hi guys, it seems this is the best list to discuss OOo wiki topics. In my view, the wiki could be somewhat more organized. E.g. it seems that anybody has a different plan and list of categories. To get this more in order I created a page listing the categories we are using, adding short explanations. I also tried to outline how categories could (should?) be used. You may want to take a look at http://wiki.services.openoffice.org/wiki/Categories Feedback certainly welcome. Thanks for listening Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Ruediger, Rüdiger Timm wrote: Sorry, now I see your other mails. Looks loke a mail server problem. I saw the mails appearing in reverse order as well, did not expect you to answer sooo fast :-) Rüdiger Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo Wiki: Categories Overview
Kay Ramme - Sun Germany - Hamburg wrote: Hi guys, it seems this is the best list to discuss OOo wiki topics. In my view, the wiki could be somewhat more organized. E.g. it seems that anybody has a different plan and list of categories. To get this more in order I created a page listing the categories we are using, adding short explanations. I also tried to outline how categories could (should?) be used. You may want to take a look at http://wiki.services.openoffice.org/wiki/Categories Feedback certainly welcome. Not being a native English speaker, I always wondered whether effort is a good term for a category that (as far as I understand it) lists (planned or executed) activities that change the OOo behavior. For me, effort connotes physical (rather than intellectual) labor---but I may be quite wrong. -Stephan Thanks for listening Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Kay, Kay Ramme - Sun Germany - Hamburg wrote: FYI Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently had a discussions regarding how to deal with binfilter in case of incompatible changes of modules used by binfilter. I am still wondering why nobody invited me to this discussion as i surely would have been able to add some background and initial thoughts to the whole theme. Anyways, i am pretty happy with the direction it is taking. We came up with the following recipe: For every request of an additional module for / change of binfilter the following steps are to be tried in the following order: 1. Check if the dependency could not be removed / avoided completely. - For the above change this means, to verify that basctl is indeed needed for loading / storing documents. 2. Copy the code which is needed only. - For the above change this means, that the serializers (import / export) may just be copied out of basctl to binfilter (respectively they may be just reimplemented if this is easier :-) . 3. Copy the whole module. - If the target module is reasonable small, the whole module may be copied to binfilter. For the above change this would mean to copy basctl to binfilter. 4. Adapt binfilter to the incompatible changes done in the dependent module. - For the above change this would mean, to adapt binfilter to the changes done in basctl. 5. Do not change the dependent module incompatible. - For the above change this would mean, not to change basctl incompatible. That's the right way to go. Please take in mind what kind of code is/will be moved to binfilter: - code that is no longer used in the 'living' office modules, but needed by the old binary filter mechanisms - code that is completely rearranged and cannot be adapted to also keep up the needed (C++) APIs and functionalities for binfilter Both cases happen, BECAUSE binfilter allows us to do things like that at all and to enhance the 'living' office modules, not to expand binfilter. The expansion of binfilter is the price to pay to keep the old binary filters running, and that price was intended and is accepted ATM. Do not forget that it is even DANGEROUS to change functionality/code without noticing that binfilter is still using it. Binfilter may well need controlled fixes from time to time in shared code regions which may also enhance the living modules, but the other way around You risk to break binfilter functionality which cannot/is rarely tested anymore. That's (one of the reasons, there were many others) why my initial plan always was to freeze binfilter on a defined state. Defined state means: Let it rest on a published version, this is never deleted and stays buildable (if fixes are needed). Freeze means: Add all still missing and urgently necessary C++ dependencies methodically: Link without the standard modules and add missing code. Yes, this might take a while and is not easy but might have been done by one person methodically, not costing man-years of bandwidth, service, maintaining, bulding, adapting, developer time, ... With the suggested steps we move to that target, so i am happy about them. Comparing the costs spent up to now by all and that will be spent until the goal is reached, i again have to suggest (as years ago) to do it once, by one person and for the next public release. The resulting binfilter module will be an UNO-API only module, independent of 'living' C++ code and can then rest on that version. I created a module page for the binfilter module in the OOo wiki and copied the receipt to this page as well: http://wiki.services.openoffice.org/wiki/Framework/Modules/binfilter Hope that helps Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Armin, Armin Le Grand wrote: I do, but what about the suggestion? Repeating here: Comparing the costs spent up to now by all and that will be spent until the goal is reached, i again have to suggest (as years ago) to do it once, by one person and for the next public release. The resulting binfilter module will be an UNO-API only module, independent of 'living' C++ code and can then rest on that version. I am _all_ for it. What's the amount of work left ? Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Armin Le Grand wrote, On 02/07/07 11:40: Freeze means: Add all still missing and urgently necessary C++ dependencies methodically: Link without the standard modules and add missing code. Yes, this might take a while and is not easy but might have been done by one person methodically, not costing man-years of bandwidth, service, maintaining, bulding, adapting, developer time, ... With the suggested steps we move to that target, so i am happy about them. Comparing the costs spent up to now by all and that will be spent until the goal is reached, i again have to suggest (as years ago) to do it once, by one person and for the next public release. The resulting binfilter module will be an UNO-API only module, independent of 'living' C++ code and can then rest on that version. I also prefer making binfilters completely independent from any other OOo code. Constrain is to keep it as small as possible. It might be difficult to duplicate ( or better get rid of) VCL. In theory, only font and output device code should be in use if you can really throw away everything not needed for a filter. For a converter even that should not be needed, because there shouldn't be any layout calculation. But to get all of that done, you need more than one person, or a lot more time than you estimate. And my suggestion would be to start with throwing away all unused code in binfilters, to avoid unnecessary dependencies. This is IMHO not the job for one person alone, but for one person of each application who knows what can be removed. Probably also someone for DrawingEngine code - hey, that IMHO would be you ;) Malte. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Rüdiger, Rüdiger Timm wrote: Armin Le Grand wrote: [...] I haven't read that restriction anywhere. Kays proposal was about any incompatible change below binfilter. It's not a restriction, it's logic. Why else should code be moved to binfilter ATM? Kay is right because incompatible changes below binfilter are a good indication for such cases. See above: i understand Kays recipe as not to do so. And that I consider wrong. That's why I wrote about duplicating code, not just moving it. Duplicating ATM is always a necessity when the original code changes so much that it cannot be used/shared with binfilter anymore. When we would have made it independent, all the necessary code would have been duplicated (most already is), but potential changes would just not need to take notice about binfilter and may be changed in the living modules as required... I do not think that we would save so much. We still would need binfilter on our master workspace just to get part in all changes to linker switches, baseline, and so on. So, everyone doing full builds would still have to check out and build binfilter, it just would be bigger. Of course, costs for adapting and maintaining would vanish. But would that outweigh the initial transformation work? It would. With original plans, binfilter would be a module in the 8.0 release and be link-incompatible from the other modules. It is used as a UNO component anyways, so it would be usable with offices up to today, how incompatible and changed they may ever be (thatÄs the UNO API definition). Think about it: All the compiler changes, environment stuff, includes, incompatible builds, adding to CWSes, would not have happened. This is what i call man-Years and ressources... Rüdiger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Malte and Kay, i will also answer Kay's reply here, he was just asking for the amount of work, too... Malte Timmermann wrote: I also prefer making binfilters completely independent from any other OOo code. Constrain is to keep it as small as possible. It might be difficult to duplicate ( or better get rid of) VCL. Right, it will not be easy. In theory, only font and output device code should be in use if you can really throw away everything not needed for a filter. For a converter even that should not be needed, because there shouldn't be any layout calculation. But to get all of that done, you need more than one person, or a lot more time than you estimate. I do not think so. All estimations can only be guesses, but i would just do a methodical approach: (a) do not link against other C++ modules (b) look at the unresolved externals (c) take one block (c1) check if it's needed at all or the usages may be stripped (c2) reduce to the needed, add to binfilter (d) repeat This will allow the task to be done from someone extern who does not know too much about the modules. We had some ressources for something like that at that time. Maybe there are even 'tricks' someone can use who has deep experience with linking processes. At a minimum approach, it would also be okay to do something like linking binfilter statically against the modules of the release version we keep it at. This may produce something like a binfilterstatic680mi.dll containing all the static linkages without copying any code to binfilter. Maybe we should investigate in that direction, we need someone with experience in that field. Even with the first methodical approach i think a good engineer - with build boxes like Pavel has one - may handle that task in 3-6 months. And my suggestion would be to start with throwing away all unused code in binfilters, to avoid unnecessary dependencies. That's where amout of work was already put and would be goot to put more, but since this is th task You need experienced engineers for, it was seen as expensive, and i agree. This is IMHO not the job for one person alone, but for one person of each application who knows what can be removed. Probably also someone for DrawingEngine code - hey, that IMHO would be you ;) Yes, if we decide to do it that way. I was already commited to do something like that years ago to prevent those man-years of work for others and i am still. We just need to evaluate if there is not a methodical approach which can be handled by someone not deeply involved. If You ask me, this is possible. We just would need ressources to throw on it, and from my point of view they could do it methodically (we need to define that, though) without deep module knowledge. Ongoing changes in the DrawingLayer OTOH REQIRE that knowledge and can not be done methodically from someone else. We just need to weight the costs, real and implied ones... Malte. - 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]
[dev] File | Open default file type
The following enhancement requests are all related: http://qa.openoffice.org/issues/show_bug.cgi?id=10048 http://qa.openoffice.org/issues/show_bug.cgi?id=19918 http://qa.openoffice.org/issues/show_bug.cgi?id=67163 http://qa.openoffice.org/issues/show_bug.cgi?id=70421 (and for a counterview, see http://qa.openoffice.org/issues/show_bug.cgi?id=5348 http://qa.openoffice.org/issues/show_bug.cgi?id=7329) The gist of the enhancement request is: File | Open always defaults to file type *.*. It would be nice if it defaulted to file type of the current application, so for example, when in Writer, File | Open would default to the file type 'Text Documents'. What is the status of this enhancement? It looks like it may have been implemented in v2.0.4rc3 and then removed. Is there any plan to implement this? Thank you, Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Development at a Glance - Weekly Update CW06
Hi, here is the weekly update for calendar week (CW) 06: CW06 http://blogs.sun.com/GullFOSS/entry/development_at_a_glance_weekly11 Regards, Dieter -- Sun Microsystems GmbH Dieter Loeschky Nagelsweg 55Senior Manager Software Engineering 20097 Hamburg StarOffice / OpenOffice.org Development Germany Phone: +49(0)40 236 46 500 http://www.sun.com [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] OOo Security Enhancements?
Based on the article In-depth analysis of the viral threats with OpenOffice.org documents, published in Journal in Computer Virology, I had some discussions on how OOo security can be further improved. I have put some information here: http://wiki.services.openoffice.org/wiki/Security_Enhancements As I state there, I support the idea of not implicitly trusting macros located in the OOo installation, but I don't think that the basic integrity checks for documents are worth implementing. What are your opinions on this? Best regards, Malte. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] File | Open default file type
An alternate suggestion (if it is easier) is have File | Open default to All documents rather than All Files (*.*). The reason is that novice users are clicking on document types such as .pdf's and getting a confusing error message. OOo should not by default list unsupported document types in the File | Open dialog. This suggestion was entered as http://qa.openoffice.org/issues/show_bug.cgi?id=74295 Allen -Original Message- From: Allen Pulsifer [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 07, 2007 9:20 AM To: dev@openoffice.org Subject: [dev] File | Open default file type The following enhancement requests are all related: http://qa.openoffice.org/issues/show_bug.cgi?id=10048 http://qa.openoffice.org/issues/show_bug.cgi?id=19918 http://qa.openoffice.org/issues/show_bug.cgi?id=67163 http://qa.openoffice.org/issues/show_bug.cgi?id=70421 (and for a counterview, see http://qa.openoffice.org/issues/show_bug.cgi?id=5348 http://qa.openoffice.org/issues/show_bug.cgi?id=7329) The gist of the enhancement request is: File | Open always defaults to file type *.*. It would be nice if it defaulted to file type of the current application, so for example, when in Writer, File | Open would default to the file type 'Text Documents'. What is the status of this enhancement? It looks like it may have been implemented in v2.0.4rc3 and then removed. Is there any plan to implement this? Thank you, Allen - 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]
