[dev] OpenOffice.org status and v3.4 final release
Greetings, Normally the OpenOffice.org holds a Release Status Meeting every Monday and reports the minutes at http://wiki.services.openoffice.org/wiki/ReleaseStatus_Minutes . I notice that no meeting has been held the last two Mondays. Is anyone working on a final release of OpenOffice.org v3.4? For example, the web page at http://wiki.services.openoffice.org/wiki/OOoRelease34 lists the following persons that are responsible for some aspect of the release: antbryan, hde, ja, jsc, md, mike, mla, and rosana. Which of those persons, if any, are still involved in the release and or involved in the OpenOffice.org project? Second, according to http://council.openoffice.org/ , the following persons are members or deputy members of the OpenOffice.org Community Council: Louis Suárez-Potts, Matthias Huetsch, Kazunari Hirano, Stefan Taxhet, Martin Hollmichel, Andreas Bartel, Juergen Schmidt, Carsten Driesner, Eike Rathke. Which if any of these persons remain involved with the OpenOffice.org project? When is the next meeting of the OpenOffice.org Community Council? Would any member of the OpenOffice.org Community Council care to comment or inform us of the current status of the project? Thank you, Allen Pulsifer -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
RE: [dev] Butler Office Pro - really a violation ?
On Fri, 2008-02-08 at 17:51 +0100, Juergen Schmidt wrote: The project simply don't need people like you who has probably never contributed one line of code but are very good in this kind of useless discussion. I must of missed this email (I did notice Michael's reply), but really, I don't care if you like me or not, and I don't care whether you personally consider this discussion to be useless or not. First of all, many people make many contributions other than code. This includes bug reports, documentation, marketing and community support. I won't bother to list all the possible avenues for contribution because if you are so myopic as to make a statement like that I will not waste my time. In addition, as I very clearly stated, any contribution I could make has been refused by the project. As soon as the licensing issues are worked out, and the project is willing to accept code licensed only under the LGPL, then I would be willing to make contributions. I will not be signing the JCA, or SCA or whatever the name du-jour happens to be. I'm sure I'm not the only developer who feels this way. Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Butler Office Pro - really a violation ?
I see that Allen wants to continue in developing the project and product, so please everyone lets Allen do it... That would be great. As soon as the project is ready to accept LGPL contributions, then we can make that happen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Butler Office Pro - really a violation ?
All people who don't like it as it is are free to leave the project and should spare us with this kind of discussion as long as the situation doesn't change. This attitude is very telling. Some people might think that the whole reason Sun set up OpenOffice.org is to get free development and code contributions to its StarOffice product. By posting things like this, you make it very clear that it is your goal and Sun's goal that all people who will not assign copyright in their work to Sun should leave the project, because you and Sun have no use for them. If this was not obvious before, it certainly is now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Butler Office Pro - really a violation ?
What I would like to consider common sense tells me that of course you continue to be the owner of the code you contributed, Caolan continues to be the owner of the code he contributed... Apparently you have not read the terms of the copyright assignment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Butler Office Pro - really a violation ?
2. yes, FSF doesn't accept e.g. non-paper-worked contributions to free software it maintains, e.g. Emacs. The obvious point, if we must belabor it, is that an organization like FSF would never take an open source program to which it held an assigned copyright and re-license it under a commercial license. The FSF's intentions and practices are very different from Sun's. Sun is explicitly asking for copyright assignment so that it can re-license the contributions under a commercial license to anyone it chooses. Many potential contributors would consider assigning copyright to a foundation such as FSF to be very different than assigning copyright to a corporation such as Sun for their commercial use. For that reason, comparisons between Sun's practices and the FSF's practices, or comparison to the practices of any similar non-profit or foundation such as the Apache Project, etc., are not very relevant and are in fact misleading, IMPO. Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Butler Office Pro - really a violation ?
i am speaking as a community member and not as Sun employee ;-) Three month ago or so we had more or less the same discussion. I thought the current situation was clarified and no further discussion is necessary until Sun brings it up or if Sun would misuse the copyright. Thank you for that clarification, Juergen.Schmidt of Sun.com If I or anyone else wants to discuss this topic, we will, regardless of your opinion Not-As-A-Sun-Employee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Butler Office Pro - really a violation ?
The intent is not to mislead, but present the reality. I would argue that talk of Joint, and Shared in copyright assignments (by contrast) is to market the unpleasant fact with meaningless friendly sounding terms :-) ie. the plain truth is perhaps not quite as obvious as you suggest. I would agree with that statement. Joint Copyright is just for show. In practice, a contributor would have the right to use the code under the LGPL anyway, and if the code is derived from OOo, would have no rights to distribute the code except on the LGPL. The only right added by the Joint Copyright is the right to sue for copyright violation, which is again, not a right that will probably ever be put into practice. In summary, the Joint Copyright does not add any useful rights that the contributor would not otherwise have, and is therefore just for show. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Butler Office Pro - really a violation ?
the means you are using to change the situation (flooding dev@ list with offtopic) are wrong. There is nothing off-topic about this discussion. It is highly relevant to every developer who is not also an employee of Sun Microsystems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Butler Office Pro - really a violation ?
When a developer contributes code to the C# compiler or the Mono runtime engine, we require that the author grants Novell the right to relicense his/her contribution under other licensing terms. This allows Novell to re-distribute the Mono source code to parties that might not want to use the GPL or LGPL versions of the code. Thank you for the example. I have to respect the fact the Novell is being very honest and open about it. Conversely, when discussing the JCA, Sun studiously avoids mentioning the fact that the JCA allows Sun to relicense contributions under any license it choose, including a commercial license. Here for example is this same pattern of avoidance right here in your post: In OpenOffice.org the JCA is required only for code contributed to the core product so that in case a relicencing might become necessary or desirable (e.g. a licence change from LGPLv2 to (L)GPLv3) this can be done easily. I think these discussion are very valuable, so that contributors, potential contributors and users can all understand the license terms and its implications. Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Some thoughts about our community
Hello Juergen, I deleted your message without reading it because I'm not willing to look at anything that starts with that tone. Best Regards, Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Some thoughts about our community
Hello Mathias, There is a lot of PR in this issue floating around the internet these days, most of it coming from Sun. Its clear to me that the goal of this PR is to maintain the status quo, i.e., ensure that contributions to the project keep coming in, and that the contributors sign the JCA or its successor the SCA that assign copyrights to Sun. I think both Sun and the project are poorly served by both the JCA/SCA and the current PR campaign. For starters, I think the JCA/SCA discourages contributions. I myself would not sign the JCA/SCA assigning copyright for anything but the most trivial code, and as we have seen, neither will Kohei and I'm sure neither will many other developers. Sun can try to spin it a different way or try to sell us on the JCA/SCA, but for many developers, you are not going to succeed. I have carefully read all of the rationale for the JCA/SCA, including the most recent blog post from Simon Phipps at http://blogs.sun.com/webmink/entry/sca_r_office. In my opinion, none of these rational hold water. The same things could be accomplished by asking contributors to assign joint copyright to a non-profit foundation rather than to Sun. The one rational Simon offers that is a little bit different than the usual is the following: In many cases (including some very well-known open source projects) [the JCA] also allows the original donor to offer commercial offerings, thus ensuring the project continues to have engagement funded by its major participants. I myself to not begrudge Sun its efforts to maintain a commercial version of OOo. Again however, the same thing could be accomplished with code that is under the LGPL. In other words, a Foundation chartered to maintain the copyrights in OOo could insist that all contributions included in the official OOo build be licensed under the LGPL, and this would be sufficient to allow Sun to continue producing and distributing StarOffice. The alternatives I see here are just what I mentioned in my prior post. If Sun continues to insist that all copyrights be assigned to it, then alternative methods of contributing will be created. These alternative methods might include alternate distributions or forks that accept pure LGPL code, or possibly even GPL code or code under other licenses. This I think is inevitable. In my opinion, the best course of action for Sun is to set up a Foundation to hold joint copyrights from contributors. That at least gives Sun a chance to negotiate for all contributions to be licensed under the LGPL. If Sun does not do that, you might find some future contributions are offered only under the GPL, and Sun would not be able to use these in StarOffice. The much better arrangement for Sun, I think, is to try to keep all contributions under the LGPL. I offer this suggestion as something to think about. In the meantime, I would like to make one comment. Kohei is the author of the solver code and owns the copyright. He has the absolute legal and moral right to determine the terms of his contribution. He has extremely generously offered this code to the world under the LGPL. The LGPL is a fine open source license. It allows virtually unrestricted use of the code, for free, while guaranteeing that any derivatives also remain free. It embodies some of the best aspects of the open source movement. I find it very admirable and commendable that Kohei has so generously offered to make his code available under the LGPL, and I find nothing to criticize in this decision. Recently however I have read some rather disturbing comments on the internet that Kohei is somehow a bad person for offering his code under the LGPL, and furthermore, the only way for him to become a good person is to sign a legal document that assigns copyright to Sun Microsystems. This I believe is unprecedented in the open source movement. Is that what we have come to, that a person who offers code under the LGPL is subject to criticism? That if he refuses to sign over his copyright to a proprietary product then he is somehow a bad person. I am quite frankly, amazed, stupefied, flabbergasted--at a total loss for words--by the recent comments I have read. In the part of the world where I come from, it is very common for code to be offered under dual licenses. An open source license such as the GPL is offered for free, and a standard commercial license is offered for a fee to companies who want to use the code in a closed-source commercial product. Companies that want to use the code under the commercial license simply pay the fee, and then they have that right. Specifically with respect to Kohei's solver code, Sun has stated that it will have to be completely rewritten by someone else, with copyright held by Sun, in order to be included in OpenOffice.org. Taking that statement at face value, it appears then that Sun is willing to spend $50,000 plus in engineering time just to have a solver that it holds the copyright for, as
RE: [dev] Some thoughts about our community
Hello Mathias, There is a lot of PR in this issue floating around the internet these days, most of it coming from Sun. Its clear to me that the goal of this PR is to maintain the status quo, i.e., ensure that contributions to the project keep coming in, and that the contributors sign the JCA or its successor the SCA that assign copyrights to Sun. I think both Sun and the project are poorly served by both the JCA/SCA and the current PR campaign. For starters, I think the JCA/SCA discourages contributions. I myself would not sign the JCA/SCA assigning copyright for anything but the most trivial code, and as we have seen, neither will Kohei and I'm sure neither will many other developers. Sun can try to spin it a different way or try to sell us on the JCA/SCA, but for many developers, you are not going to succeed. I have carefully read all of the rationale for the JCA/SCA, including the most recent blog post from Simon Phipps at http://blogs.sun.com/webmink/entry/sca_r_office. In my opinion, none of these rational hold water. The same things could be accomplished by asking contributors to assign joint copyright to a non-profit foundation rather than to Sun. The one rational Simon offers that is a little bit different than the usual is the following: In many cases (including some very well-known open source projects) [the JCA] also allows the original donor to offer commercial offerings, thus ensuring the project continues to have engagement funded by its major participants. I myself to not begrudge Sun its efforts to maintain a commercial version of OOo. Again however, the same thing could be accomplished with code that is under the LGPL. In other words, a Foundation chartered to maintain the copyrights in OOo could insist that all contributions included in the official OOo build be licensed under the LGPL, and this would be sufficient to allow Sun to continue producing and distributing StarOffice. The alternatives I see here are just what I mentioned in my prior post. If Sun continues to insist that all copyrights be assigned to it, then alternative methods of contributing will be created. These alternative methods might include alternate distributions or forks that accept pure LGPL code, or possibly even GPL code or code under other licenses. This I think is inevitable. In my opinion, the best course of action for Sun is to set up a Foundation to hold joint copyrights from contributors. That at least gives Sun a chance to negotiate for all contributions to be licensed under the LGPL. If Sun does not do that, you might find some future contributions are offered only under the GPL, and Sun would not be able to use these in StarOffice. The much better arrangement for Sun, I think, is to try to keep all contributions under the LGPL. I offer this suggestion as something to think about. In the meantime, I would like to make one comment. Kohei is the author of the solver code and owns the copyright. He has the absolute legal and moral right to determine the terms of his contribution. He has extremely generously offered this code to the world under the LGPL. The LGPL is a fine open source license. It allows virtually unrestricted use of the code, for free, while guaranteeing that any derivatives also remain free. It embodies some of the best aspects of the open source movement. I find it very admirable and commendable that Kohei has so generously offered to make his code available under the LGPL, and I find nothing to criticize in this decision. Recently however I have read some rather disturbing comments on the internet that Kohei is somehow a bad person for offering his code under the LGPL, and furthermore, the only way for him to become a good person is to sign a legal document that assigns copyright to Sun Microsystems. This I believe is unprecedented in the open source movement. Is that what we have come to, that a person who offers code under the LGPL is subject to criticism? That if he refuses to sign over his copyright to a proprietary product then he is somehow a bad person. I am quite frankly, amazed, stupefied, flabbergasted--at a total loss for words--by the recent comments I have read. In the part of the world where I come from, it is very common for code to be offered under dual licenses. An open source license such as the GPL is offered for free, and a standard commercial license is offered for a fee to companies who want to use the code in a closed-source commercial product. Companies that want to use the code under the commercial license simply pay the fee, and then they have that right. Specifically with respect to Kohei's solver code, Sun has stated that it will have to be completely rewritten by someone else, with copyright held by Sun, in order to be included in OpenOffice.org. Taking that statement at face value, it appears then that Sun is willing to spend $50,000 plus in engineering time just to have a solver that it holds the copyright for, as
RE: [dev] Some thoughts about our community
Speaking as a community participant... When I first became involved in OOo, I was not completely comfortable with the license arrangement, but thought Sun should be given the benefit of the doubt based on all of their contributions. However, let's look at this objectively. Here are some facts. 1. Sun makes many contributions to the code. 2. Sun manages the build process and dominates the decisions on what gets included in the official OOo distribution. 3. One of Sun's conditions for any code to be included in the official OOo distribution is that the copyright for the code must be assigned to Sun. 4. Sun takes those contributions and releases them in their proprietary product StarOffice. 5. There is dissatisfaction in the community over items 2 and 3. This dissatisfaction results in some companies and individuals not being willing to contribute code or participate in the community. 6. This dissatisfaction has already resulted in several forks. Some forks have completely diverged, like NeoOffice and Lotus Symphony, while some for now are just patch sets or enhancements to the official build, like OxygenOffice and Novell's distribution. Now for some predictions: - If things in the community stay the same, I think a fork (or continued growth of the existing forks) is inevitable. This fork might just be patch sets in the official build, or it might be a split that looks more like the various BSD's that port each other's code all the time. This fork (or forks) will include code that has not been assigned to Sun under the JCA. - Its possible that Sun could stop distributing its code changes as open source, although I think that is very unlikely. It is perhaps more likely that Sun may re-license all or a portion of its code under the GPL, preventing it from being used in other commercial projects. - The forked project may decide to release its changes under the GPL (to the extent possible), making it impossible for Sun to include them in its proprietary product, StarOffice. - In my opinion, a fork will be a good thing for the project and code base by increasing developer interest and enthusiasm. The competition will also be good for both projects. - One of the big question is: where will the bulk of the community go to. Will they stay with the Sun-dominated process? Will they move to the fork? If they move to the fork, will they be able to bring the OpenOffice.org name with them, or does Sun effectively control that name as well? If not, what will the new name be? (OpenOffice.net?) The bottom line is that Sun released StarOffice under the LGPL for its own reasons, the community contributes to this project for its own reasons. It is what it is, as they say. The big question is what this portends for the future. Those are my thoughts. Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] WARNING: Do Not Install IBM Lotus Symphony (Beta)
To all the OpenOffice users who might be interesting in trying out IBM Lotus Symphony (Beta): DO NOT INSTALL IBM Lotus Symphony (Beta) !!! I tried it out. It took over all of my OpenDoc file associations, without warning, and installed itself into a handful of other file associations. IT HAS NO UNINSTALLER, SO THESE CHANGES CANNOT BE EASILY REVERSED! Basically, it made a mess out of my registry. Its taking me about an hour to fix it. WARNING: INSTALL IBM Lotus Symphony (Beta) AT YOUR OWN PERIL! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] WARNING: Do Not Install IBM Lotus Symphony (Beta)
Well I tried it out on Windows too and I could install and de-install it, using the Software option in the System folder. However, some associations (I think ODT or ODS) did not get restored correctly. Hello Rony, Kindly forgive my confusion. What is the software option in the system folder? I looked in Control Panel | Add/Remove Programs and could not find an entry for Symphony. Then I tried rerunning the installer and it only offered to install, as if it had never been installed. It had no option for repair or remove. Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] WARNING: Do Not Install IBM Lotus Symphony (Beta)
Even OOo won't restore the file associations to the older program... the easier way to fix it is to repair the OOo setup or reinstall. Yes, I tried that. OOo very politely respected the Symphony file associations and did no repair. The only way I got it to work was to delete all traces of Symphony from the file associations. If the file association was Symphony-only or Symphony and OpenOffice, then I simply deleted it and fixed it later with a reinstall of OOo. For all other associations, I only deleted the Symphony entry. Hint for anyone suffering from the same problem: I eventually figured they could be easily located by searching for the partial string standalone_ (without quotes). Better solution: don't install Symphony until IBM gets its act together. Its particularly unforgivable IMO for beta software not to uninstall without a trace because that's what its for: to install, try out, and then delete. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] 470 versions in issuezilla, can we drop a couple of hundred ?
Can we cull these to at least remove all the milestones current - 5, and consider dropping the release candidates and the 1.0.X releases. What would we do then with the issues which currently have one of those versions set? We cannot simply remove the versions, this would violate the data integrity. We would have to reset this field for the affected issues. How about just changing the UI on the website? We could make it so that normally only the active versions would be displayed in the scrolling list, but somewhere there would be a checkbox or other option to make it display all versions. In the search screen, we could also add some meta-versions to the list, i.e., Any version, Any v1.x, Any v2.x, etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] Mails from moderated users
Hi all, Yes, this 'pain-in-the-ass' problem. I would prefer that all emails from unsubscribed addresses simply be rejected with an auto-reply sent to the user telling them they need to subscribe and then resend. Alternately, these emails could be treated as a subscription request and automatically held until the user subscribes. The auto-reply could inform the user that they must be subscribed, give them the option of subscribing by replying to the auto-reply (or clicking a link), and then automatically forward their original email to the list as soon as they subscribe. If they did not subscribe in 72 hours, their email would be deleted. Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] File | Open default file type
Thanks for your effort, Allen. However I'm afraid that your proposal to default to an application specific filter will not be accepted. The issue list you have presented in your initial mail already contained some issues that have been closed for that reason. We see OpenOffice.org as an integrated package and don't see why the fact that somebody is writing a text makes it more probable that the next file to be opened will be a text file also. Hello Mathias, Thank you. Believe me, I don't take it personally. That is just one of several proposals in the draft spec and I'm glad to see it get discussion and consideration. To me, that part of the proposal is all about work flow and new user expectation, not about marketing. I put that in there because it matches the way I work, and also because this had been requested by others. When I use the File | Open dialog in an application, I am generally going to open the same type of document, and having this preselected makes it easy for me. I think most new users expect the same thing, and get confused to see so many files list. I can certainly see how other people might view it differently, and I would be happy to have the UX team look at it. Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] File | Open default file type
Yes, that sounds good. I would change it a little bit and offer showing the filter dialog (that also needs a redesign BTW). Only offering to open as text is not enough. Especially text files are detected quite reliably. But as in most cases where OOo fails to detect the file it *is* an unknown type showing the filter dialog immediately isn't a good idea. So a message box asking how to proceed as you suggested will help. Hello Mathias, I did a preliminary spec at http://wiki.services.openoffice.org/wiki/File_Chooser_Type_Handling_Specific ation I think you may have more insights than me though. Could you comment further how the filter dialog should work, vis a vis the draft spec? Thank you, Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] File | Open draft specification
Hello Ciao, Thank you for your comments. With regard to this specific point: - The default file type depends on the current application. For example, from Writer, File | Open by default displays only Text documents. The other types, including All Files (*.*) can still be chosen from the File Type drop down list. Ref: http://qa.openoffice.org/issues/show_bug.cgi?id=67163 There are strong arguments against it. It would be hard for the user to open a text document while working with a spreadsheet, for instance. Actually, it would be very easy to open a text document when working with a spreadsheet. Select File | Open. The File Chooser dialog will appear. For File Type, select either Text documents or All Files (*.*). Locate the text document you want to open and click Open. That's it. This is just one more step than the current workflow (you have to explicitly select the File Type), but it corresponds better with the expectations of new users. I don't think it is worth the complexity to make this configurable, but if others believe it is, then I would not oppose it. Thanks, Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] File | Open default file type
OTOH if we didn't use this all documents filter by default the question remains if it makes sense at all. Yes, I agree with you. If All documents is not the default then there might not be much benefit. A better approach might be to give the user an error or warning message when attempting to open a file of unknown type. For example, when you try to open a pdf, OOo displays a text filter configuration dialog box. A better approach might be to first tell the user: OOo does not recognize the format of this document. Would you like to try opening it as a text document? Allen - 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 (*.*). This suggestion was entered as http://qa.openoffice.org/issues/show_bug.cgi?id=74295 Wouldn't it be consequent to rename the 'file open dialog' to 'document open dialog'? And changing the entry in the menu bar from 'File' to 'Document'? Hello Olaf, I don't know who first came up with the File menu. Its been around since at least 1984, with the introduction of the Apple Macintosh. Since then, most applications have had File as their left-most menu. It hasn't always made sense to me either. I believe the menu File may have originally represented the act of filing, as in to file a memo in a filing cabinet, rather than the common use of the term among computer people, a file as named stream of data, usually stored on disk in a hierarchical directory. See http://m-w.com/dictionary/file click file[4,verb] http://en.wikipedia.org/wiki/Computer_file#History Allen - 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]
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]
[dev] configuration for share/scripts and user/script?
Question: How does OOo locate its scripts directories, i.e., $(insturl)/share/scripts and $(userurl)/scripts? The basic directories, $(insturl)/share/basic and $(userurl)/basic are configured in share\registry\data\org\openoffice\Office\Paths.xcu, but I can find no configuration settings in the registry or elsewhere for the scripts directories. I did however notice a few hardcoded scripts strings in the OOo source code: C:\OOE680_m6\scp2\source\ooo\directory_ooo.scp(232,15):DosName = Scripts; C:\OOE680_m6\scp2\source\ooo\directory_ooo.scp(978,15):DosName = Scripts; C:\OOE680_m6\scripting\java\com\sun\star\script\framework\container\ParcelC ontainer.java(341,57):return PathUtils.make_url( containerUrl , Scripts/ + language.toLowerCase() ); C:\OOE680_m6\scripting\java\com\sun\star\script\framework\container\UnoPkgC ontainer.java(261,60):String packagesUrl = PathUtils.make_url( path, Scripts/unopkg-desc.xml ); C:\OOE680_m6\scripting\java\com\sun\star\script\framework\container\UnoPkgC ontainer.java(320,60):String packagesUrl = PathUtils.make_url( path, Scripts/unopkg-desc.xml ); C:\OOE680_m6\scripting\java\com\sun\star\script\framework\io\XStorageHelper .java(93,51):int indexOfScriptsDir = path.lastIndexOf( Scripts ); C:\OOE680_m6\scripting\java\com\sun\star\script\framework\io\XStorageHelper .java(135,48):if ( !mediaType.equals(scripts) ) C:\OOE680_m6\scripting\java\com\sun\star\script\framework\io\XStorageHelper .java(137,65): xProps.setPropertyValue(MediaType,scripts); C:\OOE680_m6\scripting\java\org\openoffice\idesupport\xml\Manifest.java(95 ,17):add(Scripts/, application/script-parcel); C:\OOE680_m6\scripting\java\org\openoffice\idesupport\zip\ParcelZipper.java (52,52):public static final String PARCEL_PREFIX_DIR = Scripts/; C:\OOE680_m6\scripting\java\org\openoffice\netbeans\modules\office\actions\ DeployParcelAction.java(99,38):File.separator + Scripts)); C:\OOE680_m6\scripting\java\org\openoffice\netbeans\modules\office\filesyst em\OpenOfficeDocFileSystem.java(66,49):public static final String SCRIPTS_ROOT = Scripts; // must be a folder C:\OOE680_m6\scripting\source\provider\URIHelper.cxx(134,48): SCRIPTS_PART = OUString::createFromAscii( /Scripts/ ); C:\OOE680_m6\scripting\source\pyprov\pythonscript.py(35,71): systemPath = uno.fileUrlToSystemPath( userInstallation + /Scripts/python/log.txt ) C:\OOE680_m6\scripting\source\storage\ScriptStorage.cxx(76,38):const sal_Char * const SCRIPT_DIR = /Scripts; C:\OOE680_m6\scripting\source\storage\ScriptStorage.cxx.tmp(76,38):const sal_Char * const SCRIPT_DIR = /Scripts/; C:\OOE680_m6\scripting\workben\installer\XmlUpdater.java(333,44): share + File.separator + Scripts + File.separator; C:\OOE680_m6\sfx2\source\doc\objmisc.cxx(2309,65): || ( xStorage-hasByName( ::rtl::OUString::createFromAscii(Scripts) ) C:\OOE680_m6\sfx2\source\doc\objmisc.cxx(2310,70): xStorage-isStorageElement( ::rtl::OUString::createFromAscii(Scripts) ) ); C:\OOE680_m6\svx\inc\globlmn_tmpl.hrc(992,15):Text[ de ] = Scripts/Macros ; \ C:\OOE680_m6\svx\inc\globlmn_tmpl.hrc(993,19):Text [ en-US ] = Scripts/Macros ; \ C:\OOE680_m6\xmloff\source\core\xmltoken.cxx(2406,16):TOKEN( scripts, XML_SCRIPTS ), C:\OOE680_m6\xmlsecurity\source\helper\documentsignaturehelper.cxx(164,63) :aSubStorageName = rtl::OUString::createFromAscii( Scripts) ; Thank you, Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] proposal for problematic UNC file url's
Entered as http://qa.openoffice.org/issues/show_bug.cgi?id=73625 -Background- In Windows, a UNC path to a directory looks like this (see http://support.microsoft.com/kb/311079): \\server\share\path According to the file URI spec, Windows UNC paths should be accepted as file urls if they are entered like this: file:///server/share/path See http://udk.openoffice.org/cpp/man/spec/uris.html, last section, Hosts; Note however there is a typo in the spec--it says file://somewhere/somedir/file.txt but should say file:///somewhere/somedir/file.txt, with 3 slashes after the file:. UNC's paths however have long been problematic in OOo. See: http://www.oooforum.org/forum/viewtopic.phtml?p=196522 http://qa.openoffice.org/issues/show_bug.cgi?id=9018 http://qa.openoffice.org/issues/show_bug.cgi?id=13148 http://qa.openoffice.org/issues/show_bug.cgi?id=51026 http://qa.openoffice.org/issues/show_bug.cgi?id=53184 http://qa.openoffice.org/issues/show_bug.cgi?id=56868 http://qa.openoffice.org/issues/show_bug.cgi?id=72031 http://qa.openoffice.org/issues/show_bug.cgi?id=72864 http://qa.openoffice.org/issues/show_bug.cgi?id=73620 Part of the problem would seem to be that in OOo's implementation of file URL's, it cannot be unambiguously determined if the first component of the URL refers to a server or to a directory. For example, in file:///part1/part2/part3 part1 could refer to the directory /part1 on the local files system, or it could refer to the server part1 on the local network. -The Proposal- The submitter proposes that OOo's implementation of UNC file URL's be modified so it can be unambiguously determined if the first part of the path is a local directory or a network server. There are a multitude of syntaxes that could be used. For example: file:///server:share/path file:///server:/share/path file:///server//share/path file:///server/share:path file:///server:share:path file:///server:share:/path file:///server/share:/path What should not be used however, is the current ambiguous implementation file:///server/share/path The author of this proposal has no preference for syntax. Note however that Microsoft's document http://support.microsoft.com/kb/311079 discusses how Netware shares are parsed, and this may enter into the decision. Linux, Solaris and Samba considerations may also enter into the decision. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] proposal for problematic UNC file url's
Hello Stephan, Thank you for your reply. To answer your question, I thought it was a typo for several reasons: 1. In researching http://qa.openoffice.org/issues/show_bug.cgi?id=73620, I tried four possible syntaxes, file:/, file://, file:///, file: and none of them worked. 2. I found other instances on the OOo website and documentation that list the syntax as file:///. 3. Shoddy and incorrect documentation abound in the OOo project, so this was a reasonable conclusion. In summary, this was not an assumption, it was a conclusion reached based on experience, research and a diligent effort to solve the problem before putting in a bug report. If you are saying that a UNC path is distinguished by having only two slashes after the file:, rather than three slashes, then you are right, it is not ambiguous. I am still glad I raised the issue however, since (a) this needs to be better documented; and (b) based on how well UNC paths do not work in OOo, there seems to be just as much confusion among the developers as the users. Thank you again for your response. Allen -Original Message- From: Stephan Bergmann [mailto:[EMAIL PROTECTED] Sent: Thursday, January 18, 2007 10:27 AM To: dev@openoffice.org Subject: Re: [dev] proposal for problematic UNC file url's Allen Pulsifer wrote: Entered as http://qa.openoffice.org/issues/show_bug.cgi?id=73625 Please see my response there. -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: [dev] Re: documentation for filter flags?
NOTINCHOOSER excludes it from the filter dialog, the awful dialog you get when OOo can't find a filter. Hello Markus, Thank you for the hint on how to force the filter chooser dialog to appear. I was able to confirm that the NOTINCHOOSER flag does not work, and entered a bug report: http://www.openoffice.org/issues/show_bug.cgi?id=70733 Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] paths configuration in v2.0.4
I also submitted two bug reports. http://qa.openoffice.org/issues/show_bug.cgi?id=70688 http://qa.openoffice.org/issues/show_bug.cgi?id=70687 Thanks Allen, the developer responsible for this is currently on vacation but he surely will have a look when he is back end of next week. Thanks. I added one more: http://www.openoffice.org/issues/show_bug.cgi?id=70735 Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] documentation for filter flags?
NOTINCHOOSER excludes it from the filter dialog, the awful dialog you get when OOo can't find a filter. Hello Mathias, Thank you, that is helpful. Is there sample file somewhere that causes OOo to bring up the filter dialog? I wanted to test NOTINCHOOSER but I'm unable to get this dialog to appear. Thanks, Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] paths configuration in v2.0.4
But you've hit the nail on the top. We have prepared for two ways of working with pathes: UserPaths can be overwritten like described here, InternalPaths are mergeable. So an admin that wants to write his own path as described by Allen and doesn't want to allow for changes made by users just can set the value into the UserPaths and empty the InternalPaths (or keeps the share/template stuff). Then he can finalize both settings and he will be done. Hello Mathias. Thank you for your reply. The part that I think is more difficult than it should be is changing the value of an InternalPath. I would like to follow up with a specific proposal that will not reduce the functionality and will not make it any more difficult for package distributors, but will make it easier for system administrators. I hope to be able to post it later this week. Thank you, Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] paths configuration in v2.0.4
Hello Joerg, Thank you for your response. Just to respond further: The Current/Default distinction in that place was misguided. That should really be achieved via layering. I agree with this. There are other places in OOo where dynamically created keys have such significance. This is the only way to get mergeable lists of strings. That statement I can't agree with. The configuration registry is basically a database. It is not uncommon in database design to use arbitrary key names. But the name is never used as the value, because the two are semantically different. Similarly, in the OpenOffice.org registry, arbitrary key names would be used where required, with the key value used as the configuration settings. To get a mergeable list of strings, the key values would be merged, not the key names. Instead you need to know a list of unspecified key names. You don't suggest to hardcode com.acme.supertemplate into OOo, do you? I'm not suggesting this. The key names would identify the source of each path setting, but to OOo, the names would be irrelevant and it would not need to know them. OOo would enumerate all of the keys under org.openoffice.Office.Paths/pathname/InternalPaths, just like it does now, except it would concatenate the key values into a path list, instead of concatenating the key names. I tested the operation of path configuration in OOo v2.0.4 and wrote up instructions on how it can be configured by an administrator. Note these instructions are based on how the path settings have been tested to work, not how they are intended or documented to work. Comments are welcome. The instructions are located at: http://openofficetechnology.com/node/50 I also submitted two bug reports. http://qa.openoffice.org/issues/show_bug.cgi?id=70688 http://qa.openoffice.org/issues/show_bug.cgi?id=70687 Thank you, Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] documentation for filter flags?
Just to follow up on this question, what in particular does the NOTINCHOOSER flag do? In testing, and in examining the source code, it appears to do nothing. In contrast, the NOTINFILEDIALOG hides the format in all dialogs, including File | Open, File | Save As and File | Export. I'm using OOo v2.0.4 en-us under WinXP. Allen -Original Message- From: Allen Pulsifer [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 10:23 AM To: dev@openoffice.org Subject: [dev] documentation for filter flags? Are the file filter flags documented somewhere? The flags I'm referring to are defined in filter\source\config\cache\constant.hxx and are used in the configuration (.xcu) files: /** @short names of filter flags. */ #define FLAGNAME_3RDPARTYFILTER _FILTER_CONFIG_FROM_ASCII_(3RDPARTYFILTER ) #define FLAGNAME_ALIEN _FILTER_CONFIG_FROM_ASCII_(ALIEN ) #define FLAGNAME_ASYNCHRON _FILTER_CONFIG_FROM_ASCII_(ASYNCHRON ) #define FLAGNAME_BROWSERPREFERRED _FILTER_CONFIG_FROM_ASCII_(BROWSERPREFERRED ) #define FLAGNAME_CONSULTSERVICE _FILTER_CONFIG_FROM_ASCII_(CONSULTSERVICE ) #define FLAGNAME_DEFAULT _FILTER_CONFIG_FROM_ASCII_(DEFAULT ) #define FLAGNAME_EXPORT _FILTER_CONFIG_FROM_ASCII_(EXPORT ) #define FLAGNAME_IMPORT _FILTER_CONFIG_FROM_ASCII_(IMPORT ) #define FLAGNAME_INTERNAL _FILTER_CONFIG_FROM_ASCII_(INTERNAL ) #define FLAGNAME_NOTINCHOOSER _FILTER_CONFIG_FROM_ASCII_(NOTINCHOOSER ) #define FLAGNAME_NOTINFILEDIALOG _FILTER_CONFIG_FROM_ASCII_(NOTINFILEDIALOG ) #define FLAGNAME_NOTINSTALLED _FILTER_CONFIG_FROM_ASCII_(NOTINSTALLED ) #define FLAGNAME_OWN _FILTER_CONFIG_FROM_ASCII_(OWN ) #define FLAGNAME_PACKED _FILTER_CONFIG_FROM_ASCII_(PACKED ) #define FLAGNAME_PREFERRED _FILTER_CONFIG_FROM_ASCII_(PREFERRED ) #define FLAGNAME_READONLY _FILTER_CONFIG_FROM_ASCII_(READONLY ) #define FLAGNAME_SILENTEXPORT _FILTER_CONFIG_FROM_ASCII_(SILENTEXPORT ) #define FLAGNAME_SUPPORTSSELECTION _FILTER_CONFIG_FROM_ASCII_(SUPPORTSSELECTION) #define FLAGNAME_TEMPLATE _FILTER_CONFIG_FROM_ASCII_(TEMPLATE ) #define FLAGNAME_TEMPLATEPATH _FILTER_CONFIG_FROM_ASCII_(TEMPLATEPATH ) #define FLAGNAME_USESOPTIONS _FILTER_CONFIG_FROM_ASCII_(USESOPTIONS ) #define FLAGNAME_COMBINED _FILTER_CONFIG_FROM_ASCII_(COMBINED ) Similar flags appear in framework\inc\filterflags.h and in framework\source\constant\filter.cxx: /*-*** ** ***//** @short These values describe our supported filter flags. @attention Don't change flag values without reason - we must support old functionality and position in flag combined values! *//*-* ** **/ #define FILTERFLAGNAME_IMPORT DECLARE_ASCII(Import ) // x #define FILTERFLAGNAME_EXPORT DECLARE_ASCII(Export ) // x #define FILTERFLAGNAME_TEMPLATE DECLARE_ASCII(Template ) // x #define FILTERFLAGNAME_INTERNAL DECLARE_ASCII(Internal ) // x #define FILTERFLAGNAME_TEMPLATEPATH DECLARE_ASCII(TemplatePath ) // x #define FILTERFLAGNAME_OWN DECLARE_ASCII(Own ) // x #define FILTERFLAGNAME_ALIEN DECLARE_ASCII(Alien) // x #define FILTERFLAGNAME_USESOPTIONS DECLARE_ASCII(UsesOptions ) // x #define FILTERFLAGNAME_DEFAULT DECLARE_ASCII(Default ) // x #define FILTERFLAGNAME_EXECUTABLE DECLARE_ASCII(Executable ) // deprecated #define FILTERFLAGNAME_SUPPORTSSELECTION DECLARE_ASCII(SupportsSelection) // x #define FILTERFLAGNAME_MAPTOAPPPLUG DECLARE_ASCII(MapToAppPlug ) // deprecated #define FILTERFLAGNAME_NOTINFILEDIALOG DECLARE_ASCII(NotInFileDialog ) // x #define FILTERFLAGNAME_NOTINCHOOSER DECLARE_ASCII(NotInChooser ) // x #define FILTERFLAGNAME_ASYNCHRON DECLARE_ASCII(Asynchron) // x #define FILTERFLAGNAME_CREATOR DECLARE_ASCII(Creator ) // deprecated #define FILTERFLAGNAME_READONLY DECLARE_ASCII(Readonly ) // x #define FILTERFLAGNAME_NOTINSTALLED DECLARE_ASCII(NotInstalled ) // deprecated #define FILTERFLAGNAME_CONSULTSERVICE DECLARE_ASCII(ConsultService ) // deprecated #define FILTERFLAGNAME_3RDPARTYFILTER DECLARE_ASCII(3rdPartyFilter ) // x #define FILTERFLAGNAME_PACKED DECLARE_ASCII(Packed ) // x #define FILTERFLAGNAME_SILENTEXPORT DECLARE_ASCII(SilentExport ) // x #define FILTERFLAGNAME_BROWSERPREFERED DECLARE_ASCII(BrowserPrefered ) // deprecated #define FILTERFLAGNAME_PREFERED DECLARE_ASCII(Prefered ) // x Thanks, Allen
RE: [dev] documentation for filter flags?
Just to follow up on this question, what in particular does the NOTINCHOOSER flag do? In testing, and in examining the source code, it appears to do nothing. In contrast, the NOTINFILEDIALOG hides the format in all dialogs, including File | Open, File | Save As and File | Export. I'm using OOo v2.0.4 en-us under WinXP. Allen -Original Message- From: Allen Pulsifer [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 10:23 AM To: dev@openoffice.org Subject: [dev] documentation for filter flags? Are the file filter flags documented somewhere? The flags I'm referring to are defined in filter\source\config\cache\constant.hxx and are used in the configuration (.xcu) files: /** @short names of filter flags. */ #define FLAGNAME_3RDPARTYFILTER _FILTER_CONFIG_FROM_ASCII_(3RDPARTYFILTER ) #define FLAGNAME_ALIEN _FILTER_CONFIG_FROM_ASCII_(ALIEN ) #define FLAGNAME_ASYNCHRON _FILTER_CONFIG_FROM_ASCII_(ASYNCHRON ) #define FLAGNAME_BROWSERPREFERRED _FILTER_CONFIG_FROM_ASCII_(BROWSERPREFERRED ) #define FLAGNAME_CONSULTSERVICE _FILTER_CONFIG_FROM_ASCII_(CONSULTSERVICE ) #define FLAGNAME_DEFAULT _FILTER_CONFIG_FROM_ASCII_(DEFAULT ) #define FLAGNAME_EXPORT _FILTER_CONFIG_FROM_ASCII_(EXPORT ) #define FLAGNAME_IMPORT _FILTER_CONFIG_FROM_ASCII_(IMPORT ) #define FLAGNAME_INTERNAL _FILTER_CONFIG_FROM_ASCII_(INTERNAL ) #define FLAGNAME_NOTINCHOOSER _FILTER_CONFIG_FROM_ASCII_(NOTINCHOOSER ) #define FLAGNAME_NOTINFILEDIALOG _FILTER_CONFIG_FROM_ASCII_(NOTINFILEDIALOG ) #define FLAGNAME_NOTINSTALLED _FILTER_CONFIG_FROM_ASCII_(NOTINSTALLED ) #define FLAGNAME_OWN _FILTER_CONFIG_FROM_ASCII_(OWN ) #define FLAGNAME_PACKED _FILTER_CONFIG_FROM_ASCII_(PACKED ) #define FLAGNAME_PREFERRED _FILTER_CONFIG_FROM_ASCII_(PREFERRED ) #define FLAGNAME_READONLY _FILTER_CONFIG_FROM_ASCII_(READONLY ) #define FLAGNAME_SILENTEXPORT _FILTER_CONFIG_FROM_ASCII_(SILENTEXPORT ) #define FLAGNAME_SUPPORTSSELECTION _FILTER_CONFIG_FROM_ASCII_(SUPPORTSSELECTION) #define FLAGNAME_TEMPLATE _FILTER_CONFIG_FROM_ASCII_(TEMPLATE ) #define FLAGNAME_TEMPLATEPATH _FILTER_CONFIG_FROM_ASCII_(TEMPLATEPATH ) #define FLAGNAME_USESOPTIONS _FILTER_CONFIG_FROM_ASCII_(USESOPTIONS ) #define FLAGNAME_COMBINED _FILTER_CONFIG_FROM_ASCII_(COMBINED ) Similar flags appear in framework\inc\filterflags.h and in framework\source\constant\filter.cxx: /*-*** ** ***//** @short These values describe our supported filter flags. @attention Don't change flag values without reason - we must support old functionality and position in flag combined values! *//*-* ** **/ #define FILTERFLAGNAME_IMPORT DECLARE_ASCII(Import ) // x #define FILTERFLAGNAME_EXPORT DECLARE_ASCII(Export ) // x #define FILTERFLAGNAME_TEMPLATE DECLARE_ASCII(Template ) // x #define FILTERFLAGNAME_INTERNAL DECLARE_ASCII(Internal ) // x #define FILTERFLAGNAME_TEMPLATEPATH DECLARE_ASCII(TemplatePath ) // x #define FILTERFLAGNAME_OWN DECLARE_ASCII(Own ) // x #define FILTERFLAGNAME_ALIEN DECLARE_ASCII(Alien) // x #define FILTERFLAGNAME_USESOPTIONS DECLARE_ASCII(UsesOptions ) // x #define FILTERFLAGNAME_DEFAULT DECLARE_ASCII(Default ) // x #define FILTERFLAGNAME_EXECUTABLE DECLARE_ASCII(Executable ) // deprecated #define FILTERFLAGNAME_SUPPORTSSELECTION DECLARE_ASCII(SupportsSelection) // x #define FILTERFLAGNAME_MAPTOAPPPLUG DECLARE_ASCII(MapToAppPlug ) // deprecated #define FILTERFLAGNAME_NOTINFILEDIALOG DECLARE_ASCII(NotInFileDialog ) // x #define FILTERFLAGNAME_NOTINCHOOSER DECLARE_ASCII(NotInChooser ) // x #define FILTERFLAGNAME_ASYNCHRON DECLARE_ASCII(Asynchron) // x #define FILTERFLAGNAME_CREATOR DECLARE_ASCII(Creator ) // deprecated #define FILTERFLAGNAME_READONLY DECLARE_ASCII(Readonly ) // x #define FILTERFLAGNAME_NOTINSTALLED DECLARE_ASCII(NotInstalled ) // deprecated #define FILTERFLAGNAME_CONSULTSERVICE DECLARE_ASCII(ConsultService ) // deprecated #define FILTERFLAGNAME_3RDPARTYFILTER DECLARE_ASCII(3rdPartyFilter ) // x #define FILTERFLAGNAME_PACKED DECLARE_ASCII(Packed ) // x #define FILTERFLAGNAME_SILENTEXPORT DECLARE_ASCII(SilentExport ) // x #define FILTERFLAGNAME_BROWSERPREFERED DECLARE_ASCII(BrowserPrefered ) // deprecated #define FILTERFLAGNAME_PREFERED DECLARE_ASCII(Prefered ) // x Thanks, Allen
[dev] paths configuration in v2.0.4
I'm looking over the new Path's configuration and it seems to me the implementation is awkward and does not follow the usually configuration paradigm. In OpenOffice.org v2.0.3 and prior, paths were configured via org.openoffice.Office.Common/Path/Default and org.openoffice.Office.Common/Path/Current. This mechanism followed the usual paradigm of key-value pairs, where the key would tell you what information you were looking for, and the value would tell you the setting. So for example, if you wanted to know (or set) the default value for the template's path, you would look at org.openoffice.Office.Common/Path/Default and retrieve (or set) the value of the key Template. This system had several advantages: (a) If you want to know or set the value for a particular key, you can access it by key name. (b) The value for a key could be overridden by a short fragment of XML, at any configuration layer. (c) The key-value pairs could be stored in a database, in a traditional way. The new configuration mechanism for v2.0.4, as documented in http://specs.openoffice.org/appwide/options_settings/OOoPaths.odt, replaces the usually key-value pairs with the following: The configuration settings were moved to org.openoffice.Office.Paths. Within this tree, there is a node for each path (Template, Dictionary, Basic, etc.). For each path: a. There are two key-value pairs, UserPaths and WritePaths, that work as expected. b. There is a third subtree, InternalPaths, that contains a set of what could be considered keys. These keys work completely differently. For the keys in the InternalPaths tree, the key is the value and the value is completely ignored. For example, for the Template path, InternalPaths contains a key named $(insturl)/share/template/$(vlang). (I've simplified it slightly by calling this a key; its actually not even a key, it's a group of type MultiPath that's named $(insturl)/share/template/$(vlang) and forms another subtree that contains a single key Unused that is completely ignored. Thus the name of the group or subtree is what serves as the value, and both the key within this group and its value are ignored). This has more than a few disadvantages. First, as far as I can see (but please correct me if I am wrong) it is not possible to write a short fragment of XML that overrides the value of this setting, therefore making true layered configuration impossible. Second, it is not possible to look this value up or set the value by name, instead, to look the value up, or set the value, you have to already know the value, i.e., the value is looked up or set by value and has no independent name. The new path configuration could have been implemented using the key-value paradigm, and maintaining all its advantages while still accomplishing the same goals, as follows: InternalPaths would contain a set. Each component that wishes to set an InternalPath would create a key (also known as a node) within this set using its own name. For example, the base application would create a key called org.openoffice.Office.Paths/Template/InternalPaths/org.openoffice.app An add-on called SuperTemplates by acme.com might create a key called: org.openoffice.Office.Paths/Template/InternalPaths/com.acme.supertemplates The value of these keys would be string-lists, just as before. The multi-layer configuration parser would take these keys and merge them together into one long string, just like it does now, except that it would merge the key values, not the key names. The advantage of this configuration method is that it maintains the key-value paradigm. The value of a key can be looked up without already knowing a value. If an administrator wanted to override the value of Template path used by the application, he/she could do so with a short fragment of XML that simply replaces the value of org.openoffice.Office.Paths/Template/InternalPaths/org.openoffice.app. This XML fragment would look just like every other XML fragment used to configure OOo. Similarly, for each add-on installed, an administrator could customize the installation by only knowing the names of the components, not the values of its paths. If this is a simple change to make, I would propose it be adopted for v2.1. At minimum, I believe to the extent possible the key-value paradigm for configuration should be maintained. There was no reason to break it in order to allow multiple components to set paths, and by breaking it, some things that should be simple, both to do and to understand, become much more difficult. Sincerely, Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] RestrictedPath working under Windows?
I would also be interested in changing RestrictedPath from an environmental variable to a configuration (.xcs/.xcu) setting. I'm realizing that it make this useful, a system administrator would probably need a way to insert the user's username or WinNT domain\username into the path. So for example, the system administrator could set RestrictedPath to \\fileserver\userfiles\$(username) and OOo would make the appropriate substitution. The same feature would be useful with any of the path variables in org.openoffice.Office.Common/Path. See http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml#1_2 _7_2_Path_Variables Is there a way to do this already? If not, I think it would make sense to add this to framework\source\services\substitutepathvars.cxx (and possibly also to svtools\source\config\pathoptions.cxx Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] RestrictedPath working under Windows?
I'm trying to get RestrictedPath working, as described under Declaring the Permitted Folders in http://ui.openoffice.org/specification/FileDialog_RestrictedPaths.sxw I'm using OOo v2.0.3 under WinXP. Do you use system dialogs, or OOo's own dialogs? The feature only works with the latter ... Hello Frank, I'm using what is compiled into the OOo Windows binary distribution and configured by default, which I'm guessing is the system dialogs. Is there a way to select OOo's dialogs, either at run-time or build-time? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] RestrictedPath working under Windows?
Is there a way to select OOo's dialogs, either at run-time or build-time? At runtime, Tools|Options|OpenOffice.org|General|[X] Use OpenOffice.org dialogs is the place to control this. That and the corresponding configuration option (org.openoffice.Office.Common/Misc/UseSystemFileDialog = false) both worked to switch to OOo's dialogs. With that setting, RestrictedPath mostly worked. With only one directory in the RestrictedPath, the behavior was not quite what I expected. It allowed me to navigate up to the parent directories, all the way to the root (c:\). It didn't allow me to save there, but it was unexpected I was able navigate there since this was above the restricted directory. When I had more than one directory in RestrictedPath, it made more sense. By allowing me to navigate up the parents all the way to the root (c:\), I was able to get from one directory to the other. So it mostly worked, but the behavior was not what I expected when I had only one directory in the RestrictedPath. Thank you for the assistance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] RestrictedPath working under Windows?
With that setting, RestrictedPath mostly worked. With only one directory in the RestrictedPath, the behavior was not quite what I expected. It allowed me to navigate up to the parent directories, all the way to the root (c:\). It didn't allow me to save there, but it was unexpected I was able navigate there since this was above the restricted directory. Hmm. For multiple paths, as you found, it is useful to be able to travel above the paths. But for one path, it might make sense to let this single path be the virtual root in the file picker. Are you interesting in fixing this? Hello Frank, The answer is yes, but. I would be interested in fixing it, but I'm not sure when I would be able to get to it. I do have a potential customer who is interested in this feature, and if that is an issue for him then I will fix it. I would also be interested in changing RestrictedPath from an environmental variable to a configuration (.xcs/.xcu) setting. Is there a specific reason an environment variable was chosen over a configuration setting? How could changing to a configuration setting be done without adversely affecting existing users -- use the configuration value if it is set, otherwise look to the environment variable? Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] RestrictedPath working under Windows?
Ah, I'm looking forward to when you come asking *where* in the code to fix it :) That's easy to find. There are only about a dozen matches in the source code for RestrictedPath and RestrictedPaths ;-) The idea was to have a feature which prevents users from changing the respective setting. Nowadays, where the configuration supports locking settings into readonly state, probably nothing is to say against making this a configuration setting. That was my concern, too, which is why I didn't understand the choice of a environment variable. On Windows XP, you have both system variables and user variables. If both values are set, the user value overrides the system value. In fact, I just tried this, setting two different values for RestrictedPath, one in a system variable in the other in a user variable, and OOo used the user value. Is there something I'm missing? Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] RestrictedPath working under Windows?
The most correct would be to use a configuration value with no default, which means you get a NIL value (a VOID Any in UNO) when reading. Then you could have VOID - look at environment Non NIL - Use the value IMHO, that is overkill. It is true that would allow an empty RestrictedPath to be set in the .xcu file that could not be overridden by a user environmental variable, but what is the benefit? If the user overrides an empty RestrictedPath, I don't see the harm. It would be less complex and therefore less prone to system administrator and programmer error to just treat a nil and empty string the same. I suggest: if .xcu value not empty: use it else: look to environment - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] RestrictedPath working under Windows?
I'm trying to get RestrictedPath working, as described under Declaring the Permitted Folders in http://ui.openoffice.org/specification/FileDialog_RestrictedPaths.sxw I'm using OOo v2.0.3 under WinXP. If I set the environment variable RestrictedPath, my user directory is set to the first component, as described under Standard Working Directory in the above referenced document. [I see this happens at OOC680_m7\desktop\source\app\app.cxx lines 1548-1558, and is distinct from the remaining functionality implemented via OOC680_m7\svtools\source\misc\restrictedpaths.cxx] None of the other functionality works, in particular, restricting where the file chooser can navigate and where a document can be saved. Is this working under Windows? I see a few fixed issues that only address unix-type paths: http://qa.openoffice.org/issues/show_bug.cgi?id=53649 http://qa.openoffice.org/issues/show_bug.cgi?id=53939 If it does work under Windows, is there a special format for the RestrictedPath variable? I've tried c:\temp c:/temp \temp /temp file:///c:/temp All of these successfully change my user directory, but don't do anything else. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]