Re: [dev] Packaging process

[Oliver Braun]

Hi Rene,

Rene Engelhard wrote:

Kay Ramme - Sun Germany - Hamburg wrote:


(Not to mention you renamed the packages so that they are not parallel
installable anymore with the official debs, but that's another matter)
This is unfortunate. But, we can not really know and check all distros 
package names.


yes, but there's only one Debian and you could have looked. In any case, I
raised my voice hours after I saw that on the CVS list so there would be a
chance to revert that (the wasn't something bad about openofficeorg-*
instead of openoffice.org-*).
But I agree it's only unfortunate...


I still don't see the problem here: who - beside package maintainers - 
would want to install _released_ vanilla OOo beside debian OOo on a 
single system ? How many users actually complained about this ?


For milestone builds, ooo-dev is used for package names. And I thought 
we worked out a way to avoid incompatible mixtures of the two package 
sources.


What I agree with being unfortunate is that we started with 
"openofficeorg" initially. We somehow expected the '.' to cause 
problems, but the ure package proved the opposite.


Regards,
Oliver

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

Re: [dev] Pitfall using VCL focus handler and virtual methods GetFocus/LoseFocus

[Mathias Bauer]

Philipp Lohmann - Sun Germany wrote:

> Frank Schönheit - Sun Microsystems Germany wrote:
>> No. The MyTabPage implemented a handler for the GetFocus event of one of
>> its children. Please examine the original example more carefully ;)
> 
> Point taken.
> 
>>> The other case you mention has nothing to do with 
>>> derivatives of Window at all; of course you have to be careful that a 
>>> member does not access the already partially destroyed parent.
>> 
>> That's the point: VCL does this. When a window is destroyed, it's child
>> windows (held as members) are destroyed, too. Now if one of those
>> members has the focus, VCL moves the focus to another suitable control -
>> either the being-destroyed window itself, or to a sibling of the member
>> window. In both cases, VCL calls into a partially destroyed instance.
> 
> I just tried to say that this has nothing to do with focus handling in 
> particular. You always have to handle such cases, this can happen as 
> soon as you implement a virtual method (or a callback for that matter).

That is as correct as useless. :-)

Of course you can simulate the same situation with other classes, the
pattern indeed is not unique to VCL, but at least until now no other
case is known where it can be found. I don't see value in using abstract
terms for a bug description if a concrete and very expressive example
exists.

Moreover, explaining the way how the bug is triggered and what the
trigger (not the root cause!) is is helpful because it might lead to
ideas for a solution even if you can't fix the root cause. If you remove
the trigger, the bug won't happen. I don't know if this is possible here
but IMHO thinking about it is worth the effort (see below).

IMHO the trigger is the focus change, the root cause of cause is the
overall architecture that spreads object dependencies over several
libraries, lacks refcounting, executes too much and too complex code in
the dtor etc. In concrete terms: if the control had a reference to the
tabpage instead of a pointer it can't call into a partially destructed
page. Of course then windows always must be destroyed by a dispose or
close call. I know that there still are some pitfalls but it's easier to
see and avoid them.

As we can't work on this we have to search and apply a fix for the
particular situation.

The only fix we have found until now is to use an explicit call of a
method of the edit control(s) from inside the dtor of the TabPage that
prevents the edit control(s) from calling back. This can be removing the
link, setting a flag at the derived control (or setting the pPage
pointer to zero, a "handcrafted" weak pointer) that is checked before
the page is called back or hiding the controls explicitly so that your
suggestion with "IsVisible()" can work.

If anybody has a better idea that can prevent the occurence of our bug
by fixing something in VCL please let us know. This would save us the
investigation and fixing of all the other cases shown by Carsten. Please
consider that Carsten only showed us the places where the link is used,
we still have to look for cases where the overwriting of GetFocus() is
used, something that will be time consuming. It would be nice to save
all this time for other tasks.

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] Packaging process

[Rene Engelhard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Kay Ramme - Sun Germany - Hamburg wrote:
> >I cannot gurantee it. I wrote that mail in one go.
> So, I suggest that you reread your mails before pushing the send button. 
> I do not have any tolerance for lazy mails (while I do not say that your 
> mails were lazy so).

I already did two times. Anyway, sorry.

> >>>some additions you *need* for whatever reasons.
> >>>
> >>>And you don't build some of the optional stuff.
> >>>You have various UNFIXED security things open (Mozilla to name the most
> >>>prominent one).
> >>Isn't Mozilla providing binaries of products with latest security patches?
> >
> >No. Not for old versions. Just new versions. And the OOo tree still
> So, what are they saying that they do not update the older versions? Are 
> they backporting the fixes, or is Debian doing that?

There are not. There wasn't really firefox security updates except new
firefox releases with other stuff. Same with the "normal" Mozilla.

> >contains mozilla 1.7.5 which you build against (NB: I don't know how
> >your build env looks like) and ship.
> As already said elsewhere, the problem is, that we did not find a way, 
> to reliable express dependencies against 3rd party stuff, except for the 
> real core stuff, as libc and friends. And AFAIK even these are not 

You also ship getopt and readdir.
Which reminds me I need to finish my patch to hack that out and make
Linux builds not use it.

> expressed in a formally correct way.

Yes, but then you still could have updated mozilla in-tree. it's still
1.7.5 there. Also the handling of issue
http://qa.openoffice.org/issues/show_bug.cgi?id=66338 was bad.

> >Because you can't do source fixes? You can't produce reliable binaries?
> You certainly can, every binary release of OOo is (nearly:-) bitwise
> reproduceable and tagged accordingly in CVS. And I would be surprised,
> if our binaries would be less stable than yours ...

No, you only can (assuming you take the binaries) when you got a new
release. (Or a new milestone, rc, whatever, where the first is not really
recommended for a stable release and the rc, well, it might, but..)

> >You can't provide packages for other archs (like we also do ppc and
> >sparc, for 1.1.x there also was s390)
> You may want to look at this from the other side. Builds for other archs
> may very well just be contributions to OpenOffice.org. OpenOffice.org
> would than obviously provide these contributions. There is no need to
> rebuild anything, even if you want to support other archs.

Oh? You do e.g. Linux SPARC builds/porting? Where? Last I know only
Jim Watson does. You surely own sparcs at Sun so hardware cannot be the issue?
Analog with Linux/powerpc.

> >after all, OOo claims to be free software, so changing it is allowed
> It certainly is, and, if I understand correctly (so, please correct me 
> if I am wrong), you are basically maintaining a fork!

No. A fork is if you fork off a codebase and do own stuff. This is
some adaptions and eventually a few features which will get upstream. This
is *not* a fork.

> >(claims to becausse there's stuff which is *not* free in the tree since
> >loong which outstanding issues for them...)
> You may want to give me a hint?

http://qa.openoffice.org/issues/show_bug.cgi?id=21678
http://qa.openoffice.org/issues/show_bug.cgi?id=37034
- - using non-free libraries like gpc
  (thankfully now avoidable by --disable-gpc and using basegfxs stuff)
- - questionable licenses for the hyphs (need to remove all but de and hu)

- - rhino/rhino.patch (quite obvious, told mh, nothing happened yet)
- - jurt/doc
- - netbeans_integration, I am quite sure there's stuff non-free/not LGPL
  compatible, correct me if not

For those issues I didn't file an issue because it woldn't have  brought
anything (see the jars issue).

But we nevertheless need to remove this stuff from Debians source and
binaries.

> >>Are you only submitting bugs or fixes as well?
> >
> >When I can fix them I submit fixes as well.
> >But they also didn't get applied See for example
> >http://qa.openoffice.org/issues/show_bug.cgi?id=26865 which had an easy
> >fix (ABI change, though, anyway) so it's not a that good example but
> >it was possible to fix with some coordination for a major release like
> >2.0.
> I take a look at it 

Thanks, but it mostly was important for 1.1.x (although probably too big) or
for 2.0 (best time for an ABI change). I don't think you want to change the ABI
now, do you?

> >I mostly commit fixes myself now when I have some...
> Sounds good :-)
> >
> >When I can not there's problems.. But for important functionality bugs
> >or licensing bugs there's still no fix. Issue numbers on request...
> Just give me some ids, I try to comment ...

See above.
Or take http://qa.openoffice.org/issues/show_bug.cgi?id=49590 (which is
still not fixed even with michaels patch, and so it's disabled
completely in Debian...). Or that LFS issue above which had a tiny
change (whic

Re: [dev] Pitfall using VCL focus handler and virtual methods GetFocus/LoseFocus

[Philipp Lohmann - Sun Germany]

Frank Schönheit - Sun Microsystems Germany wrote:

No. The MyTabPage implemented a handler for the GetFocus event of one of
its children. Please examine the original example more carefully ;)


Point taken.

The other case you mention has nothing to do with 
derivatives of Window at all; of course you have to be careful that a 
member does not access the already partially destroyed parent.


That's the point: VCL does this. When a window is destroyed, it's child
windows (held as members) are destroyed, too. Now if one of those
members has the focus, VCL moves the focus to another suitable control -
either the being-destroyed window itself, or to a sibling of the member
window. In both cases, VCL calls into a partially destroyed instance.


I just tried to say that this has nothing to do with focus handling in 
particular. You always have to handle such cases, this can happen as 
soon as you implement a virtual method (or a callback for that matter).


Kind regards, pl

--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
 -- Author unknown

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

[dev] warningfixes01

[Stephan Bergmann]

Hi all,

We would like to close CWS warningfixes01 soon (tomorrow?), including 
all the warnings01/SRC680m173 problems that are fixed by then, and 
postpone any still missing fixes to a follow-up CWS.


Of the 18 issues which 
 depends on as 
of now, 8 are still new or started and could potentially still be fixed 
on CWS warnings01:


i51521 mhu, cmc, cloph
i66577 sb (will take longer than tomorrow)
i66723 sb (need input from vq)
i66729 fs
i66730 gh
i66731 ericb
i66753 ihi
i66754 tl

So, if you think you could fix any of those until tomorrow, please add 
your issue to CWS warningfixes01 and do so.  (I do not want to hurry 
anybody, I just want to make sure we have any fixed issues integrated as 
soon as possible.)


Thanks,
-Stephan

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

Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)

[Christian Lohmaier]

Hi Janne,

On Tue, Jun 27, 2006 at 04:10:01PM +0200, Janne Johansson wrote:
> >On Tue, Jun 27, 2006 at 10:10:09AM +0200, Janne Johansson wrote:
> >> 2006/6/26, Éric Bischoff <[EMAIL PROTECTED]>:
> [...]
> It's fine that OOo is relocatable, just rpm's usually arent, whereas stuff
> doing
> configure;make;make install usually are.

Again not true. While building rpms I learned often enough that when you
want a prefix other than the default you need to patch the makefiles or
even touch the source itself.

And that is while building from source, so let alone the binaries.

ciao
Christian
-- 
NP: Limp Bizkit - Almost Over

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

Re: [dev] Packaging process

[Kay Ramme - Sun Germany - Hamburg]

Rene,

Rene Engelhard wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kay Ramme - Sun Germany - Hamburg wrote:
[...]

What I wanted to say with the introduction was that I tried to be polite
but as there was things you mentioned which are no-no for distributions
and you offended all Debian users I needed to make clear I try that but
I did _not_ offend any Debian user, I am only asking questions and 
making suggestions and express my opinion. For example, what is wrong 
about asking why distros always compile everything by their own? It may 
be naive but in _no_ terms offensive!



I cannot gurantee it. I wrote that mail in one go.
So, I suggest that you reread your mails before pushing the send button. 
I do not have any tolerance for lazy mails (while I do not say that your 
mails were lazy so).


[...]
purposes. Some are for desktop users, some are for generic servers, some 
are for specialized purposes like firewalls, application servers or 
clustering. Some try to imitate Windows or Mac OS X, some try to get 
away from other OSes as much as they can. A lot of changes are made to 
give personality to the distributions.
That does not necessarily mean, that they need to patch or change 
anything in the provided products, does it? At least OOo provides 
extensive configurability to actually change everything, without needing 
to alter a single line of code.

Of course that does. There's bugs in OOo. Bugs need to be fixed.
Distributions and OOo have different release schedules. Or: You have
Release schedules shouldn't be the problem, I would expect Debian to 
always ship the latest stable version.


We can't always. Release schedules is release schedules.
For example, we freeze in October, new OOo will come September.
I am not sure we will have enough time to get it into the distri.
(Building, testing in real-world, all library dependencies must be met
etc, various revisions, approval cycles, etc)
So, if you think that you do not have enough time to import the latest 
OOo or that it does not match your quality guide lines, I suggest to 
either go with the old one, or to officially raise your voice and to 
express your concerns. I am pretty sure Martin is listening and would 
escalate any issue as needed and appropriate.


Or take stable: 1.1.3 is in stable (1.1.4 was released already, yes, I
maybe could have gotten that in, but 1.1.3 needed updates first and then
it was too late. 1.1.5 was released *after* the sarge release)

So, 1.1.3 seems to be reasonable than.




some additions you *need* for whatever reasons.

And you don't build some of the optional stuff.
You have various UNFIXED security things open (Mozilla to name the most
prominent one).

Isn't Mozilla providing binaries of products with latest security patches?


No. Not for old versions. Just new versions. And the OOo tree still
So, what are they saying that they do not update the older versions? Are 
they backporting the fixes, or is Debian doing that?

contains mozilla 1.7.5 which you build against (NB: I don't know how
your build env looks like) and ship.
As already said elsewhere, the problem is, that we did not find a way, 
to reliable express dependencies against 3rd party stuff, except for the 
real core stuff, as libc and friends. And AFAIK even these are not 
expressed in a formally correct way.



In any case, it is a no-no for a Linux distri to ship binaries you just
got.

For what reason?


Because you can't do source fixes? You can't produce reliable binaries?
You certainly can, every binary release of OOo is (nearly:-) bitwise 
reproduceable and tagged accordingly in CVS. And I would be surprised, 
if our binaries would be less stable than yours ...

You can't provide packages for other archs (like we also do ppc and
sparc, for 1.1.x there also was s390)
You may want to look at this from the other side. Builds for other archs 
may very well just be contributions to OpenOffice.org. OpenOffice.org 
would than obviously provide these contributions. There is no need to 
rebuild anything, even if you want to support other archs.



And not everything is configurable...

So you patch what is not configurable?


And what we need for other stuff, too.
We also of course patch the configs for our default-configs.
We also patch features in if that's sensible or if those features are
planned to go upstream some time (KDE stuff, Lockdown, Calc Solver etc)
What about providing patches to configure the needed things at run- or 
deployment-time?


after all, OOo claims to be free software, so changing it is allowed
It certainly is, and, if I understand correctly (so, please correct me 
if I am wrong), you are basically maintaining a fork!

(claims to becausse there's stuff which is *not* free in the tree since
loong which outstanding issues for them...)

You may want to give me a hint?






Yeah, I know, but you implied wanting every distri getting the rpms from
OOo and building their rpms/debs out of that.
No, you misunderstood me. My 

Re: [dev] Changing the default Java for OOo from command line

[Tobias Krais]

Hi Joachim,

>> OK. I used:
>> -%<-
>>
>> export UNO_JAVA_JFW_ENV_CLASSPATH="/usr/lib/openoffice/program/classes/j
>> urt.jar;/usr/lib/openoffice/program/classes/ridl.jar;/usr/lib/openoffice/program
>>
>> /classes/java_uno.jar;/usr/lib/openoffice/program/classes/juh.jar;/usr/lib/openo
>>
>> ffice/program/classes/jut.jar;/usr/lib/openoffice/program/classes/unoidl.jar"

> UNO_JAVA_JFW_ENV_CLASSPATH can be set to true which indicates that
> CLASSPATH is used.

I read this in you document. But it did not change the behavior.

[...]

> Another idea, add unoloader.jar to the class path.

I tried this also, but it did not work out.

Greetings, Tobias

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

Re: [dev] Pitfall using VCL focus handler and virtual methods GetFocus/LoseFocus

[Mathias Bauer]

Philipp Lohmann - Sun Germany wrote:

> Mathias Bauer wrote:
>> Philipp Lohmann - Sun Germany wrote:
>> You overlook an important detail: the problem happens before any such
>> notification could have been sent and Frank obvisouly tried to explain that.
> 
> The case Carsten mentioned was a control implementing :GetFocus and in 
> there manipulating a sibling control via its parent window - which was 
> already destroyed. That sibling would obviously already have gotten its 
> dying notification. The other case you mention has nothing to do with 
> derivatives of Window at all; of course you have to be careful that a 
> member does not access the already partially destroyed parent. But this 
> basically has nothing to do with Window focus handling, except that 
> focus handling is one example for this.

No, the parent window wasn't destroyed, only partially. The bug we found
is exactly as I described it. And the problem is indeed related to
windows derivatives: without the focus change it wouldn't happen. Of
course you can have the same bug in other constructs also but in our
case it was definitely triggered by a focus change and the callbacks
related to this.

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] Packaging process

[Éric Bischoff]

Le Mardi 27 Juin 2006 14:14, Christian Lohmaier a écrit :
> > I did not know that. So that would be equivalent to a "make install"?
> > Where is that documented?
>
> There is some minimalistic info in the Hacking-guide in the wiki.

OK. Minimalistic info in some hackers guide.

On the other hand, "make install" is something well documented and well known.

> > And, returning to main topic, why try to import into Linux a packaging
> > philosophy that is adapted to Windows?
>
> Because unless most of the linux or the windows software, OOo is a
> cross-platform thing that existed for years.

That's historical reasons.

> As with mozilla/firefox there are binary packages for the different
> operating systems/distros. OOo always worked like that.

These are indeed interesting to the end users, not to the developpers nor the 
packagers.

> And why don't you want users to be able to install the vanilla version,
> but instead trying to "force" them use the version from their
> distribution?

I fully agree users should be able to choose. No one is forced to do anything.

The only thing his, when they use the distribution version, they have more 
guarantee about coherence with other software, adequacy with the general 
philosophy of the distribution, conformance to the security policy, etc. 
That's why it makes usually a better choice for the John Doe user to choose 
the version packaged with his distribution.


-- 
Si on ne peut pas toujours compter sur ses amis, on peut toujours compter son 
or.
(Donjon de Naheulbeuk)

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

Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)

[Janne Johansson]

On Tue, Jun 27, 2006 at 10:10:09AM +0200, Janne Johansson wrote:
> 2006/6/26, Éric Bischoff <[EMAIL PROTECTED]>:
> >Le Lundi 26 Juin 2006 15:47, Kay Ramme - Sun Germany - Hamburg a écrit:
> >> > - OOo should not attempt to build its own packages, at least under
> >Linux.
> >> >   Under Linux, that's the distributions' work!
> >> >   This problem is related to the "make install" one.
> >>
> >> In my opinion, OOo is showing the right approach here, it is IMHO
> >> unfortunate and a waste of time, that everybody patches and builds
> >> everything by its own, leading to small incompatibilities and bugs
here
> >> and there ...
> [...]
> I am trying to fit OOo2 into our sourcebuilding packaging system, and I
> agree with your point.
> Having to go over rpms feels "stupid" in a way where not everything is
meant
> to end up at
> /usr/local or where linux isn't necessarily implying you use (and like)
> rpms.

A make install that would install everything in the same default prefix
as the rpms would not make any difference at all.



It's fine that OOo is relocatable, just rpm's usually arent, whereas stuff
doing
configure;make;make install usually are.
Actually, it wouldn't matter if it were .deb's or stuff packed with ARJ.
It's the point of having some kind of command that would move the built
files from
their location to a tree at $PREFIX (or $DESTDIR) w/o going via some alien
package
format first. For those doing development, I could imagine this would be
kind of
hard on the I/O.

OOo is relocatable, so if you don't like the contents of

/opt/openoffice.org2.0 somewhere else.

If you (like many distros) split the ooo-files around different places
in the filesystem, then a make install would not help you either. You
would have to pick & move files yourself as well.



We don't. But the idea of building from source, getting rpms, (having to
build rpm itself) and then extracting from rpms, piping through cpio and
lastly
putting the files where they should end up sounds weird to me.

--
Some mornings, it's just not worth gnawing through the straps...

Re: [dev] Pitfall using VCL focus handler and virtual methods GetFocus/LoseFocus

[Frank Schönheit - Sun Microsystems Germa ny]

Hi Philipp,

> Bullshit. The object dying notifies you that it gets destroyed and you 
> still cannot refrain from using it ? Maybe that's just me, but i would 
> call THAT a destructive attitude  ;-) 

Mathias already explained that you got me wrong here - in the scenario I
described, there was no notification, except from the control which the
SomeWindow instance itself already destroyed.

> The case Carsten mentioned was a control implementing :GetFocus and in 
> there manipulating a sibling control via its parent window - which was 
> already destroyed.

No. The MyTabPage implemented a handler for the GetFocus event of one of
its children. Please examine the original example more carefully ;)

> The other case you mention has nothing to do with 
> derivatives of Window at all; of course you have to be careful that a 
> member does not access the already partially destroyed parent.

That's the point: VCL does this. When a window is destroyed, it's child
windows (held as members) are destroyed, too. Now if one of those
members has the focus, VCL moves the focus to another suitable control -
either the being-destroyed window itself, or to a sibling of the member
window. In both cases, VCL calls into a partially destroyed instance.

Unfortunately I don't see a way how VCL itself could prevent this, as it
does not (and cannot) know that the parent is already partially
destroyed. The only way I see is to handle all those cases in the
derived classes ...

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Database   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

[dev] Contribution

[Steve High]

Greetings

I am interested in helping in the continued awesomization of OpenOffice.

My specialty is LAMP environment programming, and I would be interested in
creating some sort of API that would allow the creation/editing of OOo
documents remotely via a web interface.  If this is not feasible, I would
like to help out in any way I can.

Please point me in the right direction, because I have never participated in
an open collaboration before.

Thanks
-steve high

--
--
(42)
--

Re: [dev] Pitfall using VCL focus handler and virtual methods GetFocus/LoseFocus

[Philipp Lohmann - Sun Germany]

Mathias Bauer wrote:

Philipp Lohmann - Sun Germany wrote:
You overlook an important detail: the problem happens before any such
notification could have been sent and Frank obvisouly tried to explain that.


The case Carsten mentioned was a control implementing :GetFocus and in 
there manipulating a sibling control via its parent window - which was 
already destroyed. That sibling would obviously already have gotten its 
dying notification. The other case you mention has nothing to do with 
derivatives of Window at all; of course you have to be careful that a 
member does not access the already partially destroyed parent. But this 
basically has nothing to do with Window focus handling, except that 
focus handling is one example for this.


Just my 2 cents, pl

--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
 -- Author unknown

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

Re: [dev] Packaging process

[Rene Engelhard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kay Ramme - Sun Germany - Hamburg wrote:
[...]

What I wanted to say with the introduction was that I tried to be polite
but as there was things you mentioned which are no-no for distributions
and you offended all Debian users I needed to make clear I try that but
I cannot gurantee it. I wrote that mail in one go.

[...]
> >>>purposes. Some are for desktop users, some are for generic servers, some 
> >>>are for specialized purposes like firewalls, application servers or 
> >>>clustering. Some try to imitate Windows or Mac OS X, some try to get 
> >>>away from other OSes as much as they can. A lot of changes are made to 
> >>>give personality to the distributions.
> >>That does not necessarily mean, that they need to patch or change 
> >>anything in the provided products, does it? At least OOo provides 
> >>extensive configurability to actually change everything, without needing 
> >>to alter a single line of code.
> >
> >Of course that does. There's bugs in OOo. Bugs need to be fixed.
> >Distributions and OOo have different release schedules. Or: You have
> Release schedules shouldn't be the problem, I would expect Debian to 
> always ship the latest stable version.

We can't always. Release schedules is release schedules.
For example, we freeze in October, new OOo will come September.
I am not sure we will have enough time to get it into the distri.
(Building, testing in real-world, all library dependencies must be met
etc, various revisions, approval cycles, etc)

Or take stable: 1.1.3 is in stable (1.1.4 was released already, yes, I
maybe could have gotten that in, but 1.1.3 needed updates first and then
it was too late. 1.1.5 was released *after* the sarge release)

> >some additions you *need* for whatever reasons.
> >
> >And you don't build some of the optional stuff.
> >You have various UNFIXED security things open (Mozilla to name the most
> >prominent one).
> Isn't Mozilla providing binaries of products with latest security patches?

No. Not for old versions. Just new versions. And the OOo tree still
contains mozilla 1.7.5 which you build against (NB: I don't know how
your build env looks like) and ship.

> >In any case, it is a no-no for a Linux distri to ship binaries you just
> >got.
> For what reason?

Because you can't do source fixes? You can't produce reliable binaries?
You can't provide packages for other archs (like we also do ppc and
sparc, for 1.1.x there also was s390)

> >And not everything is configurable...
> So you patch what is not configurable?

And what we need for other stuff, too.
We also of course patch the configs for our default-configs.
We also patch features in if that's sensible or if those features are
planned to go upstream some time (KDE stuff, Lockdown, Calc Solver etc)

after all, OOo claims to be free software, so changing it is allowed
(claims to becausse there's stuff which is *not* free in the tree since
loong which outstanding issues for them...)

> >That also means that you don't need to ship every lib inside the
> >package, bloating it for example. Or you have to integrate with
> >distro-specifics (like sensible-browser, run the browser you have
> >choosen system-wide in the env or set with the BROWSER envvar, just for
> >example, that's a minor one).
> This seems to be some kind of system integration, isn't it?

Right.

> >Or take pyuno. You need a internal python and can't use the systems'
> >python modules, not to mention the stuff isn't simply usable by the
> >systems' normal python.
> Just take a look from an ISVs perspective.

Yeah, I know, but you implied wanting every distri getting the rpms from
OOo and building their rpms/debs out of that.

> >>>3) Corrections - A lot of the work is made to fix problems in the 
> >>>packaged software itself. Why are such changes not done upstream at the 
> >>>initial software projects? They are done upstream too, but since it's a 
> >>>much slower process than a quick fix in the distribution, upstream 
> >>>corrections are done usually much after the distribution is in the 
> >>>retail stores.
> >>This is understood, but is IMHO the wrong approach and really should be 
> >>the exception, I think at least we at OOo are very willing to support 
> >>the distributions to get their fixes merged in upstream.
> >
> >LOL. I have many counterexamples here where bugs ARE NOT GETTING FIXED
> >after submitted.
> >I can look for them.
> Are you only submitting bugs or fixes as well?

When I can fix them I submit fixes as well.
But they also didn't get applied See for example
http://qa.openoffice.org/issues/show_bug.cgi?id=26865 which had an easy
fix (ABI change, though, anyway) so it's not a that good example but
it was possible to fix with some coordination for a major release like
2.0.

I mostly commit fixes myself now when I have some...

When I can not there's problems.. But for important functionality bugs
or licensing bugs there's still no fix. Issue numbers on request...

Re: [dev] Changing the default Java for OOo from command line

[Joachim Lingner]

Hi,



OK. I used:
-%<-

export UNO_JAVA_JFW_ENV_CLASSPATH="/usr/lib/openoffice/program/classes/j
urt.jar;/usr/lib/openoffice/program/classes/ridl.jar;/usr/lib/openoffice/program
/classes/java_uno.jar;/usr/lib/openoffice/program/classes/juh.jar;/usr/lib/openo
ffice/program/classes/jut.jar;/usr/lib/openoffice/program/classes/unoidl.jar"
UNO_JAVA_JFW_ENV_CLASSPATH can be set to true which indicates that 
CLASSPATH is used.


However, I have no clue right now as to what causes the 
UnsatisfiedLinkError. You could still build the Java-UNO bridge with 
debug information and hope that you get more output. The bridge is in 
project bridges (bridges/source/jni_uno).


Another idea, add unoloader.jar to the class path.


Joachim

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

Re: [dev] Pitfall using VCL focus handler and virtual methods GetFocus/LoseFocus

[Mathias Bauer]

Philipp Lohmann - Sun Germany wrote:

> Frank Schönheit - Sun Microsystems Germany wrote:
>>> There is even a event listener mechanism for dying windows.
>> 
>> Which also doesn't help, since it's also triggered from Window::~Window
>> only - which is too late, since a lot of destruction already happens
>> before this in the derived class.
> 
> Bullshit. The object dying notifies you that it gets destroyed and you 
> still cannot refrain from using it ? Maybe that's just me, but i would 
> call THAT a destructive attitude ;-)

You overlook an important detail: the problem happens before any such
notification could have been sent and Frank obvisouly tried to explain that.

A TabPage is destructed. Before the base class dtor of the TabPage (and
so the Window calls dtor) is called the members of the TabPage are
destroyed. One of these members currently has the focus and when it is
destroyed the OS (or VCL, I don't know but it doesn't matter here) moves
the focus to another edit control member of the TabPage. Now *this*
control that still is visible calls a method in the TabPage, either by
using a GetFocus-Link or from the overloaded virtual GetFocus() method.
If the called method of the TabPage now accesses members of the TabPage
that already have been destroyed (as in the bug we discovered) it
corrupts memory or crashes. Neither the edit control that gets the focus
nor the TabPage itself that gets called in the Handler are hidden or
(completely) destroyed because for none of them Window::~Window has been
called! Just the code inside the body of the TabPage dtor and some of
the dtors of its members have been executed.

IMHO there is no way to prevent this from happening without explicitly
dealing with this situation in the TabPage destructor. Carsten already
posted a solution for the Link case, for the other one I suggest to use
an explicit method at the control that tells it that the TabPage
shouldn't be called anymore so that the handler could be

void MyWindow::GetFocus()
{
if ( bTabPageStillAvailable )
{
// Do something usefull
pTabPage->DoSomething();
}
}

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] Packaging process

[Kay Ramme - Sun Germany - Hamburg]

Hi Rene,

Rene Engelhard wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[ late answer, I needed time to *try* make my answer polite, sorry if that
doesn't happen all the time in this post, for the record I am one of the
two people making the Debian packages, currently the most active one of
both ]
just saying this is IMHO already un-polite. I think I am personally open 
for any discussion, as long it is based on arguments and facts. The 
moment you start being un-polite I immediately stop answering, and you 
may discuss with whomever you want (actually achieving nothing or may be 
the contrary). I will not repeat this.




Kay Ramme - Sun Germany - Hamburg wrote:
1) Suitability - Not all the Linux distributions follow the same purposes. 
Some are for desktop users, some are for generic servers, some are for 
specialized purposes like firewalls, application servers or clustering. 
Some try to imitate Windows or Mac OS X, some try to get away from other 
OSes as much as they can. A lot of changes are made to give personality to 
the distributions.
That does not necessarily mean, that they need to patch or change 
anything in the provided products, does it? At least OOo provides 
extensive configurability to actually change everything, without needing 
to alter a single line of code.


Of course that does. There's bugs in OOo. Bugs need to be fixed.
Distributions and OOo have different release schedules. Or: You have
Release schedules shouldn't be the problem, I would expect Debian to 
always ship the latest stable version.



some additions you *need* for whatever reasons.

And you don't build some of the optional stuff.
You have various UNFIXED security things open (Mozilla to name the most
prominent one).

Isn't Mozilla providing binaries of products with latest security patches?


In any case, it is a no-no for a Linux distri to ship binaries you just
got.

For what reason?


And not everything is configurable...

So you patch what is not configurable?


2) Coherence - A Linux distribution is a coherent set of software. Even if 
documents like FHS and LSB state a lot of things, like the place where 
files should go, there's room for a lot of variations. As long as the 
various choices are coherent within the same distribution, that's okay. A 
lot of changes here and there attempt to have all software follow common 
conventions.
I think you hit the point here, IMHO Linux does not only need to be 
coherent inside the distributions, but also _overall_ ...


Yes, but it also needs coherency inside the distro.

That is what Eric said ...


That also means that you don't need to ship every lib inside the
package, bloating it for example. Or you have to integrate with
distro-specifics (like sensible-browser, run the browser you have
choosen system-wide in the env or set with the BROWSER envvar, just for
example, that's a minor one).

This seems to be some kind of system integration, isn't it?


Or take pyuno. You need a internal python and can't use the systems'
python modules, not to mention the stuff isn't simply usable by the
systems' normal python.

Just take a look from an ISVs perspective.



3) Corrections - A lot of the work is made to fix problems in the packaged 
software itself. Why are such changes not done upstream at the initial 
software projects? They are done upstream too, but since it's a much 
slower process than a quick fix in the distribution, upstream corrections 
are done usually much after the distribution is in the retail stores.
This is understood, but is IMHO the wrong approach and really should be 
the exception, I think at least we at OOo are very willing to support 
the distributions to get their fixes merged in upstream.


LOL. I have many counterexamples here where bugs ARE NOT GETTING FIXED
after submitted.
I can look for them.

Are you only submitting bugs or fixes as well?



And anyway, you have an other release schedule than distributions. How
is a distribution supposed to backport bugfixes for their next release
if there's only binaries you ship and have to wait for a new OOo release
(which might not fix those bugs after all) although the distris deadline
is earlier?
AFAIK, we are providing respins of the current major version in regular 
(mostly quarterly) intervals. We also provide respins of older versions 
if needed. There is IMHO no need to backport any patches, just use the 
latest stable version.




In short: I suppose you bring a big problem to distributors by bringing 
already packaged software.
I think I disagree again, as you said, distros may just install and 
repackage OOo. IMHO, the most prominent reason for repackaging is to 
change OOo to be a "bundled" product, while the packages we are 
providing are "unbundled". The point being, that there IMHO is _no_ real 
or good reason to have products (applications) to be "bundled", except 
that this is what distros do.


No, the reason is that shipping binaries is bad. Every distro rebuilds

Repeating think

Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)

[Christian Lohmaier]

Hi Jane,

On Tue, Jun 27, 2006 at 10:10:09AM +0200, Janne Johansson wrote:
> 2006/6/26, Éric Bischoff <[EMAIL PROTECTED]>:
> >Le Lundi 26 Juin 2006 15:47, Kay Ramme - Sun Germany - Hamburg a écrit:
> >> > - OOo should not attempt to build its own packages, at least under
> >Linux.
> >> >   Under Linux, that's the distributions' work!
> >> >   This problem is related to the "make install" one.
> >>
> >> In my opinion, OOo is showing the right approach here, it is IMHO
> >> unfortunate and a waste of time, that everybody patches and builds
> >> everything by its own, leading to small incompatibilities and bugs here
> >> and there ...
> [...] 
> I am trying to fit OOo2 into our sourcebuilding packaging system, and I
> agree with your point.
> Having to go over rpms feels "stupid" in a way where not everything is meant
> to end up at
> /usr/local or where linux isn't necessarily implying you use (and like)
> rpms.

A make install that would install everything in the same default prefix
as the rpms would not make any difference at all.

OOo is relocatable, so if you don't like the contents of
/opt/openoffice.org2.0 somewhere else.

If you (like many distros) split the ooo-files around different places
in the filesystem, then a make install would not help you either. You
would have to pick & move files yourself as well.

ciao
Christian
-- 
NP: Silverchair - Shade

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

Re: [dev] Packaging process

[Christian Lohmaier]

On Tue, Jun 27, 2006 at 11:09:39AM +0200, Éric Bischoff wrote:
> Le Lundi 26 Juin 2006 21:33, Christian Lohmaier a écrit :
> > ? The user doesn't have to bother. Either they use the packages provided
> > by $distribution or they take the packages from vanilla OOo.
> >
> > And the packagers who are doing the packages for their distribution
> > should know how to unpack something or how to compile from source.
> >
> > I absolutely do not get your point.
> 
> My point is : why make it unnatural and complicated when you can do it in the 
> normal, regular way? The normal, regular way is to package software that 
> installs with "make install".

Because the structure of the OOo build-process is anything but regular,
normal way?
 
> Currently, if distributions want to do serious changes in OOo, they have to 
> learn the whole build mechanism, scp2 bits, etc, to finally build a package 
> that they will disassemble right away. Of course they can learn how to do 
> that, it's just unusual, since no other software than OOo goes that way.

Yes. scp2 is special. But again: This has nothing to do about whether to
do a make install or to not.

> > You can use linkoo to create an installation out of your build-dir.
> 
> I did not know that. So that would be equivalent to a "make install"? Where 
> is 
> that documented?
 
There is some minimalistic info in the Hacking-guide in the wiki. 

> > > I install my distribution, and all software works smoothly together.
> >
> > That is as getting all your software from Microsoft, one single
> > "Distributor".
> 
> Okay, that piece of discussion is unrelated to main topic. It is even 
> completly off-topic ;-) but interesting, so let's continue with that. 
> Perharps in private if it bothers the others.
> 
> Yes, you are right. That's like getting all your software from Microsoft. But 
> there are a few differences that make a lot of importance (caution, troll 
> included):
> 
> 1) In fact, many companies _do_ get all their software from Microsoft, 
> putting 
> themselves in a state of strategic dependancy.

I was not talking about companies, but end-users. And yes, if they get
everything from microsoft, they're using a distribution and thus is a
subset not related to the point.

> 2) The software in your Linux distribution has not been written by the 
> distributor...

Again this is not the point. A distributor's job is to ensure
interoperability between the software packages it provides.

In windows world the only thing that you can count to a similar
framework may be the driver certification that almost no (low-end)
vendor uses. But this is more hardware related stuff and thus unrelated
again.

> 3) You have the choice of your distributor. There's real concurrence.

Again true, but totally missing the point.

The point was: 
"Get binary from $vendor and run it without problems" is possible with
windows, but not with linux. With linux you have:
"Get the version built for Redhat if you're using RedHat", "get the
version built for SuSE if you'Re using SuSE". "If you're using another
distribution, then we can not guarantee that it will work - you can try
one of the other distribution-packages or compile yourself. Good luck"

> 4) A Linux distribution contains almost all the software you might need, it's 
> seldom needed to look outside of your distro.

Again missing the point. I don't deny that.

> 5) With Microsoft you cannot adapt the software to your needs. You have not 
> the source.

Again true but missing the point.

> > Now try to apply this to linux distributions. Get a package for SuSE and
> > try to install that on Redhat.
> 
> No one does that. Software is coherent within ONE distribution.

Here you have the point (although you didn't realize that this was the
point).

> Listen, that's two different approaches. Why not just admit that it's 
> different philosophies, with both their advantages and drawbacks?

I did not deny that, and the different philosophies don't matter at all.

> And, returning to main topic, why try to import into Linux a packaging 
> philosophy that is adapted to Windows?

Because unless most of the linux or the windows software, OOo is a
cross-platform thing that existed for years. 
As with mozilla/firefox there are binary packages for the different
operating systems/distros. OOo always worked like that.

And why don't you want users to be able to install the vanilla version,
but instead trying to "force" them use the version from their
distribution?

ciao
Christian
-- 
NP: Silverchair - Shade

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

Re: [dev] Packaging process

[Rene Engelhard]

Am Dienstag, 27. Juni 2006 13:56 schrieb Christian Lohmaier:
> You shouldn't have made it polite, but instead should have tried to
> focus on the topic itself. (note that the thread is labeled with "packaging
> process"...)

And it already drifted away a bit.

> > In any case, it is a no-no for a Linux distri to ship binaries you just
> > got.
> 
> Nobody questioned that.

Then I read Kays comments wrong...
But he said stuff about "we fix it so than you can take our rpms"...

> > No.
> > 
> > Dynamic libraries under Linux have SONAMEs indicating
> > binary-compatibility. The Windows DLL hell is about stuff just named
> > .dll without indications about of that.
> 
> The problem is not that you cannot determine what version is installed,
> but that often libraries are not compatible. Versions compiled with
> version $foo doesn't run on version $bar

That's what SONAMEs are for (barring library bugs which often are quite fast 
fixed
after they have been found in Debian unstable (or by users by other distris who
installed libs themselved) because other distris rebuild everything on a node
library update) and therefore don't find it.)). In your case, the SONAME just 
should
bump. Of course, if you build against a newer lib, due to ELF linking it might 
not run
against a older one (because just functions/symbols got added which don't 
warrant a
SONAME bump) this might be right. But for that you have a build environment with
that old lib and you have a reliable one. That's what Sun is doing now anyway 
with
their glibc etc baseline. So that's no argument for including every lib in the 
tree.

Regards,

Rene
-- 
René Engelhard -- Debian GNU/Linux Developer -- Debian OOo Maintainer-Team
http://www.debian.org | http://people.debian.org/~rene/ | [EMAIL PROTECTED]
http://openoffice.debian.net | debian-openoffice@lists.debian.org
GPG: 248AEB73 | Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73

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

Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)

[Rene Engelhard]

Am Dienstag, 27. Juni 2006 13:26 schrieb Kay Ramme - Sun Germany - Hamburg:
> > That's the distributions' issue.
> EXACTLY

No. It's not. You mean that it's a problem for *you*.

I mean outdated packages in a distribution is _at first_ a problem
of that *distri itself*. That real outdated packaegs in development branches
may become a problem is right, yes. Even in stable things when you don't get 
proper
security patches for it (the bad example is Mozilla)

But for released products, nothing would've changed. We still ship 1.1.3 in 
stable
That never will change until the next stable release - planned in Dec - (which
currently is planned to have 2.0.3, 2.0.4/2.1/2.4 will come September and the
freeze is October. Quite risky...)

Regards,

Rene
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A EB73

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

Re: [dev] Packaging process

[Christian Lohmaier]

Hi Rene, 

On Tue, Jun 27, 2006 at 01:06:10PM +0200, Rene Engelhard wrote:
> Christian Lohmaier wrote:
> > That is as getting all your software from Microsoft, one single
> > "Distributor".
> 
> This comparison is shit.

Starts great. 

> > But on windows you can basically get every software from any vendor. If
> > it is labeled "runs on windows XP", you can be pretty sure that it runs
> > (despite the bugs it might have).
> 
> Just because they either are statically linked or ship every lib
> they need because of the DLL-hell. wow.

That doesn't matter.

> > Now try to apply this to linux distributions. Get a package for SuSE and
> > try to install that on Redhat. At best you can use --nodeps to ignore
> > the different naming-schemes of the packages and it will run.
> > But using switches to bypass deps or other things surely is not the best
> > way on how a package management tool should work.
> 
> Well, your problem if you try to do that... 

Hello? May I remind you of what this side-part of the discussion is about?

> [...] 
> > need $foo and $bar". $foo and $bar themselves require other packages or
> > worse conflict with other packages. (think of sound-severs,
> > desktop-environments,)
> 
> Sounds like a bug to me if packages for GNOME e.g. conflict against
> KDE...

Yeah - the old "pick *parts* of a statement and make whitty comments
about it" tactic.

The desktop-environments was related to the need $foo that in turn
requires another part, not on the conflicts one.

ciao
Christian
-- 
NP: Silverchair - Shade

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

Re: [dev] Packaging process

[Christian Lohmaier]

Hi *,

On Tue, Jun 27, 2006 at 01:02:58PM +0200, Rene Engelhard wrote:
> 
> [ late answer, I needed time to *try* make my answer polite, sorry if that
> doesn't happen all the time in this post, for the record I am one of the
> two people making the Debian packages, currently the most active one of
> both ]

You shouldn't have made it polite, but instead should have tried to
focus on the topic itself. (note that the thread is labeled with "packaging
process"...)

> Kay Ramme - Sun Germany - Hamburg wrote:
> > That does not necessarily mean, that they need to patch or change 
> > anything in the provided products, does it? At least OOo provides 
> > extensive configurability to actually change everything, without needing 
> > to alter a single line of code.
> 
> Of course that does. There's bugs in OOo. Bugs need to be fixed.
> Distributions and OOo have different release schedules. Or: You have
> some additions you *need* for whatever reasons.

All this is independent of the packaging.

> And you don't build some of the optional stuff.
> You have various UNFIXED security things open (Mozilla to name the most
> prominent one).

This is not either. If not building some optional stuff breaks the
default packaging, then it would be a bug.
 
> In any case, it is a no-no for a Linux distri to ship binaries you just
> got.

Nobody questioned that.

> [...]
> > >... and we would have the DLL conflicts nightmare in Linux too (see 
> > >"Coherence" paragraph) ;-).
> > So, we already have that par excellence ... :-(. Exactly this is the 
> > reason, why we (being an ISV) have to bring all this 3rd party stuff by 
> > our own, basically being a kind of a mini distro on Linux.
> 
> No.
> 
> Dynamic libraries under Linux have SONAMEs indicating
> binary-compatibility. The Windows DLL hell is about stuff just named
> .dll without indications about of that.

The problem is not that you cannot determine what version is installed,
but that often libraries are not compatible. Versions compiled with
version $foo doesn't run on version $bar

> [...] 

ciao
Christian
-- 
NP: Silverchair - Shade

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

Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)

[Kay Ramme - Sun Germany - Hamburg]

Hi Rene,

Rene Engelhard wrote:


ROTL. Not everything the LSB says makes sense. The OOo build system
*has* support for building debs. Use this.
This unfortunately does not work for people not building their own OOo. 
A while ago it was planned (->Martin H.: any news on this?) to provide 
.debs for Sun Hamburg build OOo installation sets as well as RPMs. I 
_am_ using Debian and would have loved to add OpenOffice.org to my 
sources.list (as well as Mozilla.org, ...).


I think it's not the role of the software developpers to distribute the 
software, just like it's not the role of package maintainers to develop 
software. If they patch the code, normally they should contribute their 
patches back in IssueZilla.
I tend to disagree here (see above :-), if all products / software would 
be provided as packages by their developers, there would be far less 
incompatibilities between the distributions, and one wouldn't need to 


Then you don't have experience with this. Sorry, but this is
completely wrong, and in any case you can't then add fixes either.
(see clophs post for example)

Could you please elaborate?


wait until a particular distribution would provide the latest package of 
a particular product ...


That's the distributions' issue.

EXACTLY


Regards,

Rene

Kay

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

Re: [dev] Linux: Deploying a UNO Package for all users on PC

[Mathias Supp]

Hi Tobias,

just add "--shared"-Option as described:
>unopkg.exe --help

using: unopkg add  package-path...
  unopkg remove  package-name...
  unopkg list  package-name...
  unopkg reinstall 
  unopkg gui
  unopkg -V
  unopkg -h

sub-commands:
add add packages
remove  remove packages by name
reinstall   expert feature: reinstall all deployed packages
listlist information about deployed packages
gui raise Package Manager Graphical User Interface 
(GUI)


options:
-h, --help  this help
-V, --version   version information
-v, --verbose   verbose output to stdout
-f, --force force overwriting existing packages
--log-filecustom log file; default: /log.txt
--sharedexpert feature: operate on shared installation
deployment context;
run only when no concurrent Office
process(es) are running!
--deployment-contextexpert feature: explicit deployment context


For details concerning deployment and this tool, please read the developer's
guide: http://api.openoffice.org/DevelopersGuide/unopkg.html

bye

Mathias

Tobias Krais schrieb:

Hi together,

if I want to add a UNO Package I use the command:
unopkg add /tmp/myPackage.uno.pkg

But now only one user can use the package. How can I deploy the package
for all users?

Greetings, Tobias

-
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] Packaging process

[Janne Johansson]

2006/6/27, Éric Bischoff <[EMAIL PROTECTED]>:


Le Mardi 27 Juin 2006 10:10, Janne Johansson a écrit:
> > Any package maintainer listening here to confirm or denegate what I am
> > saying ? I used to work in a linux distribution, so I think I can
express
> > opinions on this topic, but some package maintainers might see that
> > differently.
>
> I am trying to fit OOo2 into our sourcebuilding packaging system, and I
> agree with your point.
> Having to go over rpms feels "stupid" in a way where not everything is
> meant to end up at
> /usr/local or where linux isn't necessarily implying you use (and like)
> rpms.
>
> If not for those reasons, then for the reason that zillions of other
> opensource products happen
> to have a "unpack ; configure ; make ; make install" routine well built
in
> into the spines of us builders.

For which distro are you facing those problems?



We have a multiplatform packaging system (though I dont expect OOo2 to
build for anything else than linux-x86)  called "buildit" which is a
collection
of shellscripts that automate the above procedure (unpack, conf...) and does
some dependency handling. It's very small, internal for us, but seems to
work
for the majority of normal apps that obey configure
--prefix=/somewhere/else.

Also, we are running our linuces on a small system for which we dont pull in
any
(except X11) dist-apps, but rather keep our own apps in versioned
directories
(like /pkg/tcsh/6.14.00/bin/tcsh) so we can keep parallell instances next to
each
other. This may or may not be the silliest idea since sliced bread but it
does
make it very visible which projects are relocatable "easily" and which want
everything
under /usr/{bin/lib/share}. OOo2 strikes me as a "you should have stuffed it
all
in one place because it breaks otherwise" when working on it.

There are so many points where the "unstandard" build style of OOo hits me.
Our build system naievely assumes "unpack ; patch ; prep (configure) ; build
; install"
works, but since OOo2 does unpack stuff after configure is run and don't
seem to
propagate configure-stuff to the newly unpacked configures, I seem to loose
out
on stuff. (libxmlsec gets a --without-openssl even though I gave the
toplevel an openssl
argument; pyuno gets a PYTHON_CFLAGS with -I/my/path/include but not a
PYTHON_LIBS with -L/my/path/lib)

And to actually get somewhere back to the original Q about the "dev" (or in
my case builder)
experience, I feel like it does copy lots of gifs and does zip magic on
dpzz's lots and lots
early on, making the turnaround times for figuring out which flags dont work
take a long while.
For me.

I've also found out "dmake -P3" makes it go "sleep 1" in a lot of subdirs
between builds.

--
Some mornings, it's just not worth gnawing through the straps...

Re: [dev] Linux: Deploying a UNO Package for all users on PC

[Steffen Grund]

Try

unopkg add --shared /your/package

to install for all users. See documentation on unopkg for details.

Regards, Steffen

Tobias Krais wrote:

Hi together,

if I want to add a UNO Package I use the command:
unopkg add /tmp/myPackage.uno.pkg

But now only one user can use the package. How can I deploy the package
for all users?

Greetings, Tobias

-
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] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)

[Rene Engelhard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Kay Ramme - Sun Germany - Hamburg wrote:
> >1) I think it just makes the life of OOo package maintainers in the Linux 
> >distributions much harder. I suppose that they basically rpm-install the 
> >OOo packages, and then repackage them. Or some might have come with the 
> >idea of short-circuiting the build process just before the packages are 
> >made and then simulate a "make install".

No, we added a simple installer mechanism upstream (Michael Meeks did,
thankfully)

> >Any package maintainer listening here to confirm or denegate what I am 
> >saying ? I used to work in a linux distribution, so I think I can express 

see above.

> AFAIK, the most prominent reasons for distributions to build OOo by 
> their own are
> - to not include or have any dependencies on non-free software (e.g. Java),
> - to optimize install sets by removing included 3rd party packages 
> (freetype, expat, etc.)
> - to patch it to be more compliant to the target distribution,
> - to change the look&feel, e.g. to replace some icons etc., or
> - to change target locations, e.g. to provide OOo as a bundled product.
- - fix bugs not fixed upstream for whatever reason

Exactly.

> >2) What about the distros that are not "officially supported"? Debian, 
> >Slackware, ...
> AFAIK, Debian is officially supported, the LSB recommended way is, to 
> provide RPMs and to use "alien" on Debian.

ROTL. Not everything the LSB says makes sense. The OOo build system
*has* support for building debs. Use this.

> >I think it's not the role of the software developpers to distribute the 
> >software, just like it's not the role of package maintainers to develop 
> >software. If they patch the code, normally they should contribute their 
> >patches back in IssueZilla.
> I tend to disagree here (see above :-), if all products / software would 
> be provided as packages by their developers, there would be far less 
> incompatibilities between the distributions, and one wouldn't need to 

Then you don't have experience with this. Sorry, but this is
completely wrong, and in any case you can't then add fixes either.
(see clophs post for example)

> wait until a particular distribution would provide the latest package of 
> a particular product ...

That's the distributions' issue.

Regards,

Rene
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEoRE7+FmQsCSK63MRAkjMAJ91PMEFACSQ6Cw6vJ/MW3wJWSXACwCdH/Gf
p8cWFPWsY1jKbYIu8WO9VsI=
=fhB2
-END PGP SIGNATURE-

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

Re: [dev] Packaging process

[Rene Engelhard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christian Lohmaier wrote:
> That is as getting all your software from Microsoft, one single
> "Distributor".

This comparison is shit.

> But on windows you can basically get every software from any vendor. If
> it is labeled "runs on windows XP", you can be pretty sure that it runs
> (despite the bugs it might have).

Just because they either are statically linked or ship every lib
they need because of the DLL-hell. wow.

> Now try to apply this to linux distributions. Get a package for SuSE and
> try to install that on Redhat. At best you can use --nodeps to ignore
> the different naming-schemes of the packages and it will run.
> But using switches to bypass deps or other things surely is not the best
> way on how a package management tool should work.

Well, your problem if you try to do that...

> The situation gets worse with older installations. There is no "linux
> version X" label you could specify. It most likely is "You need version
> X of glibc" (that is the reason why I cannot use most of the precompiled
> stuff that is offered, my version is just too old), "furthermore you

Which ancient stuff do you use? In any case, yes, then you need either
build it yourself or upgrade.
(Or install the new lib, which arguably in case of libc is not a good
idea)

> need $foo and $bar". $foo and $bar themselves require other packages or
> worse conflict with other packages. (think of sound-severs,
> desktop-environments,)

Sounds like a bug to me if packages for GNOME e.g. conflict against
KDE...

Regards,

Rene
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEoREi+FmQsCSK63MRAqJYAJ9ums4YCTi+z64xIm6zattmDP9WcgCfZkiV
feYGOAiQtwRzNbSLoYHAmCc=
=iaHN
-END PGP SIGNATURE-

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

[dev] Linux: Deploying a UNO Package for all users on PC

[Tobias Krais]

Hi together,

if I want to add a UNO Package I use the command:
unopkg add /tmp/myPackage.uno.pkg

But now only one user can use the package. How can I deploy the package
for all users?

Greetings, Tobias

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

Re: [dev] Packaging process

[Rene Engelhard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[ late answer, I needed time to *try* make my answer polite, sorry if that
doesn't happen all the time in this post, for the record I am one of the
two people making the Debian packages, currently the most active one of
both ]

Kay Ramme - Sun Germany - Hamburg wrote:
> >1) Suitability - Not all the Linux distributions follow the same purposes. 
> >Some are for desktop users, some are for generic servers, some are for 
> >specialized purposes like firewalls, application servers or clustering. 
> >Some try to imitate Windows or Mac OS X, some try to get away from other 
> >OSes as much as they can. A lot of changes are made to give personality to 
> >the distributions.
> That does not necessarily mean, that they need to patch or change 
> anything in the provided products, does it? At least OOo provides 
> extensive configurability to actually change everything, without needing 
> to alter a single line of code.

Of course that does. There's bugs in OOo. Bugs need to be fixed.
Distributions and OOo have different release schedules. Or: You have
some additions you *need* for whatever reasons.

And you don't build some of the optional stuff.
You have various UNFIXED security things open (Mozilla to name the most
prominent one).

In any case, it is a no-no for a Linux distri to ship binaries you just
got.

And not everything is configurable...

> >2) Coherence - A Linux distribution is a coherent set of software. Even if 
> >documents like FHS and LSB state a lot of things, like the place where 
> >files should go, there's room for a lot of variations. As long as the 
> >various choices are coherent within the same distribution, that's okay. A 
> >lot of changes here and there attempt to have all software follow common 
> >conventions.
> I think you hit the point here, IMHO Linux does not only need to be 
> coherent inside the distributions, but also _overall_ ...

Yes, but it also needs coherency inside the distro.
That also means that you don't need to ship every lib inside the
package, bloating it for example. Or you have to integrate with
distro-specifics (like sensible-browser, run the browser you have
choosen system-wide in the env or set with the BROWSER envvar, just for
example, that's a minor one).

Or take pyuno. You need a internal python and can't use the systems'
python modules, not to mention the stuff isn't simply usable by the
systems' normal python.

> >3) Corrections - A lot of the work is made to fix problems in the packaged 
> >software itself. Why are such changes not done upstream at the initial 
> >software projects? They are done upstream too, but since it's a much 
> >slower process than a quick fix in the distribution, upstream corrections 
> >are done usually much after the distribution is in the retail stores.
> This is understood, but is IMHO the wrong approach and really should be 
> the exception, I think at least we at OOo are very willing to support 
> the distributions to get their fixes merged in upstream.

LOL. I have many counterexamples here where bugs ARE NOT GETTING FIXED
after submitted.
I can look for them.

And anyway, you have an other release schedule than distributions. How
is a distribution supposed to backport bugfixes for their next release
if there's only binaries you ship and have to wait for a new OOo release
(which might not fix those bugs after all) although the distris deadline
is earlier?

> >In short: I suppose you bring a big problem to distributors by bringing 
> >already packaged software.
> I think I disagree again, as you said, distros may just install and 
> repackage OOo. IMHO, the most prominent reason for repackaging is to 
> change OOo to be a "bundled" product, while the packages we are 
> providing are "unbundled". The point being, that there IMHO is _no_ real 
> or good reason to have products (applications) to be "bundled", except 
> that this is what distros do.

No, the reason is that shipping binaries is bad. Every distro rebuilds
from source. What if a security thing pops up? You didn't care or issue
updates for the last issues (neon, curl, mozilla, ...) for libraries you
use..
What if you need to fix bugs *before* a new version of OOo comes out
upstream?

> >Again, I am not working for a Linux distribution anymore, so that's mostly 
> >a guess of mine. Perharps someone can tell whether that's correct or not 
> >in his/her case.
> Any distros listening?

Yes. me. (Debian)

> >I will cowardly let the Debian guys answer this ;-).
> Yes, Debianists, please comment ...

I'll do.
That's complete bullshit.

Debian (and it's derivatives) is a distribution like everyone else -
dpkg/deb even was there *before* rpm afaik. Even if not, Debian should be
natively supported, not though alien'ized packages which can have arbritrary 
amounts
iof bugs through conversion.
There *is* support for Debian in your build system, but you don't enable it...
(Or you at least don't publish the resulting files for deb 

Re: [dev] Pitfall using VCL focus handler and virtual methods GetFocus/LoseFocus

[Philipp Lohmann - Sun Germany]

Frank Schönheit - Sun Microsystems Germany wrote:

There is even a event listener mechanism for dying windows.


Which also doesn't help, since it's also triggered from Window::~Window
only - which is too late, since a lot of destruction already happens
before this in the derived class.


Bullshit. The object dying notifies you that it gets destroyed and you 
still cannot refrain from using it ? Maybe that's just me, but i would 
call THAT a destructive attitude ;-)


Kind regards, pl

--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
 -- Author unknown

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

Re: [dev] Changing the default Java for OOo from command line

[Tobias Krais]

Hi Joachim,

> unopkg does not seem to accept bootstrap variables on the command line.
> This could be a bug. You could still set the variable as environment
> variable. For example
> setenv  UNO_JAVA_JFW_JREHOME file:///usr/lib/jvm/java-1.5.0-sun-1.5.0.06/
> 
> unopkg add ...

OK. I used:
-%<-
export UNO_JAVA_JFW_JREHOME="file:///usr/lib/jvm/java-1.5.0-s
un-1.5.0.06/"

export UNO_JAVA_JFW_CLASSPATH="/usr/lib/openoffice/program/classe
s/jurt.jar;/usr/lib/openoffice/program/classes/ridl.jar;/usr/lib/openoffice/prog
ram/classes/java_uno.jar;/usr/lib/openoffice/program/classes/juh.jar;/usr/lib/op
enoffice/program/classes/jut.jar;/usr/lib/openoffice/program/classes/unoidl.jar"

export UNO_JAVA_JFW_ENV_CLASSPATH="/usr/lib/openoffice/program/classes/j
urt.jar;/usr/lib/openoffice/program/classes/ridl.jar;/usr/lib/openoffice/program
/classes/java_uno.jar;/usr/lib/openoffice/program/classes/juh.jar;/usr/lib/openo
ffice/program/classes/jut.jar;/usr/lib/openoffice/program/classes/unoidl.jar"

unopkg add ./CVS-Temp/OOComNG/oocom/unopkg/JudasSaveToComponent.uno.pkg

ERROR: (com.sun.star.uno.RuntimeException) { { Message = "[jni_uno
bridge error] UNO calling Java method initialize: non-UNO exception
occurred: java.lang.UnsatisfiedLinkError: dispatch_call\X000ajava stack
trace:\X000ajava.lang.UnsatisfiedLinkError: dispatch_call\X000a\X0009at
com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native
Method)\X000a\X0009at
com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java)\X000a\X0009at
$Proxy3.queryInterface(Unknown Source)\X000a\X0009at
com.sun.star.uno.UnoRuntime.queryInterface(UnoRuntime.java)\X000a\X0009at
com.sun.star.uno.AnyConverter.convertSimple(AnyConverter.java)\X000a\X0009at
com.sun.star.uno.AnyConverter.toObject(AnyConverter.java)\X000a\X0009at
com.sun.star.comp.loader.JavaLoader.initialize(JavaLoader.java)\X000a",
Context = (com.sun.star.uno.XInterface) @0 } }
-%<-

As far as I tested, I am very sure unopkg uses the given JRE. But
something seems still missing. If I set the JRE with the GUI and then
start unopkg, it works (only in an other shell without the exports).

Can you tell me what is missing for unopkg?

Greetings, Tobias

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

Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)

[Kay Ramme - Sun Germany - Hamburg]

Janne,

Janne Johansson wrote:


If not for those reasons, then for the reason that zillions of other
opensource products happen
to have a "unpack ; configure ; make ; make install" routine well built in
into the spines of us
builders.
In general, it shouldn't be to hard to support the "classic" Linux 
approach as well.








Kay

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

Re: [dev] Pitfall using VCL focus handler and virtual methods GetFocus/LoseFocus

[Frank Schönheit - Sun Microsystems Germa ny]

Hi Philipp,

> This is based on the fact that the Window destructor does a Hide() 
> before setting the focus to somewhere else.

But this won't help. Window::~Window has not yet been called. In
Carsten's example, MyTabPage::~MyTabPage is just being called, and it's
just about to destroy its members, in particular m_aEdit1. At this
point, the MyTabPage instance is still visible.

> You can of course implement
> your own method to ensure that you do not access objects that are 
> already destroyed.

That's the point: I don't like all of us implementing own methods :)

> There is even a event listener mechanism for dying windows.

Which also doesn't help, since it's also triggered from Window::~Window
only - which is too late, since a lot of destruction already happens
before this in the derived class.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Database   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

Re: [dev] Packaging process

[Kay Ramme - Sun Germany - Hamburg]

Éric,

Éric Bischoff wrote:


No. I usually do my "make install"s as root, but that's not necessary. You can 
"make install" to your home directory if you wish. There's a configure flag 
named "--prefix" for that.

Did not know that, thanks.



And yes, I know that this is a sensitive topic to discuss ...


Yes, and unfortunately sensitive topics usually produce unproductive 
discussions ;-).
Despite this, anybody interested in the "make install" thing may provide 
a patch for supporting this. I can put this on my list of open points as 
well, or we may ask Kai Backmann (are you listening?) to put this on his 
build environment revision project.



- this could very well be one of the most prominent reasons for Windows
success in both worlds, the open source world and the commercial world.
And I want Linux to be successful in both (or more) worlds as well.


Not sure about what you say, but in any case doing both ways does not 
hurt... ;-).

Agreed.



Thanks for your explanations and comments, I am enjoying the discussions
... :-)


"me too" ;-)

Thanks for your openess.



Kay

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

[dev] xorg upgrade degrades Times New Roman rendering?

[D. Sen]

I just upgraded my X server from xorg 6.7 to xorg 7.0. While everything
else seems to work fine, the Times-New-Roman rendering with openoffice
seems to have degraded somewhat. I am using openoffice 2.0.2. The
following link is a screenshot comparing Times-New-Roman rendering using
openoffice 2.0.2 and 1.1.3 (on the same X server).

http://deeps.ee.unsw.edu.au:9366/~dsen/screen.tif

Other problems I have noticed are:
a) The font family "Symbol" shows up blank on the screen.
	b) The greek symbols using "insert special characters" using Times New 
Roman, while showing up on the screen does not render when export the 
document to PDF.


Is there a way to fix this?

So far I have tried the following:

1) Downgrading the freetype library to 2.1.7 from 2.1.9. This didnt 
improve or change anything.


2) I have also tried using export 
LD_PRELOAD=/usr/lib/xorg/modules/fonts/libfreetype.so
(according to the suggestion in 
http://wiki.archlinux.org/index.php/Fonts_FAQ). However, this results in 
failing to launch openoffice with the message:


ls: symbol lookup error: 
/usr/xorg_7.1/lib/xorg/modules/fonts/libfreetype.so: undefined symbol: 
FreeTypeRegisterFontFileFunctions




Thanks,
DS

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

Re: [dev] Packaging process

[Éric Bischoff]

Le Mardi 27 Juin 2006 10:10, Janne Johansson a écrit :
> > Any package maintainer listening here to confirm or denegate what I am
> > saying ? I used to work in a linux distribution, so I think I can express
> > opinions on this topic, but some package maintainers might see that
> > differently.
>
> I am trying to fit OOo2 into our sourcebuilding packaging system, and I
> agree with your point.
> Having to go over rpms feels "stupid" in a way where not everything is
> meant to end up at
> /usr/local or where linux isn't necessarily implying you use (and like)
> rpms.
>
> If not for those reasons, then for the reason that zillions of other
> opensource products happen
> to have a "unpack ; configure ; make ; make install" routine well built in
> into the spines of us builders.

For which distro are you facing those problems?

-- 
Si on ne peut pas toujours compter sur ses amis, on peut toujours compter son 
or.
(Donjon de Naheulbeuk)

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

Re: [dev] Packaging process

[Éric Bischoff]

Le Mardi 27 Juin 2006 09:57, Kay Ramme - Sun Germany - Hamburg a écrit :
> > Yup. In my honest opinion, if you really want to build packages, it
> > should be done the regular way, on top of a "make install".
>
> That implicits, to be able to work as root on a dedicated machine, while
> only wanting to develop OOo ...

No. I usually do my "make install"s as root, but that's not necessary. You can 
"make install" to your home directory if you wish. There's a configure flag 
named "--prefix" for that.

> And yes, I know that this is a sensitive topic to discuss ...

Yes, and unfortunately sensitive topics usually produce unproductive 
discussions ;-).

> - this could very well be one of the most prominent reasons for Windows
> success in both worlds, the open source world and the commercial world.
> And I want Linux to be successful in both (or more) worlds as well.

Not sure about what you say, but in any case doing both ways does not 
hurt... ;-).

> Thanks for your explanations and comments, I am enjoying the discussions
> ... :-)

"me too" ;-)

Thanks for your openess.


-- 
Si on ne peut pas toujours compter sur ses amis, on peut toujours compter son 
or.
(Donjon de Naheulbeuk)

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

Re: [dev] Packaging process

[Éric Bischoff]

Le Lundi 26 Juin 2006 21:33, Christian Lohmaier a écrit :
> ? The user doesn't have to bother. Either they use the packages provided
> by $distribution or they take the packages from vanilla OOo.
>
> And the packagers who are doing the packages for their distribution
> should know how to unpack something or how to compile from source.
>
> I absolutely do not get your point.

My point is : why make it unnatural and complicated when you can do it in the 
normal, regular way? The normal, regular way is to package software that 
installs with "make install".

Currently, if distributions want to do serious changes in OOo, they have to 
learn the whole build mechanism, scp2 bits, etc, to finally build a package 
that they will disassemble right away. Of course they can learn how to do 
that, it's just unusual, since no other software than OOo goes that way.

I will stop discussing that here. After all, I am not a package maintainer 
(anymore) so I am not representative enough to sustain this discussion.


> You can use linkoo to create an installation out of your build-dir.

I did not know that. So that would be equivalent to a "make install"? Where is 
that documented?


> > I install my distribution, and all software works smoothly together.
>
> That is as getting all your software from Microsoft, one single
> "Distributor".

Okay, that piece of discussion is unrelated to main topic. It is even 
completly off-topic ;-) but interesting, so let's continue with that. 
Perharps in private if it bothers the others.

Yes, you are right. That's like getting all your software from Microsoft. But 
there are a few differences that make a lot of importance (caution, troll 
included):

1) In fact, many companies _do_ get all their software from Microsoft, putting 
themselves in a state of strategic dependancy.

2) The software in your Linux distribution has not been written by the 
distributor...

3) You have the choice of your distributor. There's real concurrence.

4) A Linux distribution contains almost all the software you might need, it's 
seldom needed to look outside of your distro.

5) With Microsoft you cannot adapt the software to your needs. You have not 
the source.

> Now try to apply this to linux distributions. Get a package for SuSE and
> try to install that on Redhat.

No one does that. Software is coherent within ONE distribution.

Listen, that's two different approaches. Why not just admit that it's 
different philosophies, with both their advantages and drawbacks?

And, returning to main topic, why try to import into Linux a packaging 
philosophy that is adapted to Windows?


-- 
Si on ne peut pas toujours compter sur ses amis, on peut toujours compter son 
or.
(Donjon de Naheulbeuk)

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

Re: [dev] Pitfall using VCL focus handler and virtual methods GetFocus/LoseFocus

[Philipp Lohmann - Sun Germany]

Carsten Driesner wrote:

Frank Schönheit - Sun Microsystems Germany wrote:

I'm not sure I understand how this helps in your scenario? Is MyWindow
really already invisible while it is in its destructor?


Hi Frank,

I talked with Philipp about these problems and he suggested the solution 
with IsInvisible() for non-handler implementations. MyWindow must be 
invisible while it's in its destructor, otherwise the solution cannot 
work. Maybe Philipp can give us more information.


This is based on the fact that the Window destructor does a Hide() 
before setting the focus to somewhere else. You can of course implement 
your own method to ensure that you do not access objects that are 
already destroyed. There is even a event listener mechanism for dying 
windows.


Kind regards, pl

--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
 -- Author unknown

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

Re: [dev] Pitfall using VCL focus handler and virtual methods GetFocus/LoseFocus

[Carsten Driesner]

Frank Schönheit - Sun Microsystems Germany wrote:

Hi Carsten,

we have just found a nasty pitfall in one of our tab pages, which lead 
to memory corruption. We needed about one week to track down this issue, 
so I hope that someone else can profit from our findings.

...



If one uses the virtual methods at the Window class
virtual void GetFocus();
virtual void LoseFocus();
Philip Lohmann (VCL project lead) suggests to use IsVisible() before 
executing code in the method.


void MyWindow::GetFocus()
{
 if ( IsVisible() )
 {
 // Do something usefull
 }
}


I'm not sure I understand how this helps in your scenario? Is MyWindow
really already invisible while it is in its destructor?


Hi Frank,

I talked with Philipp about these problems and he suggested the solution 
with IsInvisible() for non-handler implementations. MyWindow must be 
invisible while it's in its destructor, otherwise the solution cannot 
work. Maybe Philipp can give us more information.


I am not completely sure that the above code can help in all cases. I 
can think of the following scenario:

- creating a dialog invisible
- set the focus to the initial control
- make the dialog visible
Here the handler/method could correctly work, but due to IsInvisible() 
won't.
The search using lxr for SetGetFocusHdl should just show if this is a 
minor problem or not (I think not). You're right that other scenarios 
using VCL focus handler/virtual GetFocus/LoseFocus methods are possible 
which can also result in memory corruption/crashes.


Nevertheless I think we have a real problem with this pitfall and we 
should proactive check our code. I had to spent about one week to find 
the root cause for the memory corruption. The bug itself was part of OOo 
for more than 6 years.


Carsten

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

Re: [dev] Will OOo version 3 preserve backwards file compatibility with OOo 2 ?

[Kay Ramme - Sun Germany - Hamburg]

Hi David,

David Wilson wrote:
Can anyone advise us as whether OOo version 3 will preserve backwards  file 
compatibility with OOo 2 ? Has this matter been decided yet, or does the 
major release number mean that compatibility does not need to be conserved ?
the '3' more or less is a marketing version only. Their are AFAIK no 
planned incompatibilities for any next minor or major version.
And we certainly will stay compatible to our main file format (ODF), 
while compatibility for older formats (e.g. StarOffice versions up to 
5.2) may become optional or vanish one day ...


In designing the bibliographic enhancements the Bibliographic Project is 
discussing the issue of backwards file compatibility.  The Bibliographic 
Project is hoping to see major enhancements to Citation and Bibliography 
support in OOo version 3 (if not before).
Does that mean, that you need the file format to become incompatible? I 
thought that support for bibliographic extensions would be optional only.


The OpenDocument file format version 1.2, due sometime in 2007, will included 
improved citation and metadata support and we are working out how Writer can 
best utilise these enhancements, as well as implementing our improved 
citation and bibliography formatting process, called CiteProc.

I heard of that ... :-)


If we need to maintain backwards file compatibility between OOo versions 2 and 
3 then we would need to maintain the old and the new citation and 
bibliography definition in the save file. If we are not maintaining backwards 
file compatibility then the design is much simpler in Writer as the import / 
export filters will handle the conversions.
Optional features may not be supported in older versions, though a 
replacement image would be nice. But, Michael Brauer is the expert and 
may comment on this ...







regards

David


Kay

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

Re: [dev] Packaging process (Was: Re: [dev] Survey - OpenOffice.org Developer Feedback Needed)

[Janne Johansson]

2006/6/26, Éric Bischoff <[EMAIL PROTECTED]>:


Le Lundi 26 Juin 2006 15:47, Kay Ramme - Sun Germany - Hamburg a écrit:
> > - OOo should not attempt to build its own packages, at least under
Linux.
> >   Under Linux, that's the distributions' work!
> >   This problem is related to the "make install" one.
>
> In my opinion, OOo is showing the right approach here, it is IMHO
> unfortunate and a waste of time, that everybody patches and builds
> everything by its own, leading to small incompatibilities and bugs here
> and there ...

Okay, we have diverging opinions on this point ;-).


1) I think it just makes the life of OOo package maintainers in the Linux
distributions much harder. I suppose that they basically rpm-install the
OOo
packages, and then repackage them. Or some might have come with the idea
of
short-circuiting the build process just before the packages are made and
then
simulate a "make install".

Any package maintainer listening here to confirm or denegate what I am
saying ? I used to work in a linux distribution, so I think I can express
opinions on this topic, but some package maintainers might see that
differently.



I am trying to fit OOo2 into our sourcebuilding packaging system, and I
agree with your point.
Having to go over rpms feels "stupid" in a way where not everything is meant
to end up at
/usr/local or where linux isn't necessarily implying you use (and like)
rpms.

If not for those reasons, then for the reason that zillions of other
opensource products happen
to have a "unpack ; configure ; make ; make install" routine well built in
into the spines of us
builders.





--
Some mornings, it's just not worth gnawing through the straps...

Re: [dev] Packaging process

[Kay Ramme - Sun Germany - Hamburg]

Éric,

Éric Bischoff wrote:

I - "Good" reasons

1) Suitability - Not all the Linux distributions follow the same purposes. 
Some are for desktop users, some are for generic servers, some are for 
specialized purposes like firewalls, application servers or clustering. Some 
try to imitate Windows or Mac OS X, some try to get away from other OSes as 
much as they can. A lot of changes are made to give personality to the 
distributions.
That does not necessarily mean, that they need to patch or change 
anything in the provided products, does it? At least OOo provides 
extensive configurability to actually change everything, without needing 
to alter a single line of code.


2) Coherence - A Linux distribution is a coherent set of software. Even if 
documents like FHS and LSB state a lot of things, like the place where files 
should go, there's room for a lot of variations. As long as the various 
choices are coherent within the same distribution, that's okay. A lot of 
changes here and there attempt to have all software follow common 
conventions.
I think you hit the point here, IMHO Linux does not only need to be 
coherent inside the distributions, but also _overall_ ...


3) Corrections - A lot of the work is made to fix problems in the packaged 
software itself. Why are such changes not done upstream at the initial 
software projects? They are done upstream too, but since it's a much slower 
process than a quick fix in the distribution, upstream corrections are done 
usually much after the distribution is in the retail stores.
This is understood, but is IMHO the wrong approach and really should be 
the exception, I think at least we at OOo are very willing to support 
the distributions to get their fixes merged in upstream.



II - "Bad" reasons

4) Not invented here - We all think that we have better ideas than our 
neighbours, so we want them our way. Distribution makers just follow the same 
behaviour because they have an ill ego just like every computer scientist.

Yeah, I know that feeling too ;-), but try to be steady ...




IMHO, "Coherence" and "Suitability" can be addressed independent of 
patching / rebuilding / packaging software products.
Non-Coherence over distributions is one of the biggest obstacles ISVs, 
and I count OOo or Mozilla as ISVs, face when supporting Linux. LSB is 
actively trying to address this, unfortunately with varying success. I 
did visit the last DAM (Desktop Architects Meeting) in Mainz (organized 
by the OSDL), and we did talk a lot about this, so I am not yet sure, 
that we have any real outcomes ... ;-)


In short: I suppose you bring a big problem to distributors by bringing 
already packaged software.
I think I disagree again, as you said, distros may just install and 
repackage OOo. IMHO, the most prominent reason for repackaging is to 
change OOo to be a "bundled" product, while the packages we are 
providing are "unbundled". The point being, that there IMHO is _no_ real 
or good reason to have products (applications) to be "bundled", except 
that this is what distros do.




Again, I am not working for a Linux distribution anymore, so that's mostly a 
guess of mine. Perharps someone can tell whether that's correct or not in 
his/her case.

Any distros listening?




I will cowardly let the Debian guys answer this ;-).

Yes, Debianists, please comment ...




Yup. In my honest opinion, if you really want to build packages, it should be 
done the regular way, on top of a "make install".
That implicits, to be able to work as root on a dedicated machine, while 
only wanting to develop OOo ...






if all products / software would 
be provided as packages by their developers, there would be far less

incompatibilities between the distributions,


Well, there would be no distributions at all ;-)...
So, you are right, that is what I personally concluded several times, 
when thinking about the subject. And yes, I know that this is a 
sensitive topic to discuss ...




... and we would have the DLL conflicts nightmare in Linux too (see 
"Coherence" paragraph) ;-).
So, we already have that par excellence ... :-(. Exactly this is the 
reason, why we (being an ISV) have to bring all this 3rd party stuff by 
our own, basically being a kind of a mini distro on Linux.




and one wouldn't need to 
wait until a particular distribution would provide the latest package of

a particular product ...


That's the Windows way, not the Linux way.

Two points here,
- being different just to be different (without good technical reasons) 
is IMHO stupid,
- this could very well be one of the most prominent reasons for Windows 
success in both worlds, the open source world and the commercial world.

And I want Linux to be successful in both (or more) worlds as well.




Thanks for your explanations and comments, I am enjoying the discussions 
... :-)


Kay

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

Re: [dev] Pitfall using VCL focus handler and virtual methods GetFocus/LoseFocus

[Frank Schönheit - Sun Microsystems Germa ny]

> SomeWindow::SomeWindow()
> {
>   DELETEZ( m_pBar );
>   DELETEZ( m_pFoo );
>   // note: less obvious versions of this use a
>   // ::std::auto_ptr< Control > for both m_pFoo and m_pBar, which makes
>   // the issue harder to spot
> }

should have been SomeWindow::~SomeWindow, of course

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Database   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

Re: [dev] Pitfall using VCL focus handler and virtual methods GetFocus/LoseFocus

[Frank Schönheit - Sun Microsystems Germa ny]

Hi Carsten,

> we have just found a nasty pitfall in one of our tab pages, which lead 
> to memory corruption. We needed about one week to track down this issue, 
> so I hope that someone else can profit from our findings.
> ...

> If one uses the virtual methods at the Window class
> virtual void GetFocus();
> virtual void LoseFocus();
> Philip Lohmann (VCL project lead) suggests to use IsVisible() before 
> executing code in the method.
> 
> void MyWindow::GetFocus()
> {
>  if ( IsVisible() )
>  {
>  // Do something usefull
>  }
> }

I'm not sure I understand how this helps in your scenario? Is MyWindow
really already invisible while it is in its destructor?

> I generated the following list with lxr from SRC680m172 with 
> "SetGetFocusHdl".

There's more issues with this VCL behavior than only focus handler
links. For instance consider the following

class SomeWindow : public Window
{
  Control* m_pFoo;
  Control* m_pBar;

  virtual void GetFocus();
};

SomeWindow::SomeWindow()
  :m_pFoo( new Control( this ) )
  ,m_pBar( new Control( this ) )
{
  // note that ( m_pFoo != NULL ) && ( m_pBar != NULL ) is an invariant
  // of the class
}

SomeWindow::SomeWindow()
{
  DELETEZ( m_pBar );
  DELETEZ( m_pFoo );
  // note: less obvious versions of this use a
  // ::std::auto_ptr< Control > for both m_pFoo and m_pBar, which makes
  // the issue harder to spot
}

SomeWindow::GetFocus()
{
  // simply delegate
  m_pBar->GrabFocus();
}


Now when the window gets destroyed while its m_pFoo has the focus, then
VCL will, upon destruction, move the focus to the parent, i.e. the
SomeWindow instance. This will attempt to delegate the focus to m_pBar,
which is already dead.


The commonality of your and my scenario (which I in fact encountered
quite a lot already) is that some GetFocus handler (either the virtual
method or the link) is called while the instance at which it's called is
in midst of its destruction.

I'm pretty sure one could find more scenarios where this causes
problems, so I'd appreciate a more general solution. Though, admittedly,
I can't think of one right now ...

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems  http://www.sun.com/staroffice -
- OpenOffice.org Database   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

[dev] Will OOo version 3 preserve backwards file compatibility with OOo 2 ?

[David Wilson]

Can anyone advise us as whether OOo version 3 will preserve backwards  file 
compatibility with OOo 2 ? Has this matter been decided yet, or does the 
major release number mean that compatibility does not need to be conserved ?

In designing the bibliographic enhancements the Bibliographic Project is 
discussing the issue of backwards file compatibility.  The Bibliographic 
Project is hoping to see major enhancements to Citation and Bibliography 
support in OOo version 3 (if not before).

The OpenDocument file format version 1.2, due sometime in 2007, will included 
improved citation and metadata support and we are working out how Writer can 
best utilise these enhancements, as well as implementing our improved 
citation and bibliography formatting process, called CiteProc.

If we need to maintain backwards file compatibility between OOo versions 2 and 
3 then we would need to maintain the old and the new citation and 
bibliography definition in the save file. If we are not maintaining backwards 
file compatibility then the design is much simpler in Writer as the import / 
export filters will handle the conversions.

For more details see - 
http://wiki.services.openoffice.org/wiki/Writer_enhancements_for_OOBib#Backwards_and_Forwards_Compatibility


regards

David
-- 
---
David N. Wilson
Co-Project Lead for the Bibliographic 
OpenOffice Project
http://bibliographic.openoffice.org

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

[dev] Enhance the Text-Field or Bookmark functions to include formatted text

[David Wilson]

I would like to enter an issue to enhance database and text fields to support 
formatted text. 

The Bibliographic project wants this enhancement because some data fields in 
the bibliography need to support formatted text. For example some scientific 
document titles need to be able to display words in Italics. Mathematical 
titles need to represent equations.  Currently fields can only hold 
unformatted text.

This enhancement would would  be of wider interest than just to the 
Bibliographic project.

Oliver Specht has suggested that there are two ways in which this might be 
achieved - to enhance the text-field, or by enhancing bookmarks. (I have 
quoted his comments below.)

I would like to get some discussion on this topic and to determine which is 
the better approach.

regards

David

=

In discussing how to achieve formatted text in fields, Oliver Specht 
<[EMAIL PROTECTED]>, wrote the following - 

"The Writer has two possible content types that could be extended to support 
the citation element (and other elements generically) 
The first is the text field (com.sun.star.text.TextField). A generic field 
service could be added to the API of the Writer that would have a property 
that contains a DOM tree. This DOM tree contains the citation-element. The 
bibliography creates the DOM tree of those fields and inserts them into the 
text together with a string that contains the presentation text. 
Such fields can only be formatted as a whole. It is not possible to have e.g. 
parts of this presentation printed in bold. This text can not be spanned over 
paragraphs. The text cannot be changed manually. 

Another possible solution is to add a new object that is similar to bookmarks 
(com.sun.star.text.Bookmark). This extended bookmark would also carry a DOM 
tree property. This 'bookmark' can span over formatted text longer than a 
paragraph. The user can modify the text inside of this bookmark easily. 
In both cases an interface to access the new elements needs to be implemented 
(sorted by document position). 
The DOM interfaces are in com.sun.star.xml.dom. (e.g. XDocument.idl, 
XNode.idl, XElement.idl) 

There's also a service com.sun.star.xml.dom.DocumentBuilder available that 
supports the creation of DOM trees. 

The bibliography component works on the DOM tree and can manipulate it 
independently. In case of using a field the component has to set the 
resulting string representation of the reference at this field. 
Using the field is a bit easier and using the bookmark is more powerful." 

This issues is also detailed at the wiki address below. The wiki page has web 
links to some of the relevant api and DOM descriptions.

http://wiki.services.openoffice.org/wiki/Writer_enhancements_for_OOBib#Enhanced_Field_or_Bookmark_Function_to_Include_Formatted_Text

Regards

David
-- 
---
David N. Wilson
Co-Project Lead for the Bibliographic 
OpenOffice Project
http://bibliographic.openoffice.org

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