[dev] OpenOffice.org status and v3.4 final release

2011-04-26 Thread Allen Pulsifer
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 ?

2008-02-11 Thread Allen Pulsifer
 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 ?

2008-02-08 Thread Allen Pulsifer
 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 ?

2008-02-08 Thread Allen Pulsifer
  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 ?

2008-02-07 Thread Allen Pulsifer
 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 ?

2008-02-07 Thread Allen Pulsifer
 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 ?

2008-02-07 Thread Allen Pulsifer
 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 ?

2008-02-07 Thread Allen Pulsifer
   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 ?

2008-02-07 Thread Allen Pulsifer
 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 ?

2008-02-05 Thread Allen Pulsifer
 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

2007-10-09 Thread Allen Pulsifer
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

2007-10-09 Thread Allen Pulsifer
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

2007-10-08 Thread Allen Pulsifer
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

2007-10-05 Thread Allen Pulsifer
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)

2007-09-28 Thread Allen Pulsifer
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)

2007-09-28 Thread Allen Pulsifer
 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)

2007-09-28 Thread Allen Pulsifer
 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 ?

2007-06-22 Thread Allen Pulsifer
  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

2007-05-19 Thread Allen Pulsifer
 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

2007-02-15 Thread Allen Pulsifer
 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

2007-02-13 Thread Allen Pulsifer
 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

2007-02-13 Thread Allen Pulsifer
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

2007-02-10 Thread Allen Pulsifer
 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

2007-02-08 Thread Allen Pulsifer
  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

2007-02-07 Thread Allen Pulsifer
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

2007-02-07 Thread Allen Pulsifer
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?

2007-01-20 Thread Allen Pulsifer
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

2007-01-18 Thread Allen Pulsifer
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

2007-01-18 Thread Allen Pulsifer
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?

2006-10-23 Thread Allen Pulsifer
  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

2006-10-23 Thread Allen Pulsifer
  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?

2006-10-22 Thread Allen Pulsifer
 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

2006-10-22 Thread Allen Pulsifer
 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

2006-10-21 Thread Allen Pulsifer
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?

2006-10-18 Thread Allen Pulsifer
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?

2006-10-18 Thread Allen Pulsifer
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

2006-10-17 Thread Allen Pulsifer
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?

2006-07-17 Thread Allen Pulsifer
  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?

2006-07-14 Thread Allen Pulsifer
  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?

2006-07-14 Thread Allen Pulsifer
  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?

2006-07-14 Thread Allen Pulsifer
  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?

2006-07-14 Thread Allen Pulsifer
 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?

2006-07-14 Thread Allen Pulsifer
 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?

2006-07-13 Thread Allen Pulsifer
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]