[dev] Fwd: CHANGE TEXT IN OO

2007-02-02 Thread mellannie rachelle reyes

-- Forwarded message --
From: mellannie rachelle reyes <[EMAIL PROTECTED]>
Date: Jan 27, 2007 2:01 AM
Subject: CHANGE TEXT IN OO
To: dev@sw.openoffice.org, dev@openoffice.org, users@openoffice.org

Good day sir/mam

Im mellannie again and thank you for your past replies regarding my
questions on Add-on. Currently we already had an add-on but there was a
problem, well our program should be able to identify if there were errors in
a particular grammar by clicking the add-on menu that we created, a dialog
box will appear to search for errors from the text in the OOo writer
document, in the dialog box when an error was detected it will then suggest
a sentence that is better than the original, however we do not know how will
we be able to also change the text written in the OOo writer when the change
button of the dialog box was clicked.

If possible we would like to know if you have a simple begginer's code for
changing the OOo text (when typed) to replce the original sentence into a
new one.

Your answers will be greatly apprecatiated.

Thank You.


[dev] Roundup extension packages for scripting engines ... (Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respectiv

2007-02-02 Thread Rony G. Flatscher
Hi Stephan,

after further experimentations a synopsis:

* In order to install a scripting package under OOo one needs to
  supply a jar-file according to the scripting framework specs
  o if all parts are Java then adding all needed classes to that
jar-file should be sufficient
* Fo a scripting language that is not implemented in Java in
  addition to the Java plug-in code one needs (example is ooRexx) to
  deploy
  o native (non-UNO) libraries (on [D]PATH, LD_LIBRARY_PATH),
  o a JRE to bridge Java and the non-Java scripting language (on
CLASSPATH),
  o native (non-UNO) binaries resp. text-files that are script
modules which need to be accessible as if they were placed
along the PATH.

At the moment this is not possible. Also the OOo scripting framework
needs a MANIFEST.MF in a predefined form.

Finally, being able to package and deploy scripts in any scripting
language that can be used for OOo would be important as well.

Regards,

---rony




Re: [dev] Extending the binfilter Module

2007-02-02 Thread Mathias Bauer
Rüdiger Timm schrieb:

> binfilter isn't static. During the last months even more code has been 
> moved from f.e. sw into binfilter.

Yes. Because we discovered even more filters we don't want to maintain
anymore. :-)

>> I think the problem is that you can't give a fixed order for 2,3 and 4.
>> This must be checked for every single case. Perhaps Kay should point
>> this out in the wiki.
> OK, accepted. But from my point of view we should not make 'move more 
> basic code into binfilter' (2 or 3) a default before 'adapt binfilter to 
> the changes' (4). I even doubt that (4) in general is more effort than (3).

Agreed. Perhaps we should give all three options the same priority and
make it clear that it is an individual decision based on trade-off
considerations.

Ciao,
Mathias

-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[EMAIL PROTECTED]".
I use it for the OOo lists and only rarely read other mails sent to it.

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



Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?

2007-02-02 Thread Rony G. Flatscher
Hi Stephan,

thank you very much for your answers!

... cut ...

> * ad "application/vnd.sun.star.uno-component;type=native":
>
> No, such files are not put on any path.  If those libraries are UNO
> libraries that support services/singletons, they will be found by the
> UNO framework via the information recorded at deployment time.  If
> those libraries are used by other libraries, those libraries must make
> sure to find them (e.g., via RPATH on ELF platforms).

Hmm, in the case of the ooRexx scripting engine:

* there is a platform dependent DLL/so which needs to be accessible
  (at the moment I copy it into "OOoHome/program"), so the library
  is *not* an UNO-component, just a native library,
* there are three text files (actually ooRexx programs) named
  BSF.CLS, UNO.CLS, UNO_XINTERFACES.REX which also need to be
  accessible by ooRexx scripts (and for that reason I have to copy
  them into "OOoHome/program".

Is there a means with the extension package manager (via a
"manifest:media-type") to cause these files to be either made accessible
via [D]PATH/LD_LIBRARY_PATH and PATH, or have a means available to tell
the package manager where to copy these files in the standard OOo
installation tree in a platform independent manner)?

Regards,

---rony



Re: [dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?

2007-02-02 Thread Stephan Bergmann

Rony G. Flatscher wrote:

Hi Stephan,

Feel free to come back here with any questions along your way,

Thank you very much for your kind offer!

Indeed, after studying your information there would be a couple of
questions:

* where would one find the full definition for "manifest.xml" and a
  list of valid "mainfest:media-type"s; I looked in the developers
  guide and tried the search function of the Wiki, but have not been
  really able to locate it?


Maybe its only in the code.  :(  But I do not know, maybe Jochen knows 
more.  Jochen???



* also, where would one be able to find the full definition for the
  "description.xml" file?
  o ad version numbers: would something like "2.1.0.20070202" or
"210.20070202" be o.k. (according to the production rule it
should be possible) or would that pose any problems (the
date of the version is the trailing value, possibly
supplemented with the time of the day like "210.20070202162200")


The authoritative definition of version numbers is 
. 
 All your examples above would be valid version numbers.  However, the 
TODO at desktop/source/deployment/misc/dp_version.cxx:1.3 l. 53 suggests 
to only use segments for now that represent integers < 2^63.  ;)



* ad "application/vnd.sun.star.uno-component;type=native":
  o This can be used to not only denote libraries, but also
executables and modules (or with other words: these files
will be put into a place that is accessible via the PATH
settings?)


No, such files are not put on any path.  If those libraries are UNO 
libraries that support services/singletons, they will be found by the 
UNO framework via the information recorded at deployment time.  If those 
libraries are used by other libraries, those libraries must make sure to 
find them (e.g., via RPATH on ELF platforms).



  o Is there a complete list somewhere of the operating system
dependent strings? The extension document mentions
"Windows", "Linux_x86", "Solaris_SPARC". So what about PPC
versions of Linux or Intel versions of Solaris or PPC and/or
Intel versions of MacOSX?


Again, maybe its only in the code.  Again, maybe Jochen knows more.


* is there a possibility to copy a set of scripts (in any available
  scripting language) to the user and/or shared script repository?
  If possible, what would be the appropriate "manifest:media-type"
  entry?
  o Of course this may pose a little problem when using the
update feature, as such scripts could have been edited in
the meantime by the users (but then one could resolve this
by moving the existing/edited extension scripts to an own
backup library)


Sorry, I have no experience with those things.  Hopefully, somebody else 
can step in.


-Stephan


TIA,

---rony


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



[dev] Working on PyUno

2007-02-02 Thread Charlie Clark

Hi,

it's been suggested to me on the Mac porting list to offer my  
services here. I am at most a Python programmer not a developer but I  
might be able to help on PyUno - at least to make the Python files  
themselves somewhat more Pythonic. Unfortunately I have no experience  
in writing C-Extentsions or even C itself. I read an interesting  
discussion in the archives regarding PyUno from 2005 but judging by  
the sources in m200 it looks like stuff hasn't happened for a long time.


Is there anyone on list actively pursuing PyUno?

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226



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



Re: [dev] Extending the binfilter Module

2007-02-02 Thread Rüdiger Timm


Mathias Bauer wrote:

Rüdiger Timm schrieb:


Kay Ramme - Sun Germany - Hamburg wrote:

FYI

Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently had a 
discussions regarding how to deal with binfilter in case of incompatible 
changes of modules used by binfilter.


We came up with the following recipe: For every request of an additional 
module for / change of binfilter the following steps are to be tried in 
the following order:


   1. Check if the dependency could not be removed / avoided completely. 
- For the above change this means, to verify that basctl is indeed 
needed for loading / storing documents.
   2. Copy the code which is needed only. - For the above change this 
means, that the serializers (import / export) may just be copied out of 
basctl to binfilter (respectively they may be just reimplemented if this 
is easier :-) .
   3. Copy the whole module. - If the target module is reasonable small, 
the whole module may be copied to binfilter. For the above change this 
would mean to copy basctl to binfilter.
   4. Adapt binfilter to the incompatible changes done in the dependent 
module. - For the above change this would mean, to adapt binfilter to 
the changes done in basctl.
   5. Do not change the dependent module incompatible. - For the above 
change this would mean, not to change basctl incompatible.



I created a module page for the binfilter module in the OOo wiki and 
copied the receipt to this page as well:


 http://wiki.services.openoffice.org/wiki/Framework/Modules/binfilter


Hope that helps

  Kay


That's a joke, isn't it?
 From my point of view of course it has to be (according to your numeration)
1.
4.
5.
2.
3.

Why would you copy additional stuff into binfilter? We did enormous 
efforts to get that monster stripped, and you plan to blow it up again. 
Why? If someone does incompatible changes he must do all necessary 
adaptions in modules above. Regardless of the name of those modules. Why 
change code in 'sw' but leave 'binfilter/bf_sw' untouched?
OK, there may be rare cases where no one is able to adapt stone aged 
binfilter code with reasonable effort. But that is an evidence of 
incapacity and should be the strict exception.

At least that's my understanding. Please correct me where I am wrong.


IMHO you have a somewhat constricted perspective. Build times are
May be. Of course what i wrote are just my personal thougths and 
feelings. And I didn't want to offend anyone.



important but also important is avoiding to burn development resources
for maintaining code you don't want to touch anymore.
binfilter isn't static. During the last months even more code has been 
moved from f.e. sw into binfilter.




I think the problem is that you can't give a fixed order for 2,3 and 4.
This must be checked for every single case. Perhaps Kay should point
this out in the wiki.
OK, accepted. But from my point of view we should not make 'move more 
basic code into binfilter' (2 or 3) a default before 'adapt binfilter to 
the changes' (4). I even doubt that (4) in general is more effort than (3).




But IMHO it's clear that option 1 is by far the best and should be aimed
for as often as possible and that option 5 should be considered only in
desperate cases.



Rüdiger

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



Re: [dev] Extending the binfilter Module

2007-02-02 Thread Jens-Heiner Rechtien

Thorsten Behrens wrote:

Caolan McNamara <[EMAIL PROTECTED]> writes:


On Fri, 2007-02-02 at 14:18 +0100, Pavel Janík wrote:

What about making binfilter SO only module? ;-)
-1 


Unfortunately .sdw etc documents exist and are a fact of life, we do
still need to import them. e.g. my performance review still comes
in .sdw format, we wouldn't want to drop importing that :-)


Hm - hard to estimate how many of those binary documents are still in
active use. And it would be interesting if they are kept just because
of laziness, or for good reasons (I clearly suspect the former).


Laziness is a good reason. No one is going over back up tapes just for 
converting old documents ... as long as it is reasonably safe to assume 
it's still safe to open the old documents. "Active use" is a  misleading 
term here. I still want to be able to look into - let's say - old 
exchanges with the tax authorities but I wouldn't ever want to change 
these documents. Be able to do that without fiddling around with an old 
version of OpenOffice.org is a major convenience.




At any rate, binfilter is a huge, tangled mess (yes, more so than the
average OOo module), and maintaining/building/shipping it benefits
only those tiny fraction of users with sd?-documents. 


*If* we want to start reducing build time/reduce developer load/free
resources for other tasks, then reducing code size is clearly top on
the list - and binfilter would be a huge blob we could drop in one
go. 


There are at least three possible ways to do this gracefully:
 a) drop binfilter for the next major release, telling users to convert
their documents using OOo2.x. Can even implement a tiny filter
replacement, that says so in a message box.


Before we drop our own legacy filters (which would be a major 
inconvenience for "lazy" long time office users) we should think hard 
about obsolete 3rd party filters which could be removed without 
alienating our own user base.



 b) move _all_ modules below binfilter into that module, possibly after
stripping them to the necessary minimum. Build it once, and tuck it
into a safe place (comes close to a, but is smaller & integrates
with OOo3).


Unrealistic, because rebuilding the binfilters might be necessary for 
all kind of reasons: compiler changes, base line changes, bug fixes, new 
platforms etc. Over long it would be part of the regular build again, 
now only bigger than ever before.



 c) have a webservice at services.openoffice.org, that runs OOo2.x,
and gets accessed from the sd?-filter of OOo3



A webservice for confidential documents? Not a good idea ...

Heiner

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



Re: [dev] Extending the binfilter Module

2007-02-02 Thread Rüdiger Timm



Thorsten Behrens wrote:

Caolan McNamara <[EMAIL PROTECTED]> writes:


On Fri, 2007-02-02 at 14:18 +0100, Pavel Janík wrote:

What about making binfilter SO only module? ;-)
-1 


Unfortunately .sdw etc documents exist and are a fact of life, we do
still need to import them. e.g. my performance review still comes
in .sdw format, we wouldn't want to drop importing that :-)


Hm - hard to estimate how many of those binary documents are still in
active use. And it would be interesting if they are kept just because
of laziness, or for good reasons (I clearly suspect the former).

At any rate, binfilter is a huge, tangled mess (yes, more so than the
average OOo module), and maintaining/building/shipping it benefits
only those tiny fraction of users with sd?-documents. 


*If* we want to start reducing build time/reduce developer load/free
resources for other tasks, then reducing code size is clearly top on
the list - and binfilter would be a huge blob we could drop in one
go. 

I do not see your point here. There is a configure option to leave out 
binfilter from a build. For an average OOo developer or even someone 
building OOo for his own use that is a good option. Only those people 
building for official distributions have to care about that module.



There are at least three possible ways to do this gracefully:
 a) drop binfilter for the next major release, telling users to convert
their documents using OOo2.x. Can even implement a tiny filter
replacement, that says so in a message box.

Would be a clean solution, though not my preferred one.


 b) move _all_ modules below binfilter into that module, possibly after
stripping them to the necessary minimum. Build it once, and tuck it
into a safe place (comes close to a, but is smaller & integrates
with OOo3).
And you are sure that it always integrates with OOo? I suspect that we 
would buy in a lot of problems and technical effort to keep that running .



 c) have a webservice at services.openoffice.org, that runs OOo2.x,
and gets accessed from the sd?-filter of OOo3


Can you imagine f.e. debian to use such an approach? :-)

Rüdiger

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



Re: [dev] Extending the binfilter Module

2007-02-02 Thread Mathias Bauer
Thorsten Behrens schrieb:

> There are at least three possible ways to do this gracefully:
>  a) drop binfilter for the next major release, telling users to convert
> their documents using OOo2.x. Can even implement a tiny filter
> replacement, that says so in a message box.

IMHO OOo3.0 would be too early for this. I think we could drop the
export but the necessary work to remove only the exporter is just too much.

>  b) move _all_ modules below binfilter into that module, possibly after
> stripping them to the necessary minimum. Build it once, and tuck it
> into a safe place (comes close to a, but is smaller & integrates
> with OOo3).

Following Kay's proposal that's what you get if you always chose option
2 or 3. This would do it not for all modules in one step but for each of
them on demand. I think that's the better approach. Yes, moving all the
modules in one step wouldn't take much time, but stripping them could be
expensive. Why moving code to binfilter without a need?

As long as the binfilter module still runs well with the built-in VCL
and no "must changes" from VCL must be done in binfilter - why not
saving the time and wait?

Before the problem with basctl came up we didn't talk about the other
modules "below" binfilter. Why should we do it now?

As long as no "must changes" are due the only disadvantage of binfilter
in its current form is that it must be rebuilt sometimes. That's bearable.

>  c) have a webservice at services.openoffice.org, that runs OOo2.x,
> and gets accessed from the sd?-filter of OOo3

Doesn't need to be a Web Service. Could be a standalone converter also.

Ciao,
Mathias

-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[EMAIL PROTECTED]".
I use it for the OOo lists and only rarely read other mails sent to it.

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



Re: [dev] Extending the binfilter Module

2007-02-02 Thread Mathias Bauer
Rüdiger Timm schrieb:

> 
> Kay Ramme - Sun Germany - Hamburg wrote:
>> FYI
>> 
>> Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently had a 
>> discussions regarding how to deal with binfilter in case of incompatible 
>> changes of modules used by binfilter.
>> 
>> We came up with the following recipe: For every request of an additional 
>> module for / change of binfilter the following steps are to be tried in 
>> the following order:
>> 
>>1. Check if the dependency could not be removed / avoided completely. 
>> - For the above change this means, to verify that basctl is indeed 
>> needed for loading / storing documents.
>>2. Copy the code which is needed only. - For the above change this 
>> means, that the serializers (import / export) may just be copied out of 
>> basctl to binfilter (respectively they may be just reimplemented if this 
>> is easier :-) .
>>3. Copy the whole module. - If the target module is reasonable small, 
>> the whole module may be copied to binfilter. For the above change this 
>> would mean to copy basctl to binfilter.
>>4. Adapt binfilter to the incompatible changes done in the dependent 
>> module. - For the above change this would mean, to adapt binfilter to 
>> the changes done in basctl.
>>5. Do not change the dependent module incompatible. - For the above 
>> change this would mean, not to change basctl incompatible.
>> 
>> 
>> I created a module page for the binfilter module in the OOo wiki and 
>> copied the receipt to this page as well:
>> 
>>  http://wiki.services.openoffice.org/wiki/Framework/Modules/binfilter
>> 
>> 
>> Hope that helps
>> 
>>   Kay
>> 
> 
> That's a joke, isn't it?
>  From my point of view of course it has to be (according to your numeration)
> 1.
> 4.
> 5.
> 2.
> 3.
> 
> Why would you copy additional stuff into binfilter? We did enormous 
> efforts to get that monster stripped, and you plan to blow it up again. 
> Why? If someone does incompatible changes he must do all necessary 
> adaptions in modules above. Regardless of the name of those modules. Why 
> change code in 'sw' but leave 'binfilter/bf_sw' untouched?
> OK, there may be rare cases where no one is able to adapt stone aged 
> binfilter code with reasonable effort. But that is an evidence of 
> incapacity and should be the strict exception.
> At least that's my understanding. Please correct me where I am wrong.

IMHO you have a somewhat constricted perspective. Build times are
important but also important is avoiding to burn development resources
for maintaining code you don't want to touch anymore.

I think the problem is that you can't give a fixed order for 2,3 and 4.
This must be checked for every single case. Perhaps Kay should point
this out in the wiki.

But IMHO it's clear that option 1 is by far the best and should be aimed
for as often as possible and that option 5 should be considered only in
desperate cases.

Ciao,
Mathias


-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[EMAIL PROTECTED]".
I use it for the OOo lists and only rarely read other mails sent to it.

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



[dev] A few brief questions ad extension packages (Re: [dev] Class-Path Entry in Manifest Package File and the Location of the Respective jars?

2007-02-02 Thread Rony G. Flatscher
Hi Stephan,
> Feel free to come back here with any questions along your way,
Thank you very much for your kind offer!

Indeed, after studying your information there would be a couple of
questions:

* where would one find the full definition for "manifest.xml" and a
  list of valid "mainfest:media-type"s; I looked in the developers
  guide and tried the search function of the Wiki, but have not been
  really able to locate it?
* also, where would one be able to find the full definition for the
  "description.xml" file?
  o ad version numbers: would something like "2.1.0.20070202" or
"210.20070202" be o.k. (according to the production rule it
should be possible) or would that pose any problems (the
date of the version is the trailing value, possibly
supplemented with the time of the day like "210.20070202162200")
* ad "application/vnd.sun.star.uno-component;type=native":
  o This can be used to not only denote libraries, but also
executables and modules (or with other words: these files
will be put into a place that is accessible via the PATH
settings?)
  o Is there a complete list somewhere of the operating system
dependent strings? The extension document mentions
"Windows", "Linux_x86", "Solaris_SPARC". So what about PPC
versions of Linux or Intel versions of Solaris or PPC and/or
Intel versions of MacOSX?
* is there a possibility to copy a set of scripts (in any available
  scripting language) to the user and/or shared script repository?
  If possible, what would be the appropriate "manifest:media-type"
  entry?
  o Of course this may pose a little problem when using the
update feature, as such scripts could have been edited in
the meantime by the users (but then one could resolve this
by moving the existing/edited extension scripts to an own
backup library)

TIA,

---rony



Re: [dev] Extending the binfilter Module

2007-02-02 Thread Thorsten Behrens
Caolan McNamara <[EMAIL PROTECTED]> writes:

> On Fri, 2007-02-02 at 14:18 +0100, Pavel Janík wrote:
> > What about making binfilter SO only module? ;-)
> 
> -1 
> 
> Unfortunately .sdw etc documents exist and are a fact of life, we do
> still need to import them. e.g. my performance review still comes
> in .sdw format, we wouldn't want to drop importing that :-)
> 
Hm - hard to estimate how many of those binary documents are still in
active use. And it would be interesting if they are kept just because
of laziness, or for good reasons (I clearly suspect the former).

At any rate, binfilter is a huge, tangled mess (yes, more so than the
average OOo module), and maintaining/building/shipping it benefits
only those tiny fraction of users with sd?-documents. 

*If* we want to start reducing build time/reduce developer load/free
resources for other tasks, then reducing code size is clearly top on
the list - and binfilter would be a huge blob we could drop in one
go. 

There are at least three possible ways to do this gracefully:
 a) drop binfilter for the next major release, telling users to convert
their documents using OOo2.x. Can even implement a tiny filter
replacement, that says so in a message box.
 b) move _all_ modules below binfilter into that module, possibly after
stripping them to the necessary minimum. Build it once, and tuck it
into a safe place (comes close to a, but is smaller & integrates
with OOo3).
 c) have a webservice at services.openoffice.org, that runs OOo2.x,
and gets accessed from the sd?-filter of OOo3

Just my 2 cents, naturally...

Cheers,

-- Thorsten

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



Re: [dev] Extending the binfilter Module

2007-02-02 Thread Caolan McNamara
On Fri, 2007-02-02 at 14:18 +0100, Pavel Janík wrote:
> What about making binfilter SO only module? ;-)

-1 

Unfortunately .sdw etc documents exist and are a fact of life, we do
still need to import them. e.g. my performance review still comes
in .sdw format, we wouldn't want to drop importing that :-)

The binfilter just needs to be reduced even further. Here's a list of
some potential candidate methods for removal :-)
http://people.redhat.com/caolanm/callcatcher/m201.binfilter.log


C.

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



Re: [dev] Extending the binfilter Module

2007-02-02 Thread Pavel Janík


On 2.2.2007, at 14:11, Rüdiger Timm wrote:


Kay Ramme - Sun Germany - Hamburg wrote:

FYI
Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently  
had a discussions regarding how to deal with binfilter in case of  
incompatible changes of modules used by binfilter.
We came up with the following recipe: For every request of an  
additional module for / change of binfilter the following steps  
are to be tried in the following order:
   1. Check if the dependency could not be removed / avoided  
completely. - For the above change this means, to verify that  
basctl is indeed needed for loading / storing documents.
   2. Copy the code which is needed only. - For the above change  
this means, that the serializers (import / export) may just be  
copied out of basctl to binfilter (respectively they may be just  
reimplemented if this is easier :-) .
   3. Copy the whole module. - If the target module is reasonable  
small, the whole module may be copied to binfilter. For the above  
change this would mean to copy basctl to binfilter.
   4. Adapt binfilter to the incompatible changes done in the  
dependent module. - For the above change this would mean, to adapt  
binfilter to the changes done in basctl.
   5. Do not change the dependent module incompatible. - For the  
above change this would mean, not to change basctl incompatible.
I created a module page for the binfilter module in the OOo wiki  
and copied the receipt to this page as well:

 http://wiki.services.openoffice.org/wiki/Framework/Modules/binfilter
Hope that helps
  Kay


That's a joke, isn't it?
From my point of view of course it has to be (according to your  
numeration)

1.
4.
5.
2.
3.


What about making binfilter SO only module? ;-)
--
Pavel Janík


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



Re: [dev] Extending the binfilter Module

2007-02-02 Thread Rüdiger Timm



Kay Ramme - Sun Germany - Hamburg wrote:

FYI

Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently had a 
discussions regarding how to deal with binfilter in case of incompatible 
changes of modules used by binfilter.


We came up with the following recipe: For every request of an additional 
module for / change of binfilter the following steps are to be tried in 
the following order:


   1. Check if the dependency could not be removed / avoided completely. 
- For the above change this means, to verify that basctl is indeed 
needed for loading / storing documents.
   2. Copy the code which is needed only. - For the above change this 
means, that the serializers (import / export) may just be copied out of 
basctl to binfilter (respectively they may be just reimplemented if this 
is easier :-) .
   3. Copy the whole module. - If the target module is reasonable small, 
the whole module may be copied to binfilter. For the above change this 
would mean to copy basctl to binfilter.
   4. Adapt binfilter to the incompatible changes done in the dependent 
module. - For the above change this would mean, to adapt binfilter to 
the changes done in basctl.
   5. Do not change the dependent module incompatible. - For the above 
change this would mean, not to change basctl incompatible.



I created a module page for the binfilter module in the OOo wiki and 
copied the receipt to this page as well:


 http://wiki.services.openoffice.org/wiki/Framework/Modules/binfilter


Hope that helps

  Kay



That's a joke, isn't it?
From my point of view of course it has to be (according to your numeration)
1.
4.
5.
2.
3.

Why would you copy additional stuff into binfilter? We did enormous 
efforts to get that monster stripped, and you plan to blow it up again. 
Why? If someone does incompatible changes he must do all necessary 
adaptions in modules above. Regardless of the name of those modules. Why 
change code in 'sw' but leave 'binfilter/bf_sw' untouched?
OK, there may be rare cases where no one is able to adapt stone aged 
binfilter code with reasonable effort. But that is an evidence of 
incapacity and should be the strict exception.

At least that's my understanding. Please correct me where I am wrong.

Rüdiger

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



Re: [dev] Extending the binfilter Module

2007-02-02 Thread Mathias Bauer
Hi Kay,

Kay Ramme - Sun Germany - Hamburg schrieb:

> We came up with the following recipe: For every request of an additional 
> module for / change of binfilter the following steps are to be tried in 
> the following order:
> 
> 1. Check if the dependency could not be removed / avoided 
> completely. - For the above change this means, to verify that basctl is 
> indeed needed for loading / storing documents.
> 2. Copy the code which is needed only. - For the above change this 
> means, that the serializers (import / export) may just be copied out of 
> basctl to binfilter (respectively they may be just reimplemented if this 
> is easier :-) .
> 3. Copy the whole module. - If the target module is reasonable 
> small, the whole module may be copied to binfilter. For the above change 
> this would mean to copy basctl to binfilter.
> 4. Adapt binfilter to the incompatible changes done in the dependent 
> module. - For the above change this would mean, to adapt binfilter to 
> the changes done in basctl.
> 5. Do not change the dependent module incompatible. - For the above 
> change this would mean, not to change basctl incompatible.

I wholeheartedly agree with your "recipe". Perhaps we should emphasize
that people should really try hard to use the first recommendation even
if this might take some time. It has the big benefit of making binfilter
smaller and avoiding future dependencies in this module.

Ciao,
Mathias


-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[EMAIL PROTECTED]".
I use it for the OOo lists and only rarely read other mails sent to it.

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



Re: [dev] HELP ME PLEASE :-)

2007-02-02 Thread Mathias Bauer
Ars Informatyka schrieb:

> Hellow
> 
> I have problem with files witch were saved in openoffice 1.9.62
> (write) with extention "oot". I don't have this version. I have to
> open it but no other version of openoffice can do it. Mabye there is
> nome converter to ott or rtf or doc files. I would be greatful if You
> gave me some solution.

These files have been saved with a beta version of OOo where the ODF
file format wasn't fixed. So we used a different media type in the files
and current versions of OOo refuse to open them as OOo checks the media
type to detect wether the packaged file represents an ODF file or not.

You should be able to load "oot" files by explicitly selecting the "Open
Document Text" filter in the file dialog of OOo. Does that help?

Ciao,
Mathias

-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[EMAIL PROTECTED]".
I use it for the OOo lists and only rarely read other mails sent to it.

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



Re: [dev] Is a dbgutils build supposed to produce so many messages

2007-02-02 Thread Mathias Bauer
Matthias B. schrieb:

> I've done a --enable-dbgutils build because I thought it could aid in
> debugging the frequent OOo crashes we suffer from. I'm a little bit
> shocked (although on 2nd thought not really surprised) at the number
> of message boxes with failed assertions and other messages about
> conditions that are not supposed to happen. Is that expected or is
> that just because our application (we're making heavy use of UNO to
> construct documents from a Java program) is stressing OOo so much?
> Is anybody interested in these messages? E.g. the message below tells
> me "Please inform OD". Is OD really interested?
> 
> Error: Assertion failed
> ==
> FILE  :  /ooo/src/OOE680_m6/sw/source/core/layout/anchoredobject.cxx
> at line 738
> ERROR :  " - cache for object
> rectangle inclusive spaces marked as valid, but it couldn't be.
> Missing invalidation of cache. Please inform OD."
> Abort ? (Yes=abort / No=ignore / Cancel=core dump)

The problem with our assertions is that many of them are checking for
conditions that the code thinks shouldn't happen but that indeed can
happen at runtime if e.g. a strange document is used. Others point to
only minor problems or better should be seen as warnings, some indeed
reveal serious problems. The one you mentioned above looks like it could
belong to the last category. I CC'ed "od" as he requested to become
informed. :-)

Overall the assertion code in OOo needs some maintenance; some problems
and false assertions have been fixed meanwhile but theses fixes are
available only in the most recent builds on the SRC680 code line.

Anyway, if you come across an assertion you can treat it as a bug and
submit an issue.

Ciao,
Mathias


-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[EMAIL PROTECTED]".
I use it for the OOo lists and only rarely read other mails sent to it.

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



Re: [dev] Joins in sw

2007-02-02 Thread Frank Meies - Sun Germany - Development - Software Engineer

Hi Li Jian,

On 02/02/07 12:34, lijian wrote:


I am Li Jian, a developer from Beijing Redflag CH2000 Software Co.,Ltd. I am in 
the Redoffice team and working with ChengXiuzhi, Liyuan and Liutao.
I'm interested in the SW project and intend to do some contributions here. In 
this community, I hope somebody can give me some suggestions and do help
to my work. Thank you!


thank you for your interest. Please have a look at

http://wiki.services.openoffice.org/wiki/Writer_ToDo

This is a good starting point for developers who want to start 
contributing to Writer. Of course you may also start with some small 
bugfixes or make some own suggestions. Please feel free to contact us 
again (dev@sw.openoffice.org) if you have found something interesting or 
if you need some more concrete suggestions.


Regards,

Frank

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



[dev] Joins in sw

2007-02-02 Thread lijian
Hi all,

I am Li Jian, a developer from Beijing Redflag CH2000 Software Co.,Ltd. I am in 
the Redoffice team and working with ChengXiuzhi, Liyuan and Liutao.
I'm interested in the SW project and intend to do some contributions here. In 
this community, I hope somebody can give me some suggestions and do help
to my work. Thank you!

Li Jian



lijian
2007-02-02


[dev] Extending the binfilter Module

2007-02-02 Thread Kay Ramme - Sun Germany - Hamburg

FYI

Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently had a 
discussions regarding how to deal with binfilter in case of incompatible 
changes of modules used by binfilter.


We came up with the following recipe: For every request of an additional 
module for / change of binfilter the following steps are to be tried in 
the following order:


   1. Check if the dependency could not be removed / avoided 
completely. - For the above change this means, to verify that basctl is 
indeed needed for loading / storing documents.
   2. Copy the code which is needed only. - For the above change this 
means, that the serializers (import / export) may just be copied out of 
basctl to binfilter (respectively they may be just reimplemented if this 
is easier :-) .
   3. Copy the whole module. - If the target module is reasonable 
small, the whole module may be copied to binfilter. For the above change 
this would mean to copy basctl to binfilter.
   4. Adapt binfilter to the incompatible changes done in the dependent 
module. - For the above change this would mean, to adapt binfilter to 
the changes done in basctl.
   5. Do not change the dependent module incompatible. - For the above 
change this would mean, not to change basctl incompatible.



I created a module page for the binfilter module in the OOo wiki and 
copied the receipt to this page as well:


 http://wiki.services.openoffice.org/wiki/Framework/Modules/binfilter


Hope that helps

  Kay

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



Re: [dev] RE:[dev] [sw-dev]question about table border line

2007-02-02 Thread Frank Meies - Sun Germany - Development - Software Engineer

Hi chensuchun,

On 02/02/07 02:52, [EMAIL PROTECTED] wrote:
 
When a table is formated with thick lines around the table and thin lines insidethe table, if you ask OO.o to add a row at the end of the table it's createdwith a thick line between it and the rest of the table instead of respecting the"thick lines around the table, thin lines inside" rule. 
I want to fix it as "thick lines around the table ,thin lines inside"after insert rows at the end of the table,but I find it is difficult to get SvxBoxInfoItem of the table in function BOOL lcl_CopyCol( const _FndBox*& rpFndBox, void* pPara ).

so I modify the insert-operation source code (in file 
sw/source/ui/shells/tabsh.cxx) as following:
 
case FN_TABLE_INSERT_COL:
case FN_TABLE_INSERT_ROW:
{ 
///-->get the SvxBoxInfoItem of the table before insert 
SfxItemSet aCoreSet( GetPool(), aUITableAttrRange); 
::lcl_TableParamToItemSet( aCoreSet, rSh ); 
SvxBoxInfoItem aBoxInfo((const SvxBoxInfoItem&) 
 aCoreSet.Get(SID_ATTR_BORDER_INNER)); 
///<--End 
///do the insert operation 
BOOL bColumn = rReq.GetSlot() == FN_TABLE_INSERT_COL; 
USHORT nCount = 0; 
BOOL bAfter = TRUE; 
if (pItem) 
{
  nCount = ((const SfxInt16Item* )pItem)->GetValue();
  if(SFX_ITEM_SET == pArgs->GetItemState(FN_PARAM_INSERT_AFTER, TRUE,
 &pItem))   
  bAfter = ((const SfxBoolItem* )pItem)->GetValue();  
}  
else if( !rReq.IsAPI() )   
++nCount;  
if( nCount )  
{  
if( bColumn ) 
   rSh.InsertCol( nCount, bAfter );  
else if ( !rSh.IsInRepeatedHeadline() ) 
   rSh.InsertRow( nCount, bAfter );  
bCallDone = TRUE;  
   ///-->after inserting,reset the table border according to the SvxBoxInfoItem  
   ///   get before   
   SfxItemSet aSet( GetPool(), RES_BOX, RES_BOX,

SID_ATTR_BORDER_INNER, SID_ATTR_BORDER_INNER,
0); 
   aSet.Put( aBoxInfo );  
   ItemSetToTableParam( aSet, rSh );  
   ///<--  
   break; 
  }
 nSlot = bColumn ? FN_TABLE_INSERT_COL_DLG : FN_TABLE_INSERT_ROW_DLG;
} 
Is this modification right,or it would cause other problem or affect other operation?How to solve this problem if the modification is wrong ? 
Thanks for help or advices!


cool, your code already looks quite good. I made some little 
modifications in order to generate only one undo event for this action:



case FN_TABLE_INSERT_COL:
case FN_TABLE_INSERT_ROW:
{
BOOL bColumn = rReq.GetSlot() == FN_TABLE_INSERT_COL;
USHORT nCount = 0;
BOOL bAfter = TRUE;
if (pItem)
{
nCount = ((const SfxInt16Item* )pItem)->GetValue();
if(SFX_ITEM_SET ==  
   pArgs->GetItemState(FN_PARAM_INSERT_AFTER, TRUE, pItem))
bAfter = ((const SfxBoolItem* )pItem)->GetValue();
}
else if( !rReq.IsAPI() )
++nCount;

if( nCount )
{
///-->get the SvxBoxInfoItem of the table before insert
SfxItemSet aCoreSet( GetPool(), aUITableAttrRange);
::lcl_TableParamToItemSet( aCoreSet, rSh );
bool bSetInnerBorders = false;
sal_uInt16 nUndoId = 0;
///<--End

if( bColumn )
{
rSh.StartUndo( UNDO_TABLE_INSCOL );
rSh.InsertCol( nCount, bAfter );
bSetInnerBorders = true;
nUndoId = UNDO_TABLE_INSCOL;
}
else if ( !rSh.IsInRepeatedHeadline() )
{
rSh.StartUndo( UNDO_TABLE_INSROW );
rSh.InsertRow( nCount, bAfter );
bSetInnerBorders = true;
nUndoId = UNDO_TABLE_INSROW;
}

bCallDone = TRUE;

   ///-->after inserting,reset the inner table borders
   if ( bSetInnerBorders )
   {
SvxBoxInfoItem aBoxInfo((const SvxBoxInfoItem&)
aCoreSet.Get(SID_ATTR_BORDER_INNER));
SfxItemSet aSet( GetPool(), SID_ATTR_BORDER_INNER,  
SID_ATTR_BORDER_INNER, 0);
aSet.Put( aBoxInfo );
ItemSetToTableParam( aSet, rSh );
rSh.EndUndo( nUndoId );
   }
   ///<--

   break;
}

nSlot = bColumn ? FN_TABLE_INSERT_COL_DLG : FN

[dev] HELP ME PLEASE :-)

2007-02-02 Thread Ars Informatyka
Hellow

I have problem with files witch were saved in openoffice 1.9.62 (write) 
with 
extention "oot". I don't have this version. I have to open it but no other 
version of openoffice can do it. Mabye there is nome converter to ott or rtf or 
doc files. I would be greatful if You gave me some solution.

Jakub Kowalczyk
-

pozdrawiamy

81-423 Gdynia
ul. Partyzantów 39/90
tel. +4858 621 75 54
fax. +4858 661 83 73


Re: [dev] Ruby binding

2007-02-02 Thread Juergen Schmidt

Andrzej Zawadzki wrote:

Rony G. Flatscher wrote:
Once I get the ooRexx scripting language support packaged into an
extension package, I will send you the respective information, such that
you can do the same for JRuby.
I'll be very thankful. However I think I'll also need some time to do this 
integration properly:)#


really good news. Please ask when you have problems and let us know if i 
can help (depending on time constraints).


Juergen




Andrzej Zawadzki

-
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] Class-Path Entry in Manifest Package File and the Location of the Respective jars?

2007-02-02 Thread Stephan Bergmann

Rony G. Flatscher wrote:

Hi Stephan,

thank you *very* much for your hints and pointers, which I need to
follow and study in full in order to be able to experiment with it!
(Will take some time, though.)


If the three additional jars (bsf-v242-20070128.jar,
bsf-rexx-engine.jar, oorexx-uno.jar) are only needed by
ScriptProviderForooRexx.jar, create a ScriptProviderForooRexx.oxt
extension (see
)
instead that contains all four jars (and can also contain additional
information like extension identifier, version, update information,
see ).

That way, your functionality (a script provider for ooRexx) comes as a
self-contained entity (that can be deployed in one step via unopkg or
OOo's "Tools - Extension Manager..."), without the need to add
additional jars to special places (OOo's program/classes, JVM's
extension path).

That sounds exactly what I have been looking for (in addition I will
have to supply platform dependent DLLs/so platforms and supportive -
platform independent - scripts), could glimpse over it already a bit and
saw that link libraries can be bundled for different platforms.


Yes, platform specific libraries are supported.  Also, I should point 
out that the Extensions.pdf is work in progress that is supposed to be 
integrated into the Developer's Guide, superseding the 
extensions-related information that (in part) is already there in the 
current version of the Guide.


Feel free to come back here with any questions along your way,

-Stephan


Also it seems, that deploying the extension will become really easy for
the user, including updating the extension!

Again, thank you very much!

Regards,

---rony


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