[dev] [Fwd: [installation-dev] Updating to OOo 2.1 & language packs]

[Oliver Braun]

Forwarding this to a broader audience since I did not get any replies yet.

Please reply on [EMAIL PROTECTED]

Thanks,
Oliver

 Original Message 
Subject:[installation-dev] Updating to OOo 2.1 & language packs
Date:   Wed, 25 Oct 2006 13:04:11 +0200
From:   Oliver Braun <[EMAIL PROTECTED]>
Reply-To:   dev@installation.openoffice.org
To: dev@installation.openoffice.org



Hi *,

with the move to the new numbering schema also the default installation 
directory changes from "OpenOffice.org 2.0" to "OpenOffice.org 2.1" 
resp. from "openoffice.org2.0" to "openoffice.org2.1".


Assuming that users might have language packs installed in their OOs 
2.0.x, the result when updating will be platform dependant:


* on Windows, the installer will detect the existing 2.0.4 and propose 
"OpenOffice.org 2.0" as destination directory instead => language packs 
still there, but potentially incompatible (might even lead to crashes).


* on Unix, the default directory "openoffice.org2.1" will be used, 
resulting in a naked OOo 2.1 with the language packs still present in 
"openoffice.org2.0".



Shouldn't we issue a warning on Windows and install to "OpenOffice.org 
2.1" by default as on Unix ? Users willing to take the risk might still 
choose the "OpenOffice.org 2.0" manually.


- Oliver

-
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] UNO component language....java vs python

[Laurent Godard]

Hi


I need to write a UNO component - I am familiar with Java and Python -


Both languages are valuable for UNO components


I am attracted by the ease and the scripting paradigm of python - but


:-)


the support in openoffice for Java appears to be better?  I have a
feeling that the python UNO interface has not been updated in a while.



What do you mean by support ? if documentation, yes 
The developpers guide is entirely (almost) provided with java example
But this can be easily translated into other languages

Any documentation written dedicated to python is welcommed. Some is 
already available but it is not that complete. See Extensions website

http://wiki.services.openoffice.org/wiki/Extensions
http://wiki.services.openoffice.org/wiki/Extensions_development_python

For the pyUNO, any volunteer helping maintaining the bridge is always 
welcomed.



Would it be wise to go the python route for creating the UNO component...?



FYI, a key feature as the mailmerge in OOo is written in python
the more python will be used, the more it will live

Btw, use the language you're more comfortable with. Both are valuable to 
me. Some other shining people will advocate the use of java


The most important is to provide functionalities to OOo in the easiest 
maneer


if you have questions regarding extensions, you may contact the 
following mailing lists :

[EMAIL PROTECTED] for creating your extension
[EMAIL PROTECTED] for creating tools, documentation that 
make experience creating extensions easier

[EMAIL PROTECTED];org to any OOo API related question

Thanks

Laurent

--
Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org - 
http://www.indesko.com
Nuxeo Enterprise Content Management >> http://www.nuxeo.com - 
http://www.nuxeo.org

Livre "Programmation OpenOffice.org", Eyrolles 2004-2006

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Thorsten Ziehm]

Hi Kohei,



There are mainly two complaints I have with the current specification 
project:


1) It asks for way too many details, especially in the UI design
section.  It's not too bad if the feature involves only one
control/widget change.  But once the change involves three or more
dialogs, with each dialog having an average of 7 to 8 controls, it
starts to become a real pain in the rear, aside from the fact that the
Basic runs and errors everytime I change the value of that combo box
(ok, I'll stop complaining about this because I think I've already got
my point across to the right person :-).



Without details a new feature isn't clear.
An example you want to design a new car. One important thing are the
tires. You said the development team you need a tire for your new car.
In you mind you know all details you need at the tires - height, width,
rim, how many bots etc. Without writing this into a specification, the
other team do not know, what you need and where it is good for.

The specification template is should a support to do not forget
something in a dialog. And there are many things you can forget, when
you have to work platform independent and language independent.


2) The target audience is not very clear.  Thanks to this thread,
though, now I'm beginning to see who the specification documents are
intended for (mostly for QA, right?).  But without knowing who will
actually read my specification and how my spec will get used, I'd have
hard time setting the right level of granularity so that I can do
absolutely minimal but still make my spec document useful for someone.



The specifications are for the developers, the quality assurance and the 
documentation team.

- without a specification the developers doesn't know what has to be
  implement
- without a specification the QA member doesn't know what has to be
  check/text
- without a specification the writer for online help doesn't know what
  has to be written



Call me lazy, but when I'm writing a spec, I don't feel productive, so
I just want to get it over with as quickly as possible.  Aside from
the fact that, when I'm trying to write a spec late at night after my
kids are asleep, my motivation meter begins to fall rapidly, and my
typing speed begins to crawl. ;-)



I know that. Documentation isn't my favorite job too. But it has to be
done, that my boss or my team know all important things. It's the same,
as to write specifications. You write down all the things, you have to
communicate, that all teams around you (and the users) know how your
implementation works.


But doesn't an externally contributed feature come pretty much when
it's complete (or nearly so)?  If so, then a spec is written after the
fact, which means the spec can be easily retrofitted to be "in sync
with the code".  In this scenario, a spec cannot be used to verify the
implementation, because the implementation is done first.  You can do
the opposite, perhaps, to verify the spec against the implementation.
I did that for my first specification (natural sort), and I'll
probably do it for my second spec (solver), too.

So, my workflow seems different from yours, which itself may be a
problem when being involved in this project.  But that's how I write
my code in my free time.



I learned at my study. Before implementation draw flow charts, write
down all dependencies, make small specifications for any action you want
to implement. That will reduce the re-work costs. What I did was to
write first the code and create then the flow charts. The dependencies I
found, because my code fails in the first implementation.

I learned that it takes more time, to implement first the code and write
down the specification afterwards. But the coding was more funny and I
didn't changed my handling at my study.

Now I am at a company and learned, that re-work costs are really costs
money and is very annoying for the users. Therefore I am now a fan of
the processes which are taught at study.

Thorsten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ...

[Kai Backman]

On 10/31/06, Mathias Bauer <[EMAIL PROTECTED]> wrote:

This was an "enhancement", not a bugfix. If you read the issue you can
see that it covered quite a lot of considerations. I don't know enough


There are 36 reported issues and over 120 votes for this problem.
Users have hidden a number of cells and perform an action on the
visible ones. Based on their experience the expectation is that the
hidden cells stay unchanged. Instead their spreadsheet is botched.
What if they save before they realize the damage and don't have a
backup? Whatever we call the issue, it's pretty clear it hurts users.

We all want to improve quality. The user is the one who judges
quality. -Not- QA and certainly not us developers. Maybe this
specification discussion is really about more fundamental priorities.
This issue has been open for five years. Over those five years, how
has the specification process improved the user experience?

Are we writing software for the users or us developers? :-)

Kai



On 10/31/06, Jim Watson <[EMAIL PROTECTED]> wrote:

You have highlighted exactly the issue in this case - users see that
this is clearly a bug or a defect, but the developer says the
behaviour is intended.



--
Kai Backman, Software Engineer, [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Thorsten Ziehm]

Hi Michael,

Michael Meeks wrote:

Hi Mathias,

So, while broadly agreeing with most of what you say:

On Mon, 2006-10-30 at 08:53 +0100, Mathias Bauer wrote:

Without the spec the QA wouldn't be able to even find bugs in
many cases (with the exception of obvious ones).


We hear this a lot. And, now we know that specifications are frequently
inaccurate, buggy / out of sync with the code anyway. So - I'm having


The team which worked out the specification process know that the
specifications are not in the highest quality now. This is a learning
process for each member on the specification (User Experience,
Development, Quality Assurance and Documentation). So each team makes
errors know. But the errors are lower than without having a process,
like in OOo 1.1.x time frame.


problems understanding what -exactly- QA need here. It'd help to have 10
representative examples of times when a specification has actually
helped distinguish between bugs & features, and what was done with that
information [ writing tests / whatever ].



You can take nearly each of the new specifications and the corresponding 
CWS. You will see, that very often bugs were written after the CWS go

into the QA for the first time.


Thorsten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] UNO component language....java vs python

[Stephan Bergmann]

ashok _ wrote:

Hello there:

I need to write a UNO component - I am familiar with Java and Python -
I am attracted by the ease and the scripting paradigm of python - but
the support in openoffice for Java appears to be better?  I have a
feeling that the python UNO interface has not been updated in a while.


Yes, Java might be better here if you want to play it safe.

-Stephan


Would it be wise to go the python route for creating the UNO component...?

thanks

Ashok


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] UNO component language....java vs python

[Tom Schindl]

Hi,

Stephan Bergmann schrieb:
> ashok _ wrote:
>> Hello there:
>>
>> I need to write a UNO component - I am familiar with Java and Python -
>> I am attracted by the ease and the scripting paradigm of python - but
>> the support in openoffice for Java appears to be better?  I have a
>> feeling that the python UNO interface has not been updated in a while.
> 
> Yes, Java might be better here if you want to play it safe.

And with the new Netbeans and Eclipse-Plugins development might be easier.

Tom



signature.asc
Description: OpenPGP digital signature

RE: [dev] Specification Process Possibilities ...

[Utomo]

Agree, 

I have met some people who has dissapointed about something and after that
they will feel very bad, especially if it is losing data. 
After they feel dissapointed, it will become more difficult to attract that
people to try again the products in future. 
They may feel that next time maybe another kind of bugs which is not
explained by others may happened and also make troubles. 

I found some issue which interesting
http://www.openoffice.org/issues/show_bug.cgi?id=33851
http://www.openoffice.org/issues/show_bug.cgi?id=20496
http://www.openoffice.org/issues/show_bug.cgi?id=17245
http://qa.openoffice.org/issues/show_bug.cgi?id=20345
And others

I hope it can be solved in Ooo 2.2, especially because it can make user
losing data. Which I think is not a good experience for user.

We need to reduce the problems which make user feel bad about Ooo. 

Just my 2c 

Thanks,


Utomo

   

-Original Message-
From: Kai Backman [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 31, 2006 3:52 PM
To: dev@openoffice.org
Subject: Re: [dev] Specification Process Possibilities ...

On 10/31/06, Mathias Bauer <[EMAIL PROTECTED]> wrote:
> This was an "enhancement", not a bugfix. If you read the issue you can 
> see that it covered quite a lot of considerations. I don't know enough

There are 36 reported issues and over 120 votes for this problem.
Users have hidden a number of cells and perform an action on the visible
ones. Based on their experience the expectation is that the hidden cells
stay unchanged. Instead their spreadsheet is botched.
What if they save before they realize the damage and don't have a backup?
Whatever we call the issue, it's pretty clear it hurts users.

We all want to improve quality. The user is the one who judges quality.
-Not- QA and certainly not us developers. Maybe this specification
discussion is really about more fundamental priorities.
This issue has been open for five years. Over those five years, how has the
specification process improved the user experience?

 Are we writing software for the users or us developers? :-)

Kai



On 10/31/06, Jim Watson <[EMAIL PROTECTED]> wrote:
> You have highlighted exactly the issue in this case - users see that 
> this is clearly a bug or a defect, but the developer says the 
> behaviour is intended.


--
Kai Backman, Software Engineer, [EMAIL PROTECTED]

-
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] Specification Process Possibilities ...

[Niklas Nebel]

Jim Watson wrote:

http://www.openoffice.org/issues/show_bug.cgi?id=2977

In this case something different was specified and fixed, while the bug 
persists at

http://www.openoffice.org/issues/show_bug.cgi?id=33851


Are you saying it's a bad thing that there is a specification that 
details what was done for 2.0? Would you prefer us saying "We've done 
something about this issue, wait for the release to see what it was"?


Niklas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ...

[Niklas Nebel]

Kai Backman wrote:

We all want to improve quality. The user is the one who judges
quality.


If users don't agree with each other, that doesn't help much. Unless you 
want to play ping pong and "fix" the behavior back and forth with each 
release.


Niklas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ...

[Thorsten Ziehm]

Hi Michael,

many questions are answered by Mathias already. Some open questions
I want to answer.

Michael Meeks wrote:


As for the quality of OO.o 2.0.0 [ created AFAIR after the
specification process was introduced ], I think it was a fairly
'interesting' release (defect wise), hence the compound slippage etc.



Yes the specification process was introduced in OOo 2.0 time frame. But
it doesn't work, as you said. The bug count was high in OOo 2.0.
Therefore a template for specifications were developed to eliminate the
most important faults.




I think this is one reason why OpenOffice.org is so successful.


Do you have data to back that up ?



It isn't possible to get data here. But from my own feeling and
discussion with many people, quality is the highest priority.


Perhaps their bugs are of the form:

"OO.o is incredibly slow to start"



Yes this is a bug. But I think it is more than one bug.


Good unit testing [ as in I can run "dmake check" in configmgr and get
a yes/no answer in a few seconds ], such as I've implemented in previous
projects I've worked on [eg. the several thousand lines of unit test in
ORBit2] is invaluable. It helps re-factoring, it improves quality and
confidence in the product, and so on. Of course UNO components
substantially complicate such unit testing in OO.o (along with
(apparently) a love of only testing what can be tested via UNO, from
Java ;-). At least, I've not been able to understand the useful / common
recipe for running "do tests" or whatever in a given source directory &
getting useful data - I'd love to be shown how this works.



Unit tests and tests with automated TestTool are different level of
quality assurance in Software. Unit tests are used to check the code
itself. The next level are API tests to check the integrated code
in the whole content. At UI level the automated testing with TestTool
is done. If the first levels are not done efficiently it will be more
difficult for the UI testing. Mostly the general stability is broken
or something else.

When we do have more testing on integration level will reduce the level
of UI testing with TestTool.


So - I need a deeper understanding of what you understand by quality
and how you weight these statements:



User perspective  :
In my opinion we had the following goals in the last updates.
(I changed the order of your points)


+ Quality is OO.o not crashing (stability)
+ Quality is OO.o not loosing data
+ Quality is OO.o loading & saving my 'foreign' data files
+ Quality is OO.o performing acceptably

>+ Quality is OO.o not consuming all available memory

+ Quality is OO.o behaving ergonomically as I expect
+ Quality is OO.o being slick & beautiful
+ Quality is OO.o being feature competitive with others


Code contributor perspective  :
These are important points too. These are and should be goals for
the development. I cannot speak about that, because I am not
the professional in code quality.


+ Quality is OO.o source code being readable
+ Quality is OO.o source code being maintainable
+ Quality is OO.o source code being consistent
+ Quality is OO.o source code not being cut/pasted


The quality (user and developer perspective) can be increased with
specifications. But specifications are not a part of the quality.

>+ Quality is every aspect of OO.o having a detailed spec.

Regards,
  Thorsten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Thorsten Behrens]

Thorsten Ziehm <[EMAIL PROTECTED]> writes:

> Thorsten responding to Kohei:
>
> An example you want to design a new car. One important thing are the
> tires. You said the development team you need a tire for your new car.
> In you mind you know all details you need at the tires - height, width,
> rim, how many bots etc. Without writing this into a specification, the
> other team do not know, what you need and where it is good for.
> 
> The specification template is should a support to do not forget
> something in a dialog. And there are many things you can forget, when
> you have to work platform independent and language independent.
>
I think the basic misunderstanding between our two camps (Sun people
vs. OOo volunteers) is the fact that the typical workflow is simply
radically different.

There's typically no such thing as formal upfront design for the
normal community developer, it's just that people have their personal
issues with OOo, and start fixing them in their private time. Like
Kohei did with the missing calc solver.

So, in the end, a volunteer dev pulls a feature out of her pockets
that adds some amount of value to OOo. The code might have issues, the
functionality might be incomplete, and the UI might not conform to
some guidelines (BTW, I'd really like to have a written-down list of
those UI requirements - in the Wiki or as an easily-digestible PDF
with a prominent link). But that's why we have patch review, and CWSs,
where we can polish that. And it's basically no difference in how
Sun-internal features are developed - those usually have several
cycles of implementation/testing/review, too.

But the difference is that there's no request from high-above to
implement a certain feature, and no dedicated time in user experience
to roll out a detailed UI spec beforehand. People just start
coding. So the example of car production might suit the way
Sun-internal features are developed, but it doesn't fit the
community. Community specs are nearly always after-the-fact
documentation of the implemented feature, thus, the argument that
specs save rework costs just doesn't apply here (simply - because all
the work has been done already, when the spec is written).

I don't question the need for _some_ documentation - QA and especially
help authors need a way to test and describe the things that newly
enter the product. But I do question the very strict requirements the
spec process puts on community contributions, and I second Michael's
statement that most of those requirements (in their current
installment of the spec process) don't add much value to the
production line (mind that - I'm talking about community contributions
here). 

In the end, specs serve multiple purposes Sun-internally:

 - have a feature well thought-out beforehand
 - have UI specified by experts (user experience)
 - have strings reviewed by experts
 - have feature documentation for QA
 - have feature documentation for help authors
 - ...etc. I've probably forgot a few more items.

The first three items should not be required for non-Sun
contributions, because they just don't affect us - if a CWS needs
rework because of them, it's the burden of the community dev. But they
should be free to choose their way, and not be pressed into a mold,
that has been designed for a Sun-employed OOo developer.

The remaining two (+N) items naturally need to be done in some way or
another, but my experience there is that every contributor just loves
to talk (and blog) about his feature - thus, gently directing that
enthusiasm into the right channels (wiki comes to mind) should really
be a non-issue. 

In the end, I'm all for changes that encourage people to spend their
spare time on OOo. We've checks and balances in place that will
prevent accidental breakage on the master. And we've some (minimal)
documentation requirements, to enable other people to do their
work. But the specifics, or even the outer form, of those
documentation, should IMO not be specified (no pun intended ;-)) in
minute detail - if QA or help authors miss something, they can simply
ask, can't they? I mean, that's what currently happens all the time,
even with the spec process in place. 

> Now I am at a company and learned, that re-work costs are really costs
> money and is very annoying for the users. Therefore I am now a fan of
> the processes which are taught at study.
> 
Absolutely correct. And I'd recommend every community developer
starting to implement a major feature to spend some time on planning &
discussion, even doing UI mock-ups. But we shouldn't _force_ them to
do that, and we shouldn't use that as an all-or-nothing argument for
the spec process. We should request what we really need
(documentation), and leave all the rest unspecified. ;-)

Just my 2 cents,

-- Thorsten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Thorsten Behrens]

Thorsten Ziehm <[EMAIL PROTECTED]> writes:

> The team which worked out the specification process know that the
> specifications are not in the highest quality now. This is a learning
> process for each member on the specification (User Experience,
> Development, Quality Assurance and Documentation). So each team makes
> errors know. But the errors are lower than without having a process,
> like in OOo 1.1.x time frame.
> 
Hi Thorsten,

I'm not sure whether having specs/not having specs in and of itself
has influence on the product quality. A spec only describes what
should be/what has been implemented. Ultimately, the QA is the gateway
to the main trunk, thus, their way of working and their means of
testing (and their ability to actually exercise hidden functionality)
determine what enters the master. 

For Sun-developed features, I'm absolutely on the same page with you
(simply because user experience does better UI than me, and Liz
does/did come up with better strings than me - by far. Let alone the
fact that a lot of people have then been thought about the feature,
and provided their feedback). But for community development? It's
basically a take-it-or-leave-it, isn't it? Take the feature as-is, or
don't take it. Having a spec tacked onto it does not change the
feature at all - it's there, already.

Providing means for QA and help to actually _understand_ what's been
sent to them is of course non-negotiable - but I would tend to call
that documentation, not spec (because the formal requirements are much
more relaxed).

> You can take nearly each of the new specifications and the
> corresponding CWS. You will see, that very often bugs were written
> after the CWS go into the QA for the first time.
> 
I don't think this is a valid argument here - it is a normal part of
the CWS process, and even the prime purpose of QA, to find issues in a
CWS before they hit the master. Be it with or without specs. And of
course, a severe CWS issue is missing/incomplete documentation of what
has been done in it.

Cheers,

-- Thorsten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] About contributing...

[FireS BurnsmuP]

I am not the greatest of programmers, but that is my area of relative 
expertise.


I would like to suggest that (the collective of developers) try to make the 
program and its components more efficient, i.e. it would be nice if the 
suite were much smaller. This is the sole reason I previously chose MS 
Office over OOo.


If there are problems with this, then I'm sorry I bothered you. If it would 
be possible to size down everything, I would like to try and help.


RSVP

~ FireS

_
Add a Yahoo! contact to Windows Live Messenger for a chance to win a free 
trip! 
http://www.imagine-windowslive.com/minisites/yahoo/default.aspx?locale=en-us&hmtagline


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] Specifications and Release Notes = Re: [dev] Specification Process Possibilities ... what about a wiki?

[Bernd Eilers]

Hi there!

There´s one thing we should not forget when discussing to use the Wiki 
for creating Specifications.


We do have a semi-automated process to generate Release Notes. This 
takes advantage of the OpenOffice Document file format and a standard 
template being used for the specification documents. Information from 
specifications documents is extracted via XSLT and a "What´s new guide" 
HTML page is created which is the basis for the Release Notes.


See for example: http://development.openoffice.org/releases/2.0.4rc3.html

If we want to work on Specifications in the Wiki there are two 
possibilities:


1.) After work is finished in the Wiki and at a give time just before 
the release, let´s say at UI - Freeze or something like that content 
from the Wiki must be moved to a .odt document.



2.) We need to work on the process to create the document for the 
Release Notes and create a new feature there to be able to extract 
information from the WiKi and we also need to set up some kind of 
template and corresponding rules on how specs in the Wiki do have too 
look to be able to find the information that is going to be extracted 
for the Release Notes.



If we go for 1.) we should take into account that we
do also have Feature Mails and that those contain the link to the 
specification which is used in the process to generate the release 
notes, so the move from Wiki to .odt must be done at least before the 
feature mail is being written.


For 2.) I think it might be not as easy to extract information from the 
wiki as it is to extract that from the OpenDocument Format, but we would 
have to see.



Kind regards,
Bernd Eilers


David Fraser wrote:

Hi Christian

Thanks for your offer! I think a wiki version of the Template would be a 
substantial aid to many people, and from the rest of the response on the 
mailing list I'm not alone in thinking that.
Could you let us know if you start working on this - I presume 
wiki.services.openoffice.org is the place - as then others could perhaps 
participate :-)


Regards
David

Christian Jansen wrote:


Hi David,
from a feature documentation perspective it makes no difference to use 
the template, a wiki, a HTML page, or what ever comes into your mind.


I think it is more important that the UI feature and its functionality 
is described in well mannor. I personally think a wiki is absolutely 
fine to do that, but both (template or wiki) should follow the same 
guidelines.


The template was intended to give novice spec writers some help to 
write a spec. We decided to use the Writer format because it allows us 
to do some automation which makes it convenient to use. Especially 
creating complex tables in a wiki is no fun.


However, I can offer to create a wiki-version of the new template.


Regards,
Christian

David Fraser schrieb:


Kazunari Hirano wrote:


Hi,

Frank Schönheit wrote:


However, what I really *really* like about this process is
the exchange of ideas and arguments.



I respect the process.
I encourage community developers and CJK developers to access the spec
project wiki [1] and the spec template [2].


For issue 12719 I attempted to have a faster and more accessible 
specification process

This involved developing the spec collaboratively in the wiki
Unfortunately the spec team did not like this idea and have gone for 
an OOo template for designing specifications with
This is perhaps better than the previous system, but I think there 
are still significant cases where using a wiki is a much faster route 
for people (particularly outside contributors) to use to 
collaboratively produce a specification.
Unfortunately I did not have time to pursue this idea; fortunately 
the Sun team that took over the issue did look through our wiki-based 
spec and hopefully included some things - the issue is now fixed 
which is nice :-)


But I would like to propose that this approach to spec generation be 
given more thought. Reasons:

1) Wikis are designed for this
2) It is easier for a person not heavily involved in OOo to go to a 
wiki page, make a few changes, edit it, and submit, then it is to get 
a document out of version control etc, open it in OOo, change it and 
submit
3) The spec process is apparently working well for those inside Sun, 
less well for those outside. If there were an easier route for those 
less involved in development to produce specs it could be run 
concurrently as an alternate mechanism (possibly with a final step of 
converting to the required template format, that could be automated)
4) This would perhaps be particularly helpful for outside 
contributers who are not coders

5) Less likely to break due to problems in the OOo template macros :-)

This was done by having a wiki template that could then be filled out 
to produce the spec.


Thoughts?
David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Thorsten Ziehm]

Hi Thorsten B.


The specification template is should a support to do not forget
something in a dialog. And there are many things you can forget, when
you have to work platform independent and language independent.


I think the basic misunderstanding between our two camps (Sun people
vs. OOo volunteers) is the fact that the typical workflow is simply
radically different.



That the workflow is different I see, but why it should be? Re-work
costs is painful for every developer or other people who worked on
such a product. Therefore the workflow worked out by Sun should help to
reduce the working hours at spare time. If somebody want to code first
and write down the specification, it's fine for me. But I learned, that
this will take more time as to work the other way round.

I do not want to say, that every developer (internally or in the
community) should create the specification before or after the code
implementation. As you wrote, the most important thing is, that the
changes are documented. Which tooling is used I am uninterested. Use a 
wiki or use HTML or the specification template. But do not forget to

document all important things - listed in the template.

Currently the team worked out a Writer document with Basic in it. If
somebody can create a Wiki similar template, perhaps it can help to
reduce the barrier between the two camps (Sun and Community).



Absolutely correct. And I'd recommend every community developer
starting to implement a major feature to spend some time on planning &
discussion, even doing UI mock-ups. But we shouldn't _force_ them to
do that, and we shouldn't use that as an all-or-nothing argument for
the spec process. We should request what we really need
(documentation), and leave all the rest unspecified. ;-)



I totally agree.
As I often wrote in this mail and in other mails. The description of
the specification process and the approval process of a CWS or what ever
should help everybody to work in a optimized way. If the specification
(documentation) is written before or after the code is implemented in
a CWS isn't important for me. But if you hand over a CWS to other people
or before you want to integrate new feature (especially UI features) the
specification (documentation) must be in final state.

Thorsten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] cpu looping in cupsd and soffice.bin

[Andy Pepperdine]

On Thursday 26 October 2006 00:38, rklein wrote:
> Hi,
>
> I experience exactly the same problem like you with cupsd and OpenOffice in
> a loop. I have also SuSE (OpenSuSE 10.0) and OpenOffice 2.0 (build
> 2.0.0.1).
>
> Any luck looking for help at SuSE?

Sorry to be so late replying, but I was waiting for a response from the Suse 
forum; and the number of replies can be counted on no hands. So it looks like 
I need to get back to trying to investigate on my own to see if I can guess 
what is happening.

Andy.

>
> Randolf
>
> Andy Pepperdine wrote:
> > On Monday 23 October 2006 14:42, G. Roderick Singleton wrote:
> > [..]
> >
> >> Andy,
> >>
> >> Have you checked with Novell or SuSE support? I ask because I cannot
> >> reproduce the problem under FC5 and cups-1.2.4.
> >
> > I'm not surprised that you cannot reproduce it; it looks like a very
> > particular issue. But Suse is my next stop.
> >
> > Regards,
> > Andy.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where to find source code for X,,,

[CPHennessy]

On Fri October 27 2006 14:03, Enno Fennema wrote:
> I have two problems. Firstly, I can save a spreadsheet on a USB stick
> when using a new name so permissions appear to be ok. I can also later
> load that sheet from the USB stick but when I try to save it I get error
> message "Cannot create backup copy!!!" and nothing saved. I can save the
> spreadsheet with SaveAs under a new name. This problem only arises under
> SuSE Linux 9.2 x86_64.
> Running a pure 32 bit system everything works fine. I am quite happy to
> plod on and try to identify where things go wrong but that brings me to
> my second problem.
>
> I am a reasonably experienced programmer but have minimal experience in
> C++ and even less with the whole UNO setup. I find it very difficult to
> find what gets done where also as their appear to be directories in CVS
> outside Attic's that are no longer used (I think). My immediate question
> was therefor what procedure can I follow to find the source code for 1)
> store() and 2) for methods called from store() till I get down to the
> ucp or sal level. Is there LXR access to the repository?

Perhaps using strace will also show you if a particular system call failed.

-- 
CPH : openoffice.org contributor

Maybe your question has been answered already?
http://user-faq.openoffice.org/#FAQ

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Thorsten Behrens]

Thorsten Ziehm <[EMAIL PROTECTED]> writes:

> > I think the basic misunderstanding between our two camps (Sun people
> > vs. OOo volunteers) is the fact that the typical workflow is simply
> > radically different.
> >
> 
> That the workflow is different I see, but why it should be?
>
Why not? If this does not harm us, why limit other people's freedom?

> If the specification (documentation) is written before or after the
> code is implemented in a CWS isn't important for me. But if you hand
> over a CWS to other people or before you want to integrate new
> feature (especially UI features) the specification (documentation)
> must be in final state.
> 
I'd avoid the wording 'final' here, and rather say it must be
sufficient for the intended audience (QA and help). Which gives the
intended audience the opportunity to demand enhancements, if they feel
insufficiently educated. ;-)

Cheers,

-- 

Thorsten

If you're not failing some of the time, you're not trying hard enough.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... - unit testing

[Michael Meeks]

Hi Mathias,

Once again thank you for your thought provoking mail.

On Mon, 2006-10-30 at 23:57 +0100, Mathias Bauer wrote:
> You mix up some things here. Nobody said that we need a spec for each
> and every "tiny ergonomic fix". We need them for new features - e.g. a
> quickstarter on Linux. :-P

I refer you to the Sun rubric ** emphasis added.

http://wiki.services.openoffice.org/wiki/Category:Specification

"I Want to Change Something in OpenOffice.org - Do I Have to
 Write a Software Specification? 
 **In general the answer is YES**. This applies to:
 Features, Enhancements, **Defects**"

Now, of course we could explicitly exclude more things from this, which
would be good - but AFAICS - at least as of now, each tiny ergonomic
change requires -at-least- a round-trip to the team lead.

> So we have parts in the code that are unit-testable (and we have
> tests for it) but most code unfortunately is bound to some
> vcl/sfx/svx/etc. stuff that makes unit testing impossible.

Great - so, what pieces of code have functioning unit tests ? whenever
I hack on a module I like to try and find these tests, I poke in
'workben' and I see very frequently stale/un-buildable/un-runable code,
then I poke in qa/ and eg. in configmgr/qa/unoapi I see a makefile.mk I
'dmake' that, something happens and it barfs:

Exception in thread "main" java.lang.NoClassDefFoundError:
org/openoffice/Runner
dmake:  Error code 1, while making 'ALLTAR'

it appears broken out of the box.

I would -Love- to have a good, standardised unit testing framework in
place to add tests to, and let us re-factor code more aggressively with
confidence. However - I just don't see anything here.

> The long duration of the tests is indeed a problem.

Yep, and something we need to fix of course; hopefully some of Noel's
work on the performance of StarBasic's may help here.

> We are currently investigating how we can get faster tests, one
> direction we are looking into is avoiding or at least reducing the
> idle/sleeping times.

Yep - of course, understanding why these idle times are there would be
good I guess.

>  Other ideas are welcome. My very personal opinion
> is that we should have more API (code) based tests and less GUI testtool
> based ones but I know that there are other opinions. Must be discussed.

Well; of course from a 'community' perspective - I'm well up for adding
in-source, in-CWS, standardized, fast unit-tests. eg. reading the calc
'R1C1' work recently, I was itching to write a test-suite, that would
simply exercise this piece of the calc code & parse 100 formulae of
varying complexity and validate that the results were correct.

Unfortunately it's -really- difficult to do that.

> There's nothing wrong with doing unit and API tests in Java.

As long as they are easy to run with some standard command, I don't
much care what they're written in.

> And UNO components don't make anything more complicated

Au contraire - if you have built all of OO.o up to 'sc' (eg.) and you
now want to write a very small, very fast unit test to exercise just the
formula parsing piece - you have a nightmare. Somehow, you have to get
OO.o alive enough to actually start, bootstrap etc. you need to build a
custom .rdb file [ we have ugly unsustainable hacks in 'workben'
directories around the place to do some of this ]. You can't even read a
file in without having an huge types.rdb, services.rdb, a ton of paths
set right and a big piece of boilerplate code etc. etc. :-) AFAICS it's
a huge pain.

Of course - if there was an existing small/light/simple infrastructure
that tests could be easily added to, then I for one would write more
unit tests: this gap has frustrated me on the 2/3 times I've actually
wanted to sit down & write a block of test code. [ And really, arguably,
people should be writing the torture tests as they write the code ].

The other problem with UNO is you can only test what is exposed via.
UNO, and that is not enough to torture the internals often.

> Or is there anything you find more complicated in unit testing of UNO
> components? Then please give an example.

It's possible my horrific past experience of UNO bootstrapping is now
obsolete :-) if so, wonderful. I'm looking for a solution that doesn't
require "installation", can be run in the source tree very simply with
'dmake check' (eg.) and will run through a list of test modules, build
them, execute them, and report their output; and wrt. VCL - having a
live X/GUI connection, at least for now is just fine. Preferably being
able to automate this fully (on each CWS before it's nominated) would be
ideal.

> You again mix things here. This is no longer true for fixes in 2.0. And
> nobody asks for specs for bug fixes. Please give examples where a bug
> fix was not integrated because a spec was missing.

It depends what you see as a 

Re: [dev] Specification Process Possibilities ...

[Michael Meeks]

Hi Thorsten,

Thanks for your mail - this is good stuff.

On Tue, 2006-10-31 at 10:45 +0100, Thorsten Ziehm wrote:
> Yes the specification process was introduced in OOo 2.0 time frame.
> But it doesn't work, as you said. The bug count was high in OOo 2.0.
> Therefore a template for specifications were developed to eliminate
> the most important faults.

Sure - I just don't think that (given the mixed results of the initial
spec. process to substantially improve quality) it's possible to
authoritatively state that increases in code quality post 2.0.0 are due
to the [new] spec. process itself. So much changed (for the better),
it's hard to say where the dominant effects are.

> >> I think this is one reason why OpenOffice.org is so successful.
> > Do you have data to back that up ?
>
> It isn't possible to get data here. But from my own feeling and
> discussion with many people, quality is the highest priority.

Of course, anecdotally I have a different slant :-) to measure this -
if we do user surveys we could perhaps work out some questions to ask
that would measure this (though it's hard to phrase them I suppose):

"What did you notice most about OO.o 2.0
a) better interop
b) new Impress layout
c) improved stability
..."

it'd be interesting to see the result. [ I thought Sun did market
research of this form, perhaps Erwin has some hard data ].

> > "OO.o is incredibly slow to start"
> 
> Yes this is a bug. But I think it is more than one bug.

:-) indeed.

> Unit tests and tests with automated TestTool are different level of
> quality assurance in Software. Unit tests are used to check the code
> itself. The next level are API tests to check the integrated code
> in the whole content.

Sure - of course, being able to run large numbers of very complex tests
very quickly inside a local developer's build tree is clearly a good
goal, and (I hope) quite attainable.

> > So - I need a deeper understanding of what you understand
>> by quality and how you weight these statements:

This was very interesting indeed, and broadly I agree with you, so
perhaps we're not so far apart at all :-)

> User perspective  :
> In my opinion we had the following goals in the last updates.
> (I changed the order of your points)
> 
> > + Quality is OO.o not crashing (stability)
> > + Quality is OO.o not loosing data
> > + Quality is OO.o loading & saving my 'foreign' data files
> > + Quality is OO.o performing acceptably
>  >+ Quality is OO.o not consuming all available memory

And we don't do too badly with the above.

> > + Quality is OO.o behaving ergonomically as I expect
> > + Quality is OO.o being slick & beautiful
> > + Quality is OO.o being feature competitive with others

I guess these last 3 are what the spec. process targets, and of course
prolly where we need the most extra polish all over the place.
Unfortunately wrt. slickness the large number of small changes to make
OO.o 'slick' [ a vague term it's true ], are substantially retarded by
the spec. process - which concerns me.

> Code contributor perspective  :
> These are important points too. These are and should be goals for
> the development. I cannot speak about that, because I am not
> the professional in code quality.
> 
> > + Quality is OO.o source code being readable
> > + Quality is OO.o source code being maintainable
> > + Quality is OO.o source code being consistent
> > + Quality is OO.o source code not being cut/pasted

So - here we can perhaps use automated lint style tools to help [ eg.
the warnings redux work is really useful here I think ], we could also
(perhaps) use one or other of the cut/paste detection tools to generate
a metric before/afterwards and point out the delta. The other bits can
only be improved by code review I think.

> The quality (user and developer perspective) can be increased with
> specifications. But specifications are not a part of the quality.
> 
>  >+ Quality is every aspect of OO.o having a detailed spec.

And this is the wonderful. It's great that you view the spec. process
not as an end in itself, but one tool to achieve greater quality in
certain circumstances. Of course - ultimately it's clear that we both
want a higher quality end-user product, and we just need good processes
that encourage contributions that (we can be sure) raise the quality to
get into the main-line as fast as possible.

Regards,

Michael.

-- 
 [EMAIL PROTECTED]  <><, Pseudo Engineer, itinerant idiot


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... - unit testing

[Christian Lohmaier]

Hi Michael, *,

On Tue, Oct 31, 2006 at 02:27:23PM +, Michael Meeks wrote:
> On Mon, 2006-10-30 at 23:57 +0100, Mathias Bauer wrote:
> > You mix up some things here. Nobody said that we need a spec for each
> > and every "tiny ergonomic fix". We need them for new features - e.g. a
> > quickstarter on Linux. :-P
> 
>   I refer you to the Sun rubric ** emphasis added.
> 
> http://wiki.services.openoffice.org/wiki/Category:Specification
> 
>   "I Want to Change Something in OpenOffice.org - Do I Have to
>Write a Software Specification? 
>**In general the answer is YES**. This applies to:
>Features, Enhancements, **Defects**"

An unfair cite.
it is 
"Defects **requiring the following type of changes**: "

> [...]
> > You again mix things here. This is no longer true for fixes in 2.0. And
> > nobody asks for specs for bug fixes. Please give examples where a bug
> > fix was not integrated because a spec was missing.
> 
>   It depends what you see as a bug. I see something being unusable as a
> serious bug, because I care about usability; OTOH you might call fixing
> that 'a feature' :-) Ultimately, the end-user sees it as a bug, and the
> customer must be always right - surely ?-)

Whether a spec or not is needed is not a matter of "defect or feature".
It is the question whether the UI gets changed or not. Whether something
changes for the user or not.
Due to the nature of new Features, this implies basically every new
feature needs a spec, and on the other hand specs for defects are not
the common thing, but the exception to the rule. (again depens on how
you categorize your "defect")

>[...] 
> > Of course every rule can be changed if good arguments and (IMHO even
> > more important!) good alternatives are presented.
> 
>   Sure, so the suggestion of using the wiki for specs is positive - it
> removes a biggish barrier to entry, and (perhaps) makes it more useful.
> Some other constructive suggestions might be these:
>   
>   * duplicate as little state as possible:
>   + no i18n data, no screenshots in specs

I agree to the i18n data, but not to the screenshots. At least not in
this general statement. Surely removing or adding one single checkbox to
an existing dialog doesn't need a screenshot, but that doesn't mean that
the new, multi-dialog wizard should not have those. (see other post)

>   + [ unless vital to illuminate some point ]

Ok. But I guess you have a different perception of "vital". "Obvious" is
a rather subjective term...

> [agree to the other points, especially this one:]
>   * ensure that the spec. process is filled with shortish 
> timeouts to handle people that don't respond
> [...]

ciao
Christian
-- 
NP: Helmet - Unsung

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] register component 'scsolver.uno.so' failed

[Kohei Yoshida]

Hi Mikaël,

On 10/31/06, Mikaël De Bie <[EMAIL PROTECTED]> wrote:


The add-in I want to compile is the scsolver created by Kohei Yoshida
(http://kohei.us/ooo/solver/)
I've downloaded the scsolver sources from
http://cvs.gnome.org/viewcvs/ooo-build/scratch/scsolver/


As I mentioned in my reply to the very first email you sent me
(privately), my scsolver component currently uses non-UNO API.  So,
unless you've gone through my code to remove those calls to non-UNO
API for localizing strings, it won't be compiled into a pure UNO
component (thus the registration may fail).

Have you gone through my code and made all necessary modification to
UNO-nify my code?

Kohei

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] How to store sensitive information

[Christian Lohmaier]

Hi Robert,

On Mon, Oct 30, 2006 at 02:46:58PM +0100, Robert Vojta wrote:
> [...] 
> this is misapprehension ... finally not for users@openoffice.org ...
> 
> Do you know Gnome Keyring Manager? Or do you know Firefox Password
> Manager? Looks like not. I would like to do modify OpenOffice.org in
> this way ...

Why not instead making OOo aware/a client of gnome-keyring manager?

> [...]

ciao
Christian
-- 
NP: Helmet - Unsung

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] Student seeks participants for thesis survey about Open Source

[Florian Effenberger]

Hello,

I have received a request from a student, who seeks for participants in
his thesis survey about Open Source. I originally posted that on 
discuss@, but feedback was not very high, so I thought reposting it to 
dev@ might get more attention. :-)


> Dear members of OpenOffice.org,

> my name is Tobias Brenner and at the moment I'm writing my
> dissertation at the Institute of Sociology at the University of
> Munich. The topic of the dissertation is "Open Source Software" and I
> decided to choose OpenOffice.org for my examination. But I can only
> do this with your help. You would do me a great favour, if you could
> fill out this short questionary for me. This will take you only a few
> minutes. Link: http://www.open-source-survey.com/Umfrage/index.html

I wanted to pass this on to you and would be happy if we could find some
participants here. :-)

Thanks!
Florian

--
## Florian Effenberger
## Marketing/Öffentlichkeitsarbeit/Presse
## OpenOffice.org - http://de.openoffice.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Christian Lohmaier]

Hi *,

On Mon, Oct 30, 2006 at 11:17:36PM -0500, Kohei Yoshida wrote:
> On 10/30/06, Nikolai Pretzell <[EMAIL PROTECTED]> wrote:
> >Kohei Yoshida schrieb:
> >> On 10/27/06, Nikolai Pretzell <[EMAIL PROTECTED]> wrote:
> >>> Kohei Yoshida schrieb:
> [...] 
> But I wouldn't want to try spec'ing every minute detail of a feature,
> and keep it in sync with the code all the time. 

Nobody requests that. And this is not reasonable either. The code
doesn't matter for the spec anyway. It is the User-interaction part that
really matters.

> And that, to me, is
> what the specification project is requiring us to do (well, probably
> not "all the time", but close).

Specify what the code should do, not how exactly the code does it.
In the quickstarter example, I would have expected that the spec would
tell that a link is created in a directory that is the equivalent of the
autostart folder on windows (see freedesktop-spec). I'm not interested
on how the code does that, but this tiny bit of information would
already explain a lot.

> There are mainly two complaints I have with the current specification 
> project:
> 
> 1) It asks for way too many details, especially in the UI design
> section.  It's not too bad if the feature involves only one
> control/widget change.  But once the change involves three or more
> dialogs, with each dialog having an average of 7 to 8 controls, it
> starts to become a real pain in the rear, [...]

I disagree. Esp. when the UI is changed significantly the UI-mockups are
necessary. Both for finding flaws in the proposed design as well as for
documentation.
I'm sure nobody expects you to do a pixel-accurate mockup, but again the
user-interaction part should be clearly visualized.

Making a picture of a mockup is far easier than explaining a dialog in
text only. One picture tells more than a thousand words.

> 2) The target audience is not very clear.  Thanks to this thread,
> though, now I'm beginning to see who the specification documents are
> intended for (mostly for QA, right?). 

QA. documentation and those who want to give feedback... And of course
the developers that implement the feature (if not "retrofitted") - but
again here no real code design, but from a user-interaction perspective.
What does the user need to do, and what is the result when a user does
this or that.

And don't forget the answer to "Why should OOo behave like that in the
first place?" (read: User scenarios or comparison with other apps - and
read as well: depends of course of the impact of the feature)

In the example of the quickstart spec: I would have expected an short
description what happens when the user uses KDE, what happens when the
user uses a gtk based system (xfce) but not GNOME, how the user
activates the feature, how the user deactivates the feature, whether it
can be enabled/disabled by an admin (if so: how)

If the spec would not be retrofitted, then the detailed specification
part could list implementation details/proposals, such as how the
quickstart works (keeping an "invisible instance", continuously catting
OOo's libraries to /dev/null or whatever).

> [...] 
> >"Responsible" does not mean he has to do the actual work. But the
> >developer is the one who after all sets a task to fixed. He cannot do
> >this, if the spec is not in sync, because either the implementation is
> >buggy or the spec. In the latter case the QA cannot test (it verifies
> >against the spec, what else?). And a feature that cannot be verified is
> >not yet done.
> 
> I don't doubt that this is how you guys do your work, and I have
> nothing against it.
> 

And if the way the stuff gets activated (i.e. the option moves to a
different tabpage or something), then I'd expect the spec to be updated
accordingly. (before that move is actually performed)

> But doesn't an externally contributed feature come pretty much when
> it's complete (or nearly so)?  If so, then a spec is written after the
> fact, which means the spec can be easily retrofitted to be "in sync
> with the code". 

Doesn't matter in this case.

> In this scenario, a spec cannot be used to verify the
> implementation, because the implementation is done first.

Well, you can still see whether what you coded actually is what you
thought it would do (i.e. what you coded is what you wrote down in the
spec). It is true that you miss the "find errors in the planning phase"
(but again I don't think you start coding without having planned the
changed first, so no gain/no loss)

> You can do
> the opposite, perhaps, to verify the spec against the implementation.
> I did that for my first specification (natural sort), and I'll
> probably do it for my second spec (solver), too.

See above. Not really a problem as long as you did not just typed ahead
your code..

> So, my workflow seems different from yours, which itself may be a
> problem when being involved in this project.  But that's how I write
> my code in my free time.

Still - then you know what your code does and 

Re: [dev] About contributing...

[Kay Ramme - Sun Germany - Hamburg]

Hi FireS,

FireS BurnsmuP wrote:
I am not the greatest of programmers, but that is my area of relative 
expertise.


I would like to suggest that (the collective of developers) try to make 
the program and its components more efficient, i.e. it would be nice if 
the suite were much smaller. This is the sole reason I previously chose 
MS Office over OOo.

Could you be more concrete and give some examples?


If there are problems with this, then I'm sorry I bothered you. If it 
would be possible to size down everything, I would like to try and help.

Lets identify first what disturbs you most ...


RSVP

~ FireS

Kay

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] register component 'scsolver.uno.so' failed

[Kohei Yoshida]

On 10/31/06, Mikaël De Bie <[EMAIL PROTECTED]> wrote:

Hi Kohei,

Kohei Yoshida a écrit :
> Hi Mikaël,
>
> On 10/31/06, Mikaël De Bie <[EMAIL PROTECTED]> wrote:
>
>> The add-in I want to compile is the scsolver created by Kohei Yoshida
>> (http://kohei.us/ooo/solver/)
>> I've downloaded the scsolver sources from
>> http://cvs.gnome.org/viewcvs/ooo-build/scratch/scsolver/
>
> As I mentioned in my reply to the very first email you sent me
> (privately), my scsolver component currently uses non-UNO API.  So,
> unless you've gone through my code to remove those calls to non-UNO
> API for localizing strings, it won't be compiled into a pure UNO
> component (thus the registration may fail).
>
> Have you gone through my code and made all necessary modification to
> UNO-nify my code?
>

I didn't do that... Is it the way you 've created your scsolver.uno.zip ?


No, that one is a pure UNO component.  But notice that I haven't made
any release in the past few months, simply because I've introduced
non-UNO API in my code, which made it rather non-trivial to release a
new UNO component.

It could be done, but it would require some work.  It would be a bit
of work even for me - the author of the code, so I imagine it would be
a lot more work for you.

Kohei

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] register component 'scsolver.uno.so' failed

[Mikaël De Bie]

Hi,

I'm trying to build a add-in for openoffice-calc, but I get an error 
while compiling.


Here's my configuration :
PC : laptop Toshiba satellite P4
OS : Linux - Ubuntu 6.06 LTS (Dapper Drake)
gcc : I used gcc-3.4.1 (the one used to compile the version I've installed)

The OpenOffice installed is 2.0.3 downloaded from
http://oootranslation.services.openoffice.org/pub/OpenOffice.org/2.0.3rc7/

I've downloaded the source of openoffice2.0.3 from
http://oootranslation.services.openoffice.org/pub/OpenOffice.org/2.0.3rc7/OOo_2.0.3_LinuxIntel_solver.tar.gz


The add-in I want to compile is the scsolver created by Kohei Yoshida 
(http://kohei.us/ooo/solver/)
I've downloaded the scsolver sources from 
http://cvs.gnome.org/viewcvs/ooo-build/scratch/scsolver/


Here is the error I get :

../../../../solver/680/unxlngi6.pro/bin/regcomp -register -r 
scsolver.uno.rdb -c scsolver.uno.so


register component 'scsolver.uno.so' in registry 'scsolver.uno.rdb' failed!
error (CannotRegisterImplementationException): loading component library
failed: scsolver.uno.so


The trace.log of the command
"strace -f -F -o /tmp/trace.log 
../../../../solver/680/unxlngi6.pro/bin/regcomp -register -r 
scsolver.uno.rdb -c scsolver.uno.so"
is available at this url : 
http://ece.fsa.ucl.ac.be/mdebie/work/ooo/trace.log


The complete output of the make command can be found at this url :
http://ece.fsa.ucl.ac.be/mdebie/work/ooo/make_output

I've also run the command ldd -r scsolover.uno.so, the output follows at 
the end of the mail.


Can anybody help or indicate me who to contact to be able to debugg 
regcomp or the library scsolver.uno.so to indentify the problem.


Thank you for your attention,

Mikaël

ldd -r scsolover.uno.so gives :

[EMAIL PROTECTED]:~/ooo-build/scratch/scsolver/workben/addon_pkg/obj$ ldd 
-r scsolver.uno.so

undefined symbol: dlclose   (./scsolver.uno.so)
undefined symbol: dlopen(./scsolver.uno.so)
undefined symbol: dlsym (./scsolver.uno.so)
undefined symbol: colamd_recommended(./scsolver.uno.so)
undefined symbol: colamd_set_defaults   (./scsolver.uno.so)
undefined symbol: colamd(./scsolver.uno.so)
undefined symbol: symamd(./scsolver.uno.so)
undefined symbol: _ZN4cppu11OWeakObject12queryAdapterEv (./scsolver.uno.so)
undefined symbol: _ZTIN4cppu11OWeakObjectE  (./scsolver.uno.so)
undefined symbol: 
_ZN4cppu28createSingleComponentFactoryEPFN3com3sun4star3uno9ReferenceINS3_10XInterfaceEEERKNS4_INS3_17XComponentContextRKN3rtl8OUStringERKNS3_8SequenceISE_EEP16_rtl_ModuleCount 
(./scsolver.uno.so)

undefined symbol: uno_type_any_assign   (./scsolver.uno.so)
undefined symbol: 
_ZN4cppu26component_getFactoryHelperEPKcPvS2_PKNS_19ImplementationEntryE  
(./scsolver.uno.so)
undefined symbol: 
_ZN6ResMgr12CreateResMgrEPKcN3com3sun4star4lang6LocaleE   
(./scsolver.uno.so)

undefined symbol: _ZN4cppu11OWeakObject7acquireEv   (./scsolver.uno.so)
undefined symbol: rtl_string2UString(./scsolver.uno.so)
undefined symbol: typelib_static_type_getByTypeClass(./scsolver.uno.so)
undefined symbol: osl_getGlobalMutex(./scsolver.uno.so)
undefined symbol: rtl_ustr_ascii_compare_WithLength (./scsolver.uno.so)
undefined symbol: osl_incrementInterlockedCount (./scsolver.uno.so)
undefined symbol: osl_releaseMutex  (./scsolver.uno.so)
undefined symbol: _ZN8scsolver15NlpModelBuilderC1EPNS_10SolverImplE 
(./scsolver.uno.so)
undefined symbol: 
_ZN8scsolver15NlpModelBuilder26setObjectiveFormulaAddressEN3com3sun4star5table11CellAddressE  
(./scsolver.uno.so)
undefined symbol: 
_ZN8scsolver12OptionDialog12setModelTypeENS_12OptModelTypeE   
(./scsolver.uno.so)
undefined symbol: _ZN4cppu23WeakImplHelper_getTypesEPNS_10class_dataE   
(./scsolver.uno.so)

undefined symbol: rtl_string_newFromStr (./scsolver.uno.so)
undefined symbol: _ZN6ResMgrD1Ev(./scsolver.uno.so)
undefined symbol: rtl_ustr_toDouble (./scsolver.uno.so)
undefined symbol: rtl_string_newFromStr_WithLength  (./scsolver.uno.so)
undefined symbol: 
_ZN4cppu25component_writeInfoHelperEPvS0_PKNS_19ImplementationEntryE  
(./scsolver.uno.so)

undefined symbol: rtl_uString_newFromAscii  (./scsolver.uno.so)
undefined symbol: 
_ZN4cppu30ImplHelper_getImplementationIdEPNS_10class_dataE
(./scsolver.uno.so)

undefined symbol: rtl_string_newConcat  (./scsolver.uno.so)
undefined symbol: _ZNK8scsolver10OptionData12getModelTypeEv 
(./scsolver.uno.so)

undefined symbol: _ZN8scsolver5TimerC1Ed(./scsolver.uno.so)
undefined symbol: uno_type_destructData (./scsolver.uno.so)
undefined symbol: uno_type_sequence_reference2One   (./scsolver.uno.so)
undefined symbol: uno_type_sequence_construct   (./scsolver.uno.so)
undefi

Re: [dev] Specification Process Possibilities ... - unit testing

[Mathias Bauer]

Michael Meeks wrote:

> Hi Mathias,
> 
>   Once again thank you for your thought provoking mail.
> 
> On Mon, 2006-10-30 at 23:57 +0100, Mathias Bauer wrote:
>> You mix up some things here. Nobody said that we need a spec for each
>> and every "tiny ergonomic fix". We need them for new features - e.g. a
>> quickstarter on Linux. :-P
> 
>   I refer you to the Sun rubric ** emphasis added.
> 
> http://wiki.services.openoffice.org/wiki/Category:Specification
> 
>   "I Want to Change Something in OpenOffice.org - Do I Have to
>Write a Software Specification? 
>**In general the answer is YES**. This applies to:
>Features, Enhancements, **Defects**"

You should quote the whole text: ;-)

#  Defects requiring the following type of changes:

* Behavioral changes of the UI (e.g. changing a dialog from modal to
modeless)
* Visual changes of the UI (e.g. changing the icon size, the splash
screen, the about box)
* Configuration changes (e.g. changing application defaults such as
Spellchecking ON/OFF)

This looks different. There is no general rule that a bugfix for a
defect needs a spec. My personal opinion is that this list is not very
specific and leaves a lot of room for interpretation. This is per se a
neutral fact - neither positive nor negative. The negative touch comes
from the implemented practice - that's what needs to be improved if you
have negative feelings about it.

Besides that you should consider that nowadays a spec can be just a very
short snippet of text that describes the changes in understandable and
hopefully unambiguous terms. That's all. I know that earlier specs where
a "little bit" oversized but IMHO that has changed now.

And if people are afraid of creating a document from a template -
Christian already wrote that we can place specs in a wiki. If that might
help I'm all for having this pretty fast. I hope you agree that it is a
good thing that the necessary things are written down at least somewhere
where they can be found easily.

>   Now, of course we could explicitly exclude more things from this, which
> would be good - but AFAICS - at least as of now, each tiny ergonomic
> change requires -at-least- a round-trip to the team lead.

Where is the problem with a contact to the project lead? IMHO this could
be a very important step to a better support that you demanded. If a
project lead knew about a particular patch or CWS that is in the works
he could help much easier and better in case something is stuck. He
could also help to form an iTeam early and make sure that the necessary
work of all participants gets aligned and planned. Work can go like
clockwork if you do it this way but can take much more time if you work
on your own and later ask people for help when you are finished. Working
in parallel shortens the time you need to get something integrated.

> I hack on a module I like to try and find these tests, I poke in
> 'workben' and I see very frequently stale/un-buildable/un-runable code,
> then I poke in qa/ and eg. in configmgr/qa/unoapi I see a makefile.mk I
> 'dmake' that, something happens and it barfs:
> 
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/openoffice/Runner
> dmake:  Error code 1, while making 'ALLTAR'
> 
>   it appears broken out of the box.
> 
>   I would -Love- to have a good, standardised unit testing framework in
> place to add tests to, and let us re-factor code more aggressively with
> confidence. However - I just don't see anything here.

I think you already found some of them. I don't know why the OOo Runner
doesn't work in your environment. Would you mind to file an issue and
assign it to "cn"?

>> We are currently investigating how we can get faster tests, one
>> direction we are looking into is avoiding or at least reducing the
>> idle/sleeping times.
> 
>   Yep - of course, understanding why these idle times are there would be
> good I guess.

Of course that's the first step. :-)
Our plan is to start with this pretty soon (in 1 or 2 weeks when the
developer of the testtool is back from vacation).

>>  Other ideas are welcome. My very personal opinion
>> is that we should have more API (code) based tests and less GUI testtool
>> based ones but I know that there are other opinions. Must be discussed.
> 
>   Well; of course from a 'community' perspective - I'm well up for adding
> in-source, in-CWS, standardized, fast unit-tests. eg. reading the calc
> 'R1C1' work recently, I was itching to write a test-suite, that would
> simply exercise this piece of the calc code & parse 100 formulae of
> varying complexity and validate that the results were correct.
> 
>   Unfortunately it's -really- difficult to do that.

That's the kind of input we should collect. Not in this thread of
course, but somewhere else. I've put it on my list and will come back later.

>> There's nothing wrong with doing unit and API tests in Java.
> 
>   As long as they are easy to run with som

Re: [dev] register component 'scsolver.uno.so' failed

[Mikaël De Bie]

Hi Kohei,

Kohei Yoshida a écrit :

Hi Mikaël,

On 10/31/06, Mikaël De Bie <[EMAIL PROTECTED]> wrote:


The add-in I want to compile is the scsolver created by Kohei Yoshida
(http://kohei.us/ooo/solver/)
I've downloaded the scsolver sources from
http://cvs.gnome.org/viewcvs/ooo-build/scratch/scsolver/


As I mentioned in my reply to the very first email you sent me
(privately), my scsolver component currently uses non-UNO API.  So,
unless you've gone through my code to remove those calls to non-UNO
API for localizing strings, it won't be compiled into a pure UNO
component (thus the registration may fail).

Have you gone through my code and made all necessary modification to
UNO-nify my code?



I didn't do that... Is it the way you 've created your scsolver.uno.zip ?


Kohei

-
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] Specifications and Release Notes = Re: [dev] Specification Process Possibilities ... what about a wiki?

[Thorsten Behrens]

Bernd Eilers <[EMAIL PROTECTED]> writes:

> We do have a semi-automated process to generate Release Notes. This
> takes advantage of the OpenOffice Document file format and a standard
> template being used for the specification documents. Information from
> specifications documents is extracted via XSLT and a "What´s new
> guide" HTML page is created which is the basis for the Release Notes.
> 
> See for example: http://development.openoffice.org/releases/2.0.4rc3.html
> 
Hm, looking at this page, I'd say automatic processing could have its
drawbacks (looking at the abstracts for issue 62484). ;-)

> 1.) After work is finished in the Wiki and at a give time just before
> the release, let´s say at UI - Freeze or something like that content
> from the Wiki must be moved to a .odt document.
> 
> 2.) We need to work on the process to create the document for the
> Release Notes and create a new feature there to be able to extract
> information from the WiKi and we also need to set up some kind of
> template and corresponding rules on how specs in the Wiki do have too
> look to be able to find the information that is going to be extracted
> for the Release Notes.
> 
Well, I don't see any special formatting used in the spec abstract
(that's what I suppose is extracted from the template document). So,
why not use the feature mail to provide this abstract? We've a HTML
formular for that, anyway.

Cheers,

-- 

Thorsten

If you're not failing some of the time, you're not trying hard enough.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Eike Rathke]

Hi Thorsten,

On Tuesday, 2006-10-31 12:06:28 +0100, Thorsten Behrens wrote:

> But the difference is that there's no request from high-above to
> implement a certain feature, and no dedicated time in user experience
> to roll out a detailed UI spec beforehand.

Specs aren't only about UI, they're also about behavior of a feature.
Behavior of a feature, if not obvious, is something that must be agreed
upon. We do have examples of started development, patches were sent in,
but there wasn't even an agreement on how the feature should really
work, discussion in the issue continues, more patches attached, but
still no agreement. At the end this leads to nowhere because you won't
get someone from UserEx to even read the issue anymore, because the 42
comments to the issue are not digestible for anyone not involved from
the beginning.

One more +1 for a wiki for specification.

> People just start coding. So the example of car production might suit
> the way Sun-internal features are developed,

Nah, comparing software development with car manufacturing always has
a bit ... well ... some taste of helplessness..

> but it doesn't fit the
> community. Community specs are nearly always after-the-fact
> documentation of the implemented feature, thus, the argument that
> specs save rework costs just doesn't apply here (simply - because all
> the work has been done already, when the spec is written).
> 
> I don't question the need for _some_ documentation - QA and especially
> help authors need a way to test and describe the things that newly
> enter the product. But I do question the very strict requirements the
> spec process puts on community contributions, and I second Michael's
> statement that most of those requirements (in their current
> installment of the spec process) don't add much value to the
> production line (mind that - I'm talking about community contributions
> here). 

While I completely agree on the entire paragraph above,

> In the end, specs serve multiple purposes Sun-internally:
> 
>  - have a feature well thought-out beforehand
>  - have UI specified by experts (user experience)
>  - have strings reviewed by experts
>  - have feature documentation for QA
>  - have feature documentation for help authors
>  - ...etc. I've probably forgot a few more items.
> 
> The first three items should not be required for non-Sun
> contributions, because they just don't affect us

I don't agree on this statement. It affects us, and with "us" I'm
referring the entire OOo project, not only Sun. We don't need the "Big
Design Up Front" (BDUF) picture, especially not in its waterfall model
sense, but maybe "Enough Design Up Front" (EDUF), as was also noted by
some Agile/XP enthusiasts [1][2][3] when Joel (on Software) came up with
his "love BDUF" [4]. We do need _some_ picture of a feature. A picture
we may as well add to, correct, recolour, overpaint, or even tear apart
after some cycles of evolution. So I'd like to replace your point you
say we don't need to

>  - have a feature well thought-out beforehand

with

- have a feature _enough_ thought-out beforehand

Again, a wiki may be a perfect place for this.


On to the next:

>  - have UI specified by experts (user experience)

This affects us. UI has to be consistent, functional, and should guide
users like most users expect. This is what UserEx should have an eye on.
Much of software evaluation (in organizations, governments, companies,
by journalists, ...) happens on the UI level. If that has quirks it will
give us OOo bad reputation. I don't say we need UserEx for each and
every single check box, but sometimes we may even need them to say ok to
where the checkbox is placed.

>  - have strings reviewed by experts

Yes and no. It is vital for a good UI to name identical things
identical, and different things different throughout the entire product.
You need at least to check with a glossary now and then, or sometimes
need a hint to phrase something different. UserEx can provide those
hints.

However, far more important than a string review, IMHO, would be to drop
German as a developer provided second source localization. Let's get rid
of that. There's no sense in it other than most Hamburg engineers being
native German speakers. Two major drawbacks with the German source
localization are:

  1. non-Hamburg contributors most certainly can't provide it.
  2. If they can manage somehow, it doesn't necessarily mean it's a good
 localization, bable fish and the like..
 - This localization will stick until issues are submitted. AFAIK
   there is no following localization process.


> - if a CWS needs
> rework because of them, it's the burden of the community dev. But they
> should be free to choose their way, and not be pressed into a mold,
> that has been designed for a Sun-employed OOo developer.

Seconded, but "if a CWS needs rework because of them" effectively means
the spec/UI/string things may be done any time, maybe even after the CWS
was set read

Re: [dev] register component 'scsolver.uno.so' failed

[Mikaël De Bie]

Kohei Yoshida a écrit :

On 10/31/06, Mikaël De Bie <[EMAIL PROTECTED]> wrote:

Hi Kohei,

Kohei Yoshida a écrit :
> Hi Mikaël,
>
> On 10/31/06, Mikaël De Bie <[EMAIL PROTECTED]> wrote:
>
>> The add-in I want to compile is the scsolver created by Kohei Yoshida
>> (http://kohei.us/ooo/solver/)
>> I've downloaded the scsolver sources from
>> http://cvs.gnome.org/viewcvs/ooo-build/scratch/scsolver/
>
> As I mentioned in my reply to the very first email you sent me
> (privately), my scsolver component currently uses non-UNO API.  So,
> unless you've gone through my code to remove those calls to non-UNO
> API for localizing strings, it won't be compiled into a pure UNO
> component (thus the registration may fail).
>
> Have you gone through my code and made all necessary modification to
> UNO-nify my code?
>

I didn't do that... Is it the way you 've created your 
scsolver.uno.zip ?


No, that one is a pure UNO component.  But notice that I haven't made
any release in the past few months, simply because I've introduced
non-UNO API in my code, which made it rather non-trivial to release a
new UNO component.

It could be done, but it would require some work.  It would be a bit
of work even for me - the author of the code, so I imagine it would be
a lot more work for you.

Kohei


I'll report these informations to my advisors...
Thanks a lot for all Kohei,

Mikaël

-
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] Specifications and Release Notes = Re: [dev] Specification Process Possibilities ... what about a wiki?

[Eike Rathke]

Hi Bernd,

On Tuesday, 2006-10-31 12:41:25 +0100, Bernd Eilers wrote:

> We do have a semi-automated process to generate Release Notes. This 
> takes advantage of the OpenOffice Document file format and a standard 
> template being used for the specification documents. Information from 
> specifications documents is extracted via XSLT and a "What´s new guide" 
> HTML page is created which is the basis for the Release Notes.
> 
> See for example: http://development.openoffice.org/releases/2.0.4rc3.html

Not all there is generated from specs, there are also
features/enhancements that don't have a spec and were announced via EIS'
External Feature Announcement. This should always be possible.

Also a conversion from wiki to .odt or any other format. e.g. the format
EIS understands, should be feasible, given the right transformation.
Wiki markup could be used to identify the abstract sections.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to this [EMAIL PROTECTED] account, which I use 
for
 mailing lists only and don't read from outside Sun. Thanks.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] The QuickStarter Spec.

[Mathias Bauer]

Michael Meeks wrote:

> Thankfully the code works  :-)  But the very concept of rampant
> duplication of state all over the place is at root broken IMHO. Having
> unnecessary screenshots, duplicating bi-lingual strings etc. adds
> [AFAICS] nothing at all to an existing impl, but a huge amount of pain
> in terms of re-synchronising things.

I don't want to argue against this, just a question: how should the QA
find out wether the strings they find in the product are the right ones
that others wanted to have there? I don't get how this works.

>   An asynchronous work-flow, whereby an Engineer can implement a
> feature / fix, knock up a quick wiki page describing it, commit it to a
> CWS, assign it to QA, mail the dev@ui.openoffice.org list about it, and
> get on with his next task would be ideal. Of course, U.E. could poke at
> the wiki/issue (if they were interested & had time), otherwise it would
> just proceed, QA likewise could ask questions / extend the wiki page
> describing the change (if at all necessary), otherwise they could focus
> on the real grist of the implementation.
Interesting approach. I think we should check this against the goals
behind the spec idea.

>   So - I'm not against writing -something- down, but lets make it
> absolutely minimal. Matthias Heutsch had a nice flow based on the
> Solaris process that included a streamlined fast track for
> 'uncontroversial' changes; codifying that (and a load of timeouts for
> comments) would substantially improve things.
As we learned the hard way this great idea is pretty fast understood by
developers, but obviously not well received by QA people. Apparently the
degree of being "uncontroversial" for a particular change depends on the
previous knowledge and the skills of the participants in the dispute.
That's the dilemma.

I remember the meeting where we discussed this idea and we all thought
that this a great thing. Perhaps it's time to advertize it more
aggressively. It won't help you with your general "spec phobia" though.

Ciao,
Mathias

-- 
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Mathias Bauer]

Michael Meeks wrote:

> Hi Mathias,
> 
>   So, while broadly agreeing with most of what you say:
> 
> On Mon, 2006-10-30 at 08:53 +0100, Mathias Bauer wrote:
>> Without the spec the QA wouldn't be able to even find bugs in
>> many cases (with the exception of obvious ones).
> 
>   We hear this a lot. And, now we know that specifications are frequently
> inaccurate, buggy / out of sync with the code anyway. So - I'm having
> problems understanding what -exactly- QA need here. It'd help to have 10
> representative examples of times when a specification has actually
> helped distinguish between bugs & features, and what was done with that
> information [ writing tests / whatever ].
Well, did I say our specs are perfect? Of course developers make errors
and so do spec writers. But should we give up writing specs because of
this? Should we stop coding also because our code contains bugs? My
understanding is that our goal is to improve over time and serve the
goals we attach to our activities better. And as Frank stated we already
learned something from our old specs and this is reflected in the new
spec template. And it is much more "light weight".

>   Perhaps with some good examples to analyse here, it'd be easier to
> understand some of the rational. 
Fair enough. I will forward your request to our QA (in case they stopped
reading here). OTOH we already know some examples where the absence of a
spec definitely caused problems (one of them started this thread).

Ciao,
Mathias

-- 
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Mathias Bauer]

Kohei Yoshida wrote:

> 2) The target audience is not very clear.  Thanks to this thread,
> though, now I'm beginning to see who the specification documents are
> intended for (mostly for QA, right?).  
Not exclusively. Also developers will benefit from a spec if they have
to refactor/change/extend the code later on. Believe me, I can't count
the occasions any more where I would have been glad to have a
specification for a feature that needed a larger rework. Without a spec
we very often are standing in the dark and hope to be lucky not to
damage too much things just because we just don't know about their
existence. If you contribute features to a project you should see that
you add something useful to the project but also a legacy for the code
owner who has to maintain your code in the future. Code alone isn't
documentation enough, even for developers.

Just a thought worth another 2ct, IMHO.

Ciao,
Mathias
-- 
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where to find source code for X,,,

[Jim Watson]

On 01/11/2006, at 12:52 AM, CPHennessy wrote:


On Fri October 27 2006 14:03, Enno Fennema wrote:

I have two problems. Firstly, I can save a spreadsheet on a USB stick
when using a new name so permissions appear to be ok. I can also  
later
load that sheet from the USB stick but when I try to save it I get  
error
message "Cannot create backup copy!!!" and nothing saved. I can  
save the

spreadsheet with SaveAs under a new name.


I can sometimes reproduce this behaviour on a iMac using a network  
folder to another iMac, I have not narrowed down the exact  
circumstances, I suspect it relates to using the File-Recent  
Documents after the volume has been re-mounted?

Enno - are you using the File-Recent Documents to open the files?

jim

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where to find source code for X,,,

[Enno Fennema]

Will dig a bit further with strace. Sounds good idea. Thanks CPH.

Jim,
No, I did not use File-Recent Documents although my files obviously do 
appear there


Enno



On 01/11/2006, at 12:52 AM, CPHennessy wrote:

... Try strace


Jim Watson wrote:


...  are you using the File-Recent Documents to open the files?

jim



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Thorsten Behrens]

Eike Rathke <[EMAIL PROTECTED]> writes:

> Specs aren't only about UI, they're also about behavior of a feature.
> Behavior of a feature, if not obvious, is something that must be agreed
> upon. We do have examples of started development, patches were sent in,
> but there wasn't even an agreement on how the feature should really
> work, discussion in the issue continues, more patches attached, but
> still no agreement.
>
Hi Eike,

how would a spec help (a community dev) in reaching such an agreement?

> > In the end, specs serve multiple purposes Sun-internally:
> > 
> >  - have a feature well thought-out beforehand
> >  - have UI specified by experts (user experience)
> >  - have strings reviewed by experts
> >  - have feature documentation for QA
> >  - have feature documentation for help authors
> >  - ...etc. I've probably forgot a few more items.
> > 
> > The first three items should not be required for non-Sun
> > contributions, because they just don't affect us
> 
> I don't agree on this statement. It affects us, and with "us" I'm
> referring the entire OOo project, not only Sun. We don't need the "Big
> Design Up Front" (BDUF) picture, especially not in its waterfall model
> sense, but maybe "Enough Design Up Front" (EDUF), as was also noted by
> some Agile/XP enthusiasts [1][2][3] when Joel (on Software) came up with
> his "love BDUF" [4]. We do need _some_ picture of a feature. A picture
> we may as well add to, correct, recolour, overpaint, or even tear apart
> after some cycles of evolution.
>
I wouldn't say that we need this picture, in a sense that we need to
require it from everyone. I tried to split the things that are
essential for others to digest/evaluate/QA a contribution, from the
ones that 'just' have the potential to make life easier/less wasteful
for a developer. Those should be suggestions, not requirements.

> On to the next:
> 
> >  - have UI specified by experts (user experience)
> 
> This affects us. UI has to be consistent, functional, and should guide
> users like most users expect. This is what UserEx should have an eye on.
> Much of software evaluation (in organizations, governments, companies,
> by journalists, ...) happens on the UI level. If that has quirks it will
> give us OOo bad reputation. I don't say we need UserEx for each and
> every single check box, but sometimes we may even need them to say ok to
> where the checkbox is placed.
> 
Hm - I think this really depends a lot on how much UI is involved,
whether there's prior art (either inside or outside OOo), and how much
code is tied to the actual UI. Having explicit UI guidelines/design
rules would most probably allow the average developer to correctly
place a checkbox (in as much as control placement will ever be
'correct' - I've seen UI experts change their mind about such things
in a relatively short timeframe).

It naturally pays off to have a small group of wizards sign off UI and
strings, in terms of cohesiveness, terminology, and ease of use. But
it obviously doesn't scale up currently.

I'd guess much of the aforementioned problems will be non-issues, once
there's a GUI editor available - because then, adapting UI quickly
(possibly by user experience), and even after-the-fact (like help
authoring) is possible.

> However, far more important than a string review, IMHO, would be to drop
> German as a developer provided second source localization. Let's get rid
> of that.
>
Aww, of course. I thought we already did that. :-/

> Anyway, all this, work done in a CWS by a community developer, leaves
> out the frequent situation where a patch arrives for some feature or
> enhancement attached to an issue and eagerly awaits to get applied,
> which for smaller enhancements most times happens in a CWS a Sun
> developer has open anyway, and only for larger features a CWS on its own
> is created. Whose burden is it then to provide necessary spec and
> involve UE/QA/DOC?
> 
Ours (the Sun devs/code owners). But I wouldn't see it as a burden
(most of the time), more like a mediating/facilitating role. In the
best of all cases, patch contributor and QA/DOC just need to be
connected. In other cases, more work might be necessary, but since the
patch gets thorough code review anyway, information about changed/new
behaviour should be a by-product. If UE has their say, admittedly,
more work is necessary. But as pointed out above, the root cause of
that problem is IMO not fixable with whatever spec process we come up
with.

> Btw I think a template does ease things a lot, be it as a document or
> a wiki template, because it guides the spec author and she doesn't have
> to pull some prosa out of her head.
> 
I'm indifferent about that. Maybe I'm biased by the past template's
narrow scope (specialized towards UI features).

> I think much of the hurdle are communication (habit) problems instead of
> a specification (template) problem. If we agree that we need some
> spec/doc and need to collaborate, then it doesn't matter if one o

Re: [dev] How to store sensitive information

[Mathias Bauer]

Robert Vojta wrote:

> Hallo,
> 
> does OpenOffice.org provide a framework for storing sensitive
> information? Like passwords? Anything like Gnome Keyring Manager, ...?

We have a password container that can collect passwords at runtime and
keeps them. Currently we don't store passwords persistently (only in
memory), though the implementation would be there. It uses a
configuration backend and the passwords can be "sealed" with a master
password.

The whole implementation is encapsulated into a UNO service and if
somebody wanted we could show him the ropes and discuss possible ways to
integrate with other "backends".

Best regards,
Mathias
-- 
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] How to store sensitive information

[Mathias Bauer]

Robert Vojta wrote:

> Hallo,
> 
>> That depends what you want to do. OOo can set a password on a document when
>> you save through File -> Save As. Bear in mind that the encryption is strong,
>> so if you lose the password you lose the data. It is not practical to try to
>> break it with current technology, AIUI. There is only type of encryption
>> possible defined by OOo now.
> 
> this is misapprehension ... finally not for users@openoffice.org ...
> 
> Do you know Gnome Keyring Manager? Or do you know Firefox Password
> Manager? Looks like not. I would like to do modify OpenOffice.org in
> this way ...
> 
> - extend WebDAV support and modify file picker,
> - provide password management for WebDAV (and others) accounts

I forgot to mention: our password manager is used currently exactly for
these purposes (IIRC). So if you open a WebDAV folder, enter your
password and later on open the same folder again (without closing Ooo in
between) the password should be remembered.

Ciao,
Mathias

-- 
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] Re: [framework-dev] [Fwd: [installation-dev] Updating to OOo 2.1 & language packs]

[Mathias Bauer]

Oliver Braun wrote:

> with the move to the new numbering schema also the default installation 
> directory changes from "OpenOffice.org 2.0" to "OpenOffice.org 2.1" 
> resp. from "openoffice.org2.0" to "openoffice.org2.1".

Perhaps we should stop using directory names containing version numbers?
Firefox e.g. always installs into the same directory (on Windows it's
"program files\Mozilla Firefox"). What's the point in keeping the
version numbers in the directory names? Would be interesting to ask the
Firefox developers if they experienced any user problems or complaints.

Besides that:

> Assuming that users might have language packs installed in their OOs 
> 2.0.x, the result when updating will be platform dependant:
> 
> * on Windows, the installer will detect the existing 2.0.4 and propose 
> "OpenOffice.org 2.0" as destination directory instead => language packs 
> still there, but potentially incompatible (might even lead to crashes).
> 
> * on Unix, the default directory "openoffice.org2.1" will be used, 
> resulting in a naked OOo 2.1 with the language packs still present in 
> "openoffice.org2.0".
> 
> Shouldn't we issue a warning on Windows and install to "OpenOffice.org 
> 2.1" by default as on Unix ? Users willing to take the risk might still 
> choose the "OpenOffice.org 2.0" manually.

This would be acceptable as a stop gap solution. In alignment with my
idea from above and also as a clearer approach: can we find a way to
disable/deinstall language packs?

Ciao,
Mathias

-- 
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Thorsten Behrens]

Mathias Bauer <[EMAIL PROTECTED]> writes:

> Not exclusively. Also developers will benefit from a spec if they have
> to refactor/change/extend the code later on. Believe me, I can't count
> the occasions any more where I would have been glad to have a
> specification for a feature that needed a larger rework. Without a spec
> we very often are standing in the dark and hope to be lucky not to
> damage too much things just because we just don't know about their
> existence.
>
Hi Mathias,

yes, you might catch a few bugs using this approach. But I think one
of the key messages of agile software engineering is that in the end,
the code determines behaviour, not documentation. Put differently,
code and documentation will quickly diverge, simply because there
can't be technical, automated means to check that they are in
sync. 

The only proven way to prevent something to break in the future is to
explicitely test against it in an automated unit/integration/UI
test. _Before_ a CWS gets integrated. 

Fixing the root cause of your problem is not providing more
documentation, but providing more automated testing.

Hey, and yes, having a feature documented is _also_ nice - just as
well-commented code and interfaces. It makes working with the code
much easier - but still, even inline autodoc comments are not
up-to-date in all cases...

Cheers,

-- Thorsten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] cpu looping in cupsd and soffice.bin

[rklein]

Hi Andy,

today, I resolved my problem. Recently, I set hosts.allow and hosts.deny
very restrictive. That caused the problem with cups. It had nothing to do
with Openoffice. Any request to cups like lpq for example threw the cupsd in
the loop. Reverting the settings in hosts.allow and host.deny stopped this
from happening. Now I just have to find what needed to be included in
hosts.allow to let cups work.

RK


Andy Pepperdine wrote:
> 
> On Thursday 26 October 2006 00:38, rklein wrote:
>> Hi,
>>
>> I experience exactly the same problem like you with cupsd and OpenOffice
>> in
>> a loop. I have also SuSE (OpenSuSE 10.0) and OpenOffice 2.0 (build
>> 2.0.0.1).
>>
>> Any luck looking for help at SuSE?
> 
> Sorry to be so late replying, but I was waiting for a response from the
> Suse 
> forum; and the number of replies can be counted on no hands. So it looks
> like 
> I need to get back to trying to investigate on my own to see if I can
> guess 
> what is happening.
> 
> Andy.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/cpu-looping-in-cupsd-and-soffice.bin-tf2482603.html#a7104055
Sent from the openoffice - dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Specification Process Possibilities ... what about a wiki?

[Thorsten Behrens]

Thorsten Behrens <[EMAIL PROTECTED]> writes:

> Having explicit UI guidelines/design rules would most probably allow
> the average developer to correctly place a checkbox
>
Drats - even linked from the specs page:
http://wiki.services.openoffice.org/wiki/User_Interface_Guidelines

My bad,

-- Thorsten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Possible exploit potential in openoffice

[James Courtier-Dutton]

Stephan Bergmann wrote:

Caolan McNamara wrote:

On Wed, 2006-10-25 at 13:58 +0200, Stephan Bergmann wrote:
After some analysis I just filed 
.  However, 
that issue is probably specific to OOo as built by Sun (and available 
for download from the OOo web site).  If your OOo at 
/usr/lib/openoffice is instead built by some Linux distribution, your 
problem could be another one (if libuno_sal.so.3 is not RWX for you, 
it might also be that issue 70840 only addresses a first problem, and 
we have to address further problems once that is fixed).


Also, we really should also add...

.section.note.GNU-stack,"",@progbits


That should probably be:
#ifdef __ELF__
.section .note.GNU-stack,"",%progbits
#endif

as explained on the url I put in my initial email:
http://www.gentoo.org/proj/en/hardened/gnu-stack.xml



to the end of bridges/source/cpp_uno/gcc3_linux_intel/call.s similiar to
the line at the end of bridges/source/cpp_uno/gcc3_linux_x86_64/call.s


Yes.  Can you file an issue?


over here we just run execstack -c .../program/libgcc3_uno.so
during packaging to workaround it

C.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] How to store sensitive information

[Robert Vojta]

Why not instead making OOo aware/a client of gnome-keyring manager?


What about KDE users? Other platforms - Windows, Mac OS X?

Answer is simple - I need to store passwords on all available
platforms - like Firefox does.

--
Robert Vojta

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] How to store sensitive information

[Robert Vojta]

On 10/31/06, Mathias Bauer <[EMAIL PROTECTED]> wrote:


We have a password container that can collect passwords at runtime and
keeps them. Currently we don't store passwords persistently (only in
memory), though the implementation would be there. It uses a
configuration backend and the passwords can be "sealed" with a master
password.


Sounds like good news to me ... Can you tell me in which module is
this implementation? Is this implementation enabled by default and not
used or it's just there and nobody is using it? Are those passwords
(sealed with a master password) encrypted?

My first email was about WebDAV - it's an example from users RFEs. I
have few extensions and they need similar functionality in
OpenOffice.org - ability to store encrypted passwords persistently
sealed with master password.


The whole implementation is encapsulated into a UNO service and if
somebody wanted we could show him the ropes and discuss possible ways to
integrate with other "backends".


Hmm, I think that the Mozilla approach is better. Lot of backends on
all available platforms - never ending job. If persistently stored
passwords can be encrypted, configuration backend fits all needs for
this feature.

--
Robert Vojta

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]