[dev] RE: [api-dev] pdf import programmatically
Hi, Can anyone help me on this? Is there a way to force a document to open with draw programmatically? > From: shaun...@hotmail.com > To: dev@openoffice.org; d...@api.openoffice.org > Date: Mon, 7 Jun 2010 15:32:58 +0800 > Subject: [api-dev] pdf import programmatically > > > Hi all, > > > > I am trying import pdf files to edit. I've installed the sun pdf import with > openoffice 3.1. Pdf files seem to open fine in draw when i open it from the > desktop. > > > > However, when i use the loadComponentFromURL method, it opens the file with > writer and encoded text appears. I've also tried passing in "MediaType" in > the mediadescriptor with the value of "simpress8" but it doesn't work. > > > > How can i programmatically force it to open with draw and return a XComponent > object? > > > > Thanks. > > > > Cheers, > > > > Wei Min > > _ > Hotmail: Trusted email with powerful SPAM protection. > https://signup.live.com/signup.aspx?id=60969 _ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969
Re: [dev] Old bugs related to hyperlinks with bookmark.
On 06/16/2010 09:21 PM, Knut Olav Bøhmer wrote:
As long as the url points to a ".doc" file, my interceptor is not called no
matter if there is a bookmark there or not. It does not matter if ctrl-click
is required or not. There is just NO dispatch interception going on for
".doc" files.
But I get all sorts of other dispatch querys like ".uno:GoUp" or ".uno:Quit"
and "file://" but not as long as it is a .doc file whether the file exists
or not.
Regards
I assume that the code that calls the hyperlink dispatch uses the wrong
way. In code using sfx2 (as e.g. Writer) we have two ways to dispatch,
the "normal" one and an "internal" one that can't be intercepted.
Something like that is necessary, e.g. to handle dispatch events after
possible interceptions ("slave" dispatchers). That sounds interesting
enough to have a look. :-)
In case you are interested: the "normal" dispatch is triggered by
"Execute" calls at an instance of class SfxBindings, while the
"internal" one uses "Execute" calls at an instance of class SfxDispatcher.
Regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamfor...@gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
[dev] Community Council Elections 2010-06: Introducing the Nominees
Hi everyone, I would like to thank both Thorsten and Andreas for their nomination for the "Product Development Representative" in the Community Council. According to our election process, we are now in the introduction phase - the nominees do have the chance to introduce themselves to the community. Moreover, each of us might ask questions to the nominees ... this is helpful, since they might represent "us" for quite some time ;-) I would like to start - so please answer the following questions: * What is your idea by the work/tasks of the council? * Do you have any special areas of interest/ideas? * Is there enough spare time for the work in the council? Thanks a lot! For all, if you have any questions with regard to the current Community Council Election, please have a look at the status page in the wiki: http://wiki.services.openoffice.org/wiki/Community_Council/Elections/2010-06 Any other questions? Go on community, go on :-) Have a nice day, Christoph - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Rich Text Format Support in OpenOffice.org Writer
Hello, First off, I need to say that this is -not- a message complaining about rich text format support. Now that that is out of the way... I would like to volunteer my services to help improve the RTF support for openoffice.org writer. However, I am a fairly new programmer and would require some guidance getting into the code base, and also some guidance on how to work with a large project such as this one. The first question is probably: Why would I want to improve RTF support? Well, my college uses exclusively Microsoft Word for essentianally everything, and doesn't support anything else well. The only concession they will make is to allow submissions in, and send documents in, RTF format. Since RTF support isn't the best right now, i'd like to see if I can manage to improve it, even if only a little bit. I had a discussion about why I'd want to do this here: http://user.services.openoffice.org/en/forum/viewtopic.php?f=7&t=31596. If anyone has the time to point me in the right direction, it would be appreciated. Thank you, Chris Carpenter(mordocai)
Re: [dev] Old bugs related to hyperlinks with bookmark.
On 16 June 2010 19:39, Mathias Bauer wrote: > Hi Knut Olav, > > > On 16.06.2010 17:57, Knut Olav Bøhmer wrote: > > Is there a (easy) way to tell OOo that we want to handle specific url's >> internally? It could also sometimes be useful to say that we do not want >> to >> handle odt urls internally also (maybe).. But the most important thing is >> to >> get the #bookmarks to work. >> > > For the bookmark case I would fix that in the place I have shown. > > I just discovered that we already have code there that handles the case > where the URL only consists of a jump mark. I will have a closer look and > report my findings in the issue. We can follow-up there. Great! Maybe it would be possible to tell "the system" how to handle url's with > bookmarks? > No, that doesn't work. A "#" is just a letter in a file name, so the URL > "file://foo/bar/text.doc#mark" does not point to the same file as > "file://foo/bar/text.doc". Jump marks in file URLs must be handled > internally. OOo can do that in the same way as a browser can do it for http > URLs. > > > So the .doc did not arrive at my >> dispatcher, because "the system" had taken it. >> > > If the jump to the bookmark would be a result of a click on a hyperlink, > your dispatch interceptor should have seen the dispatch. But the command > isn't the URL, it would the command ".uno:OpenURL" or so, where the file > name (including the jump mark) would be one of its dispatch arguments. Can > you confirm that? As long as the url points to a ".doc" file, my interceptor is not called no matter if there is a bookmark there or not. It does not matter if ctrl-click is required or not. There is just NO dispatch interception going on for ".doc" files. But I get all sorts of other dispatch querys like ".uno:GoUp" or ".uno:Quit" and "file://" but not as long as it is a .doc file whether the file exists or not. Regards -- Knut Olav Bøhmer
Re: [dev] Re: BigPointerArray, SvPointerArray vs STL containers
Great success! I have successfully removed the SvArray of objects macro (SV_DECL_OBJARR and SV_IMPL_OBJARR macros). Please feel free to check and test it. Patch is available at (replace_svarray3.patch): http://www.openoffice.org/issues/show_bug.cgi?id=112395 2010/6/15 Bjoern Michaelsen: >> Changing out SvArray, will fix this long standing bug, which will >> bring great joy and happiness to my life. >> >> http://www.openoffice.org/issues/show_bug.cgi?id=84159 > > Getting rid of SvArray might not be enough alone to fix this, but it > would be a big step in the right direction. Please also have a look at > the work in cws new_itemsets which tries to get rid of the old > SfxItemSet implementation and replace it with stl container-based stuff > whereever possible. Changing such a fundamental datastructure is not > easy at all, but the new implementation is mostly stable by now -- only > a few minor glitches remaining. > Gotta have to have a look at the stuff with somebody from the calc > team. Any voluteers? Do you know which field/variable cause this overflow? Where it is located (please specify path)? In file: http://svn.services.openoffice.org/opengrok/xref/DEV300_m82/svl/source/items/itempool.cxx I found SV_IMPL_PTRARR( SfxPoolVersionArr_Impl, SfxPoolVersion_Impl* ); declaration. Does this SvArray couse this trouble? I would like prepare patch which will fix this bug (Issue 84159). Best Regards Bartosz - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Old bugs related to hyperlinks with bookmark.
Hi Knut Olav, On 16.06.2010 17:57, Knut Olav Bøhmer wrote: Is there a (easy) way to tell OOo that we want to handle specific url's internally? It could also sometimes be useful to say that we do not want to handle odt urls internally also (maybe).. But the most important thing is to get the #bookmarks to work. For the bookmark case I would fix that in the place I have shown. I just discovered that we already have code there that handles the case where the URL only consists of a jump mark. I will have a closer look and report my findings in the issue. We can follow-up there. Maybe it would be possible to tell "the system" how to handle url's with bookmarks? No, that doesn't work. A "#" is just a letter in a file name, so the URL "file://foo/bar/text.doc#mark" does not point to the same file as "file://foo/bar/text.doc". Jump marks in file URLs must be handled internally. OOo can do that in the same way as a browser can do it for http URLs. So the .doc did not arrive at my dispatcher, because "the system" had taken it. If the jump to the bookmark would be a result of a click on a hyperlink, your dispatch interceptor should have seen the dispatch. But the command isn't the URL, it would the command ".uno:OpenURL" or so, where the file name (including the jump mark) would be one of its dispatch arguments. Can you confirm that? Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Old bugs related to hyperlinks with bookmark.
On 16 June 2010 17:24, Mathias Bauer wrote:
> On 16.06.2010 15:24, Knut Olav Břhmer wrote:
>
>> Hi,
>>
>> There are some old bug related to hyperlinks with bookmark: hyperlinks to
>> .doc files with bookmarks does not work.
>>
>> I think the following bugs are related to each other. And the bug has been
>> there for at least 6 years.
>>
>> http://qa.openoffice.org/issues/show_bug.cgi?id=26957
>> http://qa.openoffice.org/issues/show_bug.cgi?id=109752
>> http://qa.openoffice.org/issues/show_bug.cgi?id=109752
>> http://qa.openoffice.org/issues/show_bug.cgi?id=109752
>> http://qa.openoffice.org/issues/show_bug.cgi?id=19413
>>
>
> Any reason why one the issues is listed three times?
>
Sorry, maybe I copied and pasted from wrong tab. My head was spinning after
many hours of reading things I didn't understand...
> Besides that, these issues are totally unrelated and it doesn't make sense
> to construct a general hyperlink problem that just doesn't exist. Moreover,
> the Calc issue was reported just a few weeks ago. It seems that nobody just
> is aware of it (no QA or dev engineer was involved until now).
>
I wasn't able to reproduce issue 19413, perhaps we should close it.
>
> Then there is issue 26957. It seems that the bug is triggered by the fact
> that the URL to open is handed over to the system, not handled by OOo
> internally. That can't work as "#" in file URLs are not what they are in
> e.g. http URLs. The only solution would be *not* to let the system handle
> the URL (and that's the reason why it works in Word).
>
> Here's the code in sfx2/source/appl/appopen.cxx that decides whether a URL
> shall be handled internally or not:
>
> aTypeName = xTypeDetection->queryTypeByURL( aURL.Main );
>> SfxFilterMatcher& rMatcher = SFX_APP()->GetFilterMatcher();
>> const SfxFilter* pFilter = rMatcher.GetFilter4EA( aTypeName );
>> if ( !pFilter || !( pFilter->IsOwnFormat() ))
>> {
>>
>
>
Thank you! This is the kind of stuff I'd like to learn more about.
> Changing that is a matter of minutes, but the side effect could be larger
> than expected. Allowing to handle all URLs internally that OOo can open
> (detected by pFilter != 0 in the code above) is not wanted, as many other
> formats like e.g jpg, png etc. surely should preferably handled by the
> system and the application registered there.
>
> Another idea: check for "#" in the URL, and in case there is one, handle
> the URL internally.
Is there a (easy) way to tell OOo that we want to handle specific url's
internally? It could also sometimes be useful to say that we do not want to
handle odt urls internally also (maybe).. But the most important thing is to
get the #bookmarks to work.
Maybe it would be possible to tell "the system" how to handle url's with
bookmarks?
>
> In the queryDispatch method the plan was to check for
>> if ((aURL.Complete.startsWith("file://") )&&
>> (aURL.Complete.matches(".*doc#.*") )) {
>> and then use loadComponentFromURL. But .doc hyperlinks never arrived here.
>>
>
> You can't intercept loadComponentFromURL calls with a dispatch interceptor,
> your only can intercept - sic! - dispatch calls
Yes, and that's also why I can use loadComponentFromURL inside a dispatch
interceptor without getting in to trouble. So the .doc did not arrive at my
dispatcher, because "the system" had taken it.
It would be nice if it was possible to intercept things that is handed to
the system also.
Than you so much for answering.
--
Knut Olav Bøhmer
Re: [dev] Old bugs related to hyperlinks with bookmark.
On 16.06.2010 15:24, Knut Olav Bøhmer wrote:
Hi,
There are some old bug related to hyperlinks with bookmark: hyperlinks to
.doc files with bookmarks does not work.
I think the following bugs are related to each other. And the bug has been
there for at least 6 years.
http://qa.openoffice.org/issues/show_bug.cgi?id=26957
http://qa.openoffice.org/issues/show_bug.cgi?id=109752
http://qa.openoffice.org/issues/show_bug.cgi?id=109752
http://qa.openoffice.org/issues/show_bug.cgi?id=109752
http://qa.openoffice.org/issues/show_bug.cgi?id=19413
Any reason why one the issues is listed three times?
Besides that, these issues are totally unrelated and it doesn't make
sense to construct a general hyperlink problem that just doesn't exist.
Moreover, the Calc issue was reported just a few weeks ago. It seems
that nobody just is aware of it (no QA or dev engineer was involved
until now).
I wasn't able to reproduce issue 19413, perhaps we should close it.
Then there is issue 26957. It seems that the bug is triggered by the
fact that the URL to open is handed over to the system, not handled by
OOo internally. That can't work as "#" in file URLs are not what they
are in e.g. http URLs. The only solution would be *not* to let the
system handle the URL (and that's the reason why it works in Word).
Here's the code in sfx2/source/appl/appopen.cxx that decides whether a
URL shall be handled internally or not:
aTypeName = xTypeDetection->queryTypeByURL( aURL.Main );
SfxFilterMatcher& rMatcher = SFX_APP()->GetFilterMatcher();
const SfxFilter* pFilter = rMatcher.GetFilter4EA( aTypeName );
if ( !pFilter || !( pFilter->IsOwnFormat() ))
{
Changing that is a matter of minutes, but the side effect could be
larger than expected. Allowing to handle all URLs internally that OOo
can open (detected by pFilter != 0 in the code above) is not wanted, as
many other formats like e.g jpg, png etc. surely should preferably
handled by the system and the application registered there.
Another idea: check for "#" in the URL, and in case there is one, handle
the URL internally.
In the queryDispatch method the plan was to check for
if ((aURL.Complete.startsWith("file://") )&&
(aURL.Complete.matches(".*doc#.*") )) {
and then use loadComponentFromURL. But .doc hyperlinks never arrived here.
You can't intercept loadComponentFromURL calls with a dispatch
interceptor, your only can intercept - sic! - dispatch calls.
Regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamfor...@gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] SfxItemSet assumptions and assertions
On 16.06.2010 11:07, Malte Timmermann wrote: We have const SfxPoolItem& Get() and const SfxPoolItem* GetItem(...) Not sure why we have two different Get Methods, but the first doesn't allow to return NULL, so I assume the second one would also have to return the same VoidItem for consistency. I assume that Get() can't be used right away because the internally stored item pointer may have the value NULL or even -1(!). So I think that you can't call GetItem() before checking if the ItemSet has an item and it would be just wrong if it would be called for an invalid item. Putting them on a different ID than it's own ID doesn't sound right to me. For the different which ID stuff we have the SlotID mechanism. But that would probably need cloning the item and changing the which when putting it into a pool/itemset where different which ids are use. So the situations where we put items on different IDs should be investigated more closely. But again, looking at pItem = new SfxVoidItem( m_nSlotID ); rReq.SetReturnValue( SfxVoidItem( rReq.GetSlot() ) ); it seems to be a supported and wanted scenario. The fact that it is used that not mean that it is correct or even necessary. ;-) The question is what is the intent of writing this code and if that really requires such a fuzzy interface. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: about oov build
Thanks, i got it! 2010/6/16 Michael Stahl > On 16/06/2010 10:22, wangxiang wrote: > > Thanks, > > > > I just want to build some modules like SW with the debug partial build, > and > > replace existing libs to get some debugging > > > > But I can't find the ".o" or ".so" in the installation folders. In my > > fedora12, it's "/opt/openoffice.org3/program/" > > > > and i follow your suggestions and find the programs in the output tree > > sub-folders "openoffice.org3/program/" > > > > But there're still no other libs in the folder > > you're still looking in the wrong directory: > it's "opt/openoffice.org/program/", with no "3" in it! > > openoffice.org3 is the "brand" layer, and contains little of interest > (just the soffice.bin program that actually starts OOo). > > -- > "We are sorry, you have dialed an imaginary number. > Please rotate your phone ninety degrees and try again." > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.org > For additional commands, e-mail: dev-h...@openoffice.org > > -- Xiang Wang Institue Of Acoustics, CAS
Re: [dev] Re: BigPointerArray, SvPointerArray vs STL containers
Hi Bartosz, On Tuesday, 2010-06-15 09:06:19 +0200, Bartosz wrote: > After replace svArrays by STL containers, in some cases I observed boost of > performance. > > For example: > for (USHORT i = 0; i < aEntries.size(); ++i) Please ensure to adapt also all types where necessary, in this case the result may even be an endless loop if aEntries happens to contain more than 64k entries.. instead of USHORT i it should be size_t i Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the e...@sun.com account, which I use for mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks. pgp2t83YiRifM.pgp Description: PGP signature
[dev] Old bugs related to hyperlinks with bookmark.
Hi,
There are some old bug related to hyperlinks with bookmark: hyperlinks to
.doc files with bookmarks does not work.
I think the following bugs are related to each other. And the bug has been
there for at least 6 years.
http://qa.openoffice.org/issues/show_bug.cgi?id=26957
http://qa.openoffice.org/issues/show_bug.cgi?id=109752
http://qa.openoffice.org/issues/show_bug.cgi?id=109752
http://qa.openoffice.org/issues/show_bug.cgi?id=109752
http://qa.openoffice.org/issues/show_bug.cgi?id=19413
I could try to fix the bug myself, and I would very much like that, but I
don't have the knowledge.
So if someone could guide me and point me in the right direction, I would be
very happy.
I find it strange that this bugs are not fixed as hyperlinks are quite an
essential feature of electronic documents.
I have tried to make a workaround for this problem by making a
DispatchProviderInterceptor that handles opening of hyperlinks. In this
effort I found another bug (probably a bug). Hyperlinks to ".doc" files is
not possible to intercept.
In the queryDispatch method the plan was to check for
if ((aURL.Complete.startsWith("file://") ) &&
(aURL.Complete.matches(".*doc#.*") )) {
and then use loadComponentFromURL. But .doc hyperlinks never arrived here.
So now my plan is to make a macro that loops through the document, and
rewrites every hyperlink with bookmark, like this
"file:///file.doc#bookmark" , to something like
file:///file.odt#[doc]bookmark, and manipulate the url, so that it opens the
correct file. I have already made a small experiment that works. If someone
wants the final workaround, you can email me. There are several issues with
doing it this way: the document gets dirty and want's to be saved when you
quit. And when you save, the hyperlinks have to be "rewritten" back to
.doc#bookmark (I plan to handle that too.).
I wonder why ".doc" hyperlinks can not be intercepted. I would consider it a
good idea if what you'd write in the hyperlink field would be arbitrary, so
that new functionality could be written to hyperlinks by intercepting the
dispatch.
So, could anyone help me?
--
Knut Olav Bøhmer
Re: [dev] SfxItemSet assumptions and assertions
And now that I just read Bjoerns last mail wrt old/current behavior:
At least for the EditEngine I am quite sure these items have been in
some ItemPool, but never in an ItemSet.
So that might be the reason why I never had an issue with that.
Not sure what would happen with the VoidItems listed below in other places.
Malte.
Malte Timmermann wrote, On 06/16/10 11:07:
>
> Mathias Bauer wrote, On 06/16/10 10:11:
>> On 15.06.2010 11:47, Björn Michaelsen wrote:
>>
>>> Well, the implementation in new_itemsets only checks for the which id
>>> being 0 and never checks for the type being an SfxVoidItem (outside
>>> assertions). So an disabled item is consistently defined as any item
>>> returning an which id of 0 in the new itemset implementation.
>> That's an improvement and it allows to use the "API" consistently. OTOH
>> it is still ugly. :-) I consider the way how the ItemSet codes the
>> "disabled" status an implementation detail.
>>
>>> Now the interesting part is finding the clients of the itemset that
>>> rely on void items being interpreted as "disabled" by the itemset and
>>> fixing those
>> Question is if that is more effort then replacing all code that puts
>> items with ID = 0 with code calling "DisableItem" instead. That would
>> make putting an item with ID=0 an invalid action.
>>
>> BTW: I don't remember if any of the two ItemSet implementations returns
>> an VoidItem in a GetItem call for a disabled item or if NULL is returned
>> then. IMHO it always should be the latter.
>
> We have
> const SfxPoolItem& Get()
> and
> const SfxPoolItem* GetItem(...)
>
> Not sure why we have two different Get Methods, but the first doesn't
> allow to return NULL, so I assume the second one would also have to
> return the same VoidItem for consistency.
>
>> Back to your primary topic. If we identify the places where a VoidItem
>> with ID != 0 is put, and if the developers state that this is by intent,
>> we can remove that assertion and make putting VoidItems with ID != 0 a
>> valid action that does not disable that item.
>
> Yes, I guess it would be better to keep allowing VoidItems with Which !=
> 0. Or we search for all places where we might have != 0 VoidItems.
>
> Places I found:
> EditEngine has some, but that could be changed.
>
> I have no clue here:
> http://svn.services.openoffice.org/opengrok/xref/DEV300_m81/sfx2/source/control/sfxstatuslistener.cxx#233
> if ( pType == ::getVoidCppuType() )
> 232 {
> 233 pItem = new SfxVoidItem( m_nSlotID );
> 234 eState = SFX_ITEM_UNKNOWN;
> 235 }
>
> I don't think the slot id would be zero...
> But this looks like we really would mix up slot and which ids.
> Some more such things in sfx2/source/control/
>
> SW:
> rReq.SetReturnValue(SfxVoidItem(bLabel ? FN_LABEL : FN_BUSINESS_CARD));
> rSet.Put( SfxVoidItem( SID_ATTR_ZOOMSLIDER ) );
> rReq.SetReturnValue( SfxVoidItem( rReq.GetSlot() ) );
>
> SVX:
> new SfxVoidItem(SDRATTR_SHADOW3D );
> new SfxVoidItem(SDRATTR_SHADOWPERSP );
>
> I didn't check the [all...] links in OpenGrok, but with these hits I
> already feel that we simply should keep the old behavior...
>
>> The question why ItemSet::Put must allow that nWhich differs from the
>> item's which is still open. I assume that it's related to different
>> pools having different WhichIds for the same item. But knowing it for
>> sure would perhaps allow us to define a less fuzzy interface.
>
> Putting them on a different ID than it's own ID doesn't sound right to me.
> For the different which ID stuff we have the SlotID mechanism.
> But that would probably need cloning the item and changing the which
> when putting it into a pool/itemset where different which ids are use.
> So the situations where we put items on different IDs should be
> investigated more closely.
>
> But again, looking at
> pItem = new SfxVoidItem( m_nSlotID );
> rReq.SetReturnValue( SfxVoidItem( rReq.GetSlot() ) );
> it seems to be a supported and wanted scenario.
>
> Malte.
>
>> Regards,
>> Mathias
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
> For additional commands, e-mail: dev-h...@openoffice.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: about oov build
On 16/06/2010 10:22, wangxiang wrote: > Thanks, > > I just want to build some modules like SW with the debug partial build, and > replace existing libs to get some debugging > > But I can't find the ".o" or ".so" in the installation folders. In my > fedora12, it's "/opt/openoffice.org3/program/" > > and i follow your suggestions and find the programs in the output tree > sub-folders "openoffice.org3/program/" > > But there're still no other libs in the folder you're still looking in the wrong directory: it's "opt/openoffice.org/program/", with no "3" in it! openoffice.org3 is the "brand" layer, and contains little of interest (just the soffice.bin program that actually starts OOo). -- "We are sorry, you have dialed an imaginary number. Please rotate your phone ninety degrees and try again." - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] SfxItemSet assumptions and assertions
Mathias Bauer wrote, On 06/16/10 10:11:
> On 15.06.2010 11:47, Björn Michaelsen wrote:
>
>> Well, the implementation in new_itemsets only checks for the which id
>> being 0 and never checks for the type being an SfxVoidItem (outside
>> assertions). So an disabled item is consistently defined as any item
>> returning an which id of 0 in the new itemset implementation.
>
> That's an improvement and it allows to use the "API" consistently. OTOH
> it is still ugly. :-) I consider the way how the ItemSet codes the
> "disabled" status an implementation detail.
>
>> Now the interesting part is finding the clients of the itemset that
>> rely on void items being interpreted as "disabled" by the itemset and
>> fixing those
> Question is if that is more effort then replacing all code that puts
> items with ID = 0 with code calling "DisableItem" instead. That would
> make putting an item with ID=0 an invalid action.
>
> BTW: I don't remember if any of the two ItemSet implementations returns
> an VoidItem in a GetItem call for a disabled item or if NULL is returned
> then. IMHO it always should be the latter.
We have
const SfxPoolItem& Get()
and
const SfxPoolItem* GetItem(...)
Not sure why we have two different Get Methods, but the first doesn't
allow to return NULL, so I assume the second one would also have to
return the same VoidItem for consistency.
>
> Back to your primary topic. If we identify the places where a VoidItem
> with ID != 0 is put, and if the developers state that this is by intent,
> we can remove that assertion and make putting VoidItems with ID != 0 a
> valid action that does not disable that item.
Yes, I guess it would be better to keep allowing VoidItems with Which !=
0. Or we search for all places where we might have != 0 VoidItems.
Places I found:
EditEngine has some, but that could be changed.
I have no clue here:
http://svn.services.openoffice.org/opengrok/xref/DEV300_m81/sfx2/source/control/sfxstatuslistener.cxx#233
if ( pType == ::getVoidCppuType() )
232 {
233 pItem = new SfxVoidItem( m_nSlotID );
234 eState = SFX_ITEM_UNKNOWN;
235 }
I don't think the slot id would be zero...
But this looks like we really would mix up slot and which ids.
Some more such things in sfx2/source/control/
SW:
rReq.SetReturnValue(SfxVoidItem(bLabel ? FN_LABEL : FN_BUSINESS_CARD));
rSet.Put( SfxVoidItem( SID_ATTR_ZOOMSLIDER ) );
rReq.SetReturnValue( SfxVoidItem( rReq.GetSlot() ) );
SVX:
new SfxVoidItem(SDRATTR_SHADOW3D );
new SfxVoidItem(SDRATTR_SHADOWPERSP );
I didn't check the [all...] links in OpenGrok, but with these hits I
already feel that we simply should keep the old behavior...
>
> The question why ItemSet::Put must allow that nWhich differs from the
> item's which is still open. I assume that it's related to different
> pools having different WhichIds for the same item. But knowing it for
> sure would perhaps allow us to define a less fuzzy interface.
Putting them on a different ID than it's own ID doesn't sound right to me.
For the different which ID stuff we have the SlotID mechanism.
But that would probably need cloning the item and changing the which
when putting it into a pool/itemset where different which ids are use.
So the situations where we put items on different IDs should be
investigated more closely.
But again, looking at
pItem = new SfxVoidItem( m_nSlotID );
rReq.SetReturnValue( SfxVoidItem( rReq.GetSlot() ) );
it seems to be a supported and wanted scenario.
Malte.
>
> Regards,
> Mathias
>
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: about oov build
Am Wed, 16 Jun 2010 16:22:13 +0800 schrieb wangxiang : > Thanks, > > I just want to build some modules like SW with the debug partial > build, and replace existing libs to get some debugging > > But I can't find the ".o" or ".so" in the installation folders. In my > fedora12, it's "/opt/openoffice.org3/program/" > > and i follow your suggestions and find the programs in the output tree > sub-folders "openoffice.org3/program/" > > But there're still no other libs in the folder /opt/openoffice3/ is the brand layer, you need to find the basis layer. On my machine (gentoo) it is at /usr/lib/openoffice/basis3.2/program on other distro it might be a different location. Ask your friendly package manager. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: SfxItemSet assumptions and assertions
Am Wed, 16 Jun 2010 10:11:25 +0200 schrieb Mathias Bauer : > BTW: I don't remember if any of the two ItemSet implementations > returns an VoidItem in a GetItem call for a disabled item or if NULL > is returned then. IMHO it always should be the latter. Getting a void item the old implementation returns: - a state disabled and leaves the item pointer unmodified in GetItemState - a NULL item pointer in GetItem - a pointer to the void item and fires an assertion (triggered on which id == 0 _OR_ type == SfxVoidItem) in Get Getting a void item the new implementation returns: - state disabled and leaving the pointer unmodified only on which id = 0 in GetItemState - a NULL item pointer on which id = 0 in GetItem - a pointer to the item in Get Void items with a which id set to the which position it is in in the itemset are treated just as any other item. Assertions are mostly pushed to the point where such items are put in the set, not when they are extracted -- when it is too late already. > Back to your primary topic. If we identify the places where a > VoidItem with ID != 0 is put, and if the developers state that this > is by intent, we can remove that assertion and make putting VoidItems > with ID != 0 a valid action that does not disable that item. True. Still somewhere code may lurk, where a void item is put with a which id set and expected to work as a disabled state. For example IIRC doing a SfxItemSet::Put(SfxVoidItem(4711)) will result in SfxItemSet::GetItemState(4711, false, NULL) returning a disabled state in the old implementation, but not in the new one. So there are three cases. The developer intended: - the behavior of the old implementation (which would be abuse of the interface) - the behavior of the new implementation (which would be a bug) - any behavior, because they make no difference in the given scenario. A migration path could be as follows: We have a aborting assertion on putting void items. Every such call either gets replaced by: - an explicit DisableItem call - or an explicit (new) PutVoidItem call (with the which id of the void item set to the which id of the position in the set) After we got rid of all the assertions, we might remove the PutVoidItem call and allow Put to accept void items with a valid which id. > The question why ItemSet::Put must allow that nWhich differs from the > item's which is still open. I assume that it's related to different > pools having different WhichIds for the same item. But knowing it for > sure would perhaps allow us to define a less fuzzy interface. ACK! Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: about oov build
Thanks, I just want to build some modules like SW with the debug partial build, and replace existing libs to get some debugging But I can't find the ".o" or ".so" in the installation folders. In my fedora12, it's "/opt/openoffice.org3/program/" and i follow your suggestions and find the programs in the output tree sub-folders "openoffice.org3/program/" But there're still no other libs in the folder *My question actually is "If someone wrote an extension/plugin for OOo, Can he debug his code with just replacing some existing libs of OOo? "* 2010/6/16 Bjoern Michaelsen > Am Wed, 16 Jun 2010 15:32:54 +0800 > schrieb wangxiang : > > > *But another question comes back : I can't find the ".o" or ".so" > > libs in the folder "/opt/openoffice.org3/program" (There's only an > > "libnpsoplugin.so" in the folder )* > > Is that right ? > Yes, most libs are in /opt/openoffice (the "middle layer", see > > http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo > ) > > > *Because I want to build the sw module with debug information, and > > replace the existing libs with the new build libs* > > Well, you should not need to do that with a machine-wide installation. > You can either set: > export FORCE2ARCHIVE=true > or > export PKGFORMAT=installed > to get a tarball that you can simply unpack an run anywhere, or to get > an runnable installation directly in the output tree of > instsetoo_native > ( > http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux#cite_note-Foot6-5 > .) > > Best Regards, > > Bjoern > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.org > For additional commands, e-mail: dev-h...@openoffice.org > > -- Xiang Wang Institue Of Acoustics, CAS
Re: [dev] SfxItemSet assumptions and assertions
On 15.06.2010 11:47, Björn Michaelsen wrote: Well, the implementation in new_itemsets only checks for the which id being 0 and never checks for the type being an SfxVoidItem (outside assertions). So an disabled item is consistently defined as any item returning an which id of 0 in the new itemset implementation. That's an improvement and it allows to use the "API" consistently. OTOH it is still ugly. :-) I consider the way how the ItemSet codes the "disabled" status an implementation detail. Now the interesting part is finding the clients of the itemset that rely on void items being interpreted as "disabled" by the itemset and fixing those Question is if that is more effort then replacing all code that puts items with ID = 0 with code calling "DisableItem" instead. That would make putting an item with ID=0 an invalid action. BTW: I don't remember if any of the two ItemSet implementations returns an VoidItem in a GetItem call for a disabled item or if NULL is returned then. IMHO it always should be the latter. Back to your primary topic. If we identify the places where a VoidItem with ID != 0 is put, and if the developers state that this is by intent, we can remove that assertion and make putting VoidItems with ID != 0 a valid action that does not disable that item. The question why ItemSet::Put must allow that nWhich differs from the item's which is still open. I assume that it's related to different pools having different WhichIds for the same item. But knowing it for sure would perhaps allow us to define a less fuzzy interface. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: about oov build
Am Wed, 16 Jun 2010 15:32:54 +0800 schrieb wangxiang : > *But another question comes back : I can't find the ".o" or ".so" > libs in the folder "/opt/openoffice.org3/program" (There's only an > "libnpsoplugin.so" in the folder )* > Is that right ? Yes, most libs are in /opt/openoffice (the "middle layer", see http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo) > *Because I want to build the sw module with debug information, and > replace the existing libs with the new build libs* Well, you should not need to do that with a machine-wide installation. You can either set: export FORCE2ARCHIVE=true or export PKGFORMAT=installed to get a tarball that you can simply unpack an run anywhere, or to get an runnable installation directly in the output tree of instsetoo_native (http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux#cite_note-Foot6-5.) Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] about oov build
Thanks, i have removed all the rpm installed by "yum" Then i go to the folder "/home/xwang/OpenOffice/OpenOffice_Dev/instsetoo_native/ unxlngi6.pro/OpenOffice/rpm/install/en-US_download" and the folder "desktop-integration" then install all the rpms, it becomes ok! *But another question comes back : I can't find the ".o" or ".so" libs in the folder "/opt/openoffice.org3/program" (There's only an "libnpsoplugin.so" in the folder )* Is that right ? *Because I want to build the sw module with debug information, and replace the existing libs with the new build libs* 2010/6/16 O. Felka > Hi, > > wangxiang schrieb: > > hello, fedora12 "yum install openoffice" in my computer no problem >> >> But when i build the Ooo with the latest hg version >> >> i use the "rpm -iv openoffice.org-*rpm" in the folder "instsetoo_native/ >> unxlngi6.pro/OpenOffice/rpm/install/en-US" >> >> then i run the "/opt/openoffice.org3/prgrams/swriter", it shows "Missing >> vcl resource. This indicates that files vital to localization are missing. >> You might have a corrupt installation." >> >> >> Is this because i didn;t install the "destop-intergration" ? >> >> >> Or missing other modules? >> >> >> Thanks, i follow this page to install >> >> http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux >> >> > have you removed all office rpms that are installed with yum before you > started the installation of native OOo? > > Olaf > > http://www.openoffice.org/ > > http://qa.openoffice.org/ooQAReloaded/FrameworkTeamsite/ooQA-TeamFramework.html > > -- > > Sun Microsystems GmbH Olaf Felka > Nagelsweg 55Quality Assurance Engineer > 20097 Hamburg > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.org > For additional commands, e-mail: dev-h...@openoffice.org > > -- Xiang Wang Institue Of Acoustics, CAS
[dev] Re: Building the Source Code
Am Tue, 15 Jun 2010 10:47:07 -0700 (PDT) schrieb Matt Wis : > I have installed Cygwin and the five modules listed at > http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Windows. > I cannot run configure. When I run "./configure", it says > "bash: ./configure: No such file or directory." Well, you should change to the directory with the source code before running the configure command. configure is a script in the root directory of the checked out source tree. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
