[dev] Programmatic control of Toolbar Items: ComboBox possible?
I'd like to know if the new "programmatic control of menu and toolbar items" feature will allow me to create a custom ComboBox in a toolbar. Thanks. Matthias
[dev] why soffice cann't run while mozilla plugin is running
hi all, There is no the thread of soffice. Then I use mozilla open a odt file. I find a soffice thread in the system. I run "/opt/openoffice/program/soffice" in a terminal. But I cann't see the UI of openoffice. Why??? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning-Free Code
On Tue, 2005-08-30 at 18:50 +0200, Mathias Bauer wrote: > Ken Foskey wrote: > > On Mon, 2005-08-29 at 17:59 +0200, Stephan Bergmann wrote: > > > >> If someone think it's reasonable to suppress a warning, this must be > >> discussed with the team members. It should also be discussed in public, > >> using the mailing list [EMAIL PROTECTED] Please start the subject with > >> “compiler warnings:”. > > > > * Initially I would suggest -Wno-reorder (I think) > > > > There are a HUGE number of errors caused simply by the order of the > > variables in the class declaration and I have only found one instance > > where it indicated a real error (parent initialisation depended on child > > data). The needle for this one is small and the haystack particularly > > large. Because of the pervasiveness of this change merges afterwards a > > PAINFUL! I speak from experience. I would think about doing this > > module by module as a separate exercise. > > Just to make sure that I understood correctly: you suggest to ignore > these warnings but work on it in a subsequent CWS? > > This is a real useful warning that can find some really nasty errors, so > we should definitely work on keeping it activated, but of course if > there are so much places that trigger the warning it could be a good > idea to postpone it to a later CWS. Yes, In my experience this warning leads to a lot of changes. Doing this initialy will make the whole process really tedious, (as opposed to simply tedious). It will also break a lot of merges of patches. -- Ken Foskey OpenOffice.org developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning-Free Code
Ken Foskey wrote: > On Mon, 2005-08-29 at 17:59 +0200, Stephan Bergmann wrote: > >> If someone think it's reasonable to suppress a warning, this must be >> discussed with the team members. It should also be discussed in public, >> using the mailing list [EMAIL PROTECTED] Please start the subject with >> “compiler warnings:”. > > * Initially I would suggest -Wno-reorder (I think) > > There are a HUGE number of errors caused simply by the order of the > variables in the class declaration and I have only found one instance > where it indicated a real error (parent initialisation depended on child > data). The needle for this one is small and the haystack particularly > large. Because of the pervasiveness of this change merges afterwards a > PAINFUL! I speak from experience. I would think about doing this > module by module as a separate exercise. Just to make sure that I understood correctly: you suggest to ignore these warnings but work on it in a subsequent CWS? This is a real useful warning that can find some really nasty errors, so we should definitely work on keeping it activated, but of course if there are so much places that trigger the warning it could be a good idea to postpone it to a later CWS. Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning-Free Code
On Mon, 2005-08-29 at 17:59 +0200, Stephan Bergmann wrote:
> Warning free code is a basic precondition for robust industrial quality
> code. This as well is current scientific knowledge as the result of the
> personal experience of Hamburg-internal engineers, as well as the
> opinion of some OpenOffice.org developers like e.g. Ken Foskey.
So I would actually recommend against an all out warnings push unless
everyone is VERY clear the objective is to highlight bugs not to remove
warnings. The difference in objectives is very important.
** If in doubt leave it alone. **
I am also concerned that then process will become a template fix.
if( fp = fopen( "file", "r" )) {
can become:
if( (fp = fopen( "file", "r")) ) {
If I assign someone to clean up the error, say a junior programmer
because it is menial, and we have this code:
if( x = 4 ) {
They may very well apply the 'template' solution hiding a useful
warning.
if( (x = 4) ) {
That useful warning being removed is WORSE than the problem of many
warnings. This gets really tricky when you get into essoteric C++
warnings.
The objective of the push should be to highlight bugs by removing as
many warnings with obvious solutions as possible. If in doubt leave the
warning!
As Pavel has hinted it is possibly better to work through one warning
class at a time, eg assignment bugs. This can be discussed so that the
approach to each is correct, eg don't just bracket them.
--
Ken Foskey
OpenOffice.org developer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] compiler warnings: STLport; doubunder; OSL_VERIFY
As anounced elsewhere, we want to discuss here all C/C++ compiler
warnings we stumble over on CWS warnings01 and that we want to disable.
Now, I have three issues to discuss:
1 STLport
I already wrote this before, but maybe it did not get the necessary
attention. To ensure that all spurious warnings from within any STLport
headers are suppressed, the following changes are necessary:
On unxsoli4 and unxsols4 the warnings inllargeuse ("function is too
large and will not be expanded inline") and notemsource ("Could not find
source for function") are globally disabled in each compilation unit
(regardless of whether or not it includes an STLport header), because
those warnings seem to only be generated at the end of a compilation unit.
On wntmsci10 the warnings 4514 ("unreferenced inline function has been
removed") and 4710 ("function not inlined") are globally disabled in
each compilation unit that includes an STLport header, from the point of
inclusion onwards, because those warnings seem to only be generated at
the end of a compilation unit.
2 doubunder
On unxsoli4 and unxsols4, to suppress the doubunder warning "There are
two consecutive underbars in __sal_NoAcquire", IMO it is best to disable
doubunder globally. For one, __sal_NoAcquire is part of our published
API, so we cannot easily change it, and for another, there are probably
more similarly broken identifiers waiting for us in the rest of the code.
3 OSL_VERIFY
On unxsoli4 and unxsols4 PRODUCT builds, OSL_VERIFY(a == b) causes a
spurious warning "The result of a comparison is unused" (because the
argument of OSL_VERIFY is always executed, even for OSL_DEBUG_LEVEL ==
0). Instead of disabling the corresponding unxsoli4 and unxsols4
warning, I would vote to change code
OSL_VERIFY(e);
to
if (!e) {
OSL_ASSERT(false);
}
(and thus work around the warning) on the ground that OSL_VERIFY is
dangerous and confusing---unlike the other OSL diagnose functions, it
*does* evaluate its argument for OSL_DEBUG_LEVEL == 0. In the interest
of the "least surprise" principle, we IMO should deprecate OSL_VERIFY
and replace all its occurrences as described above.
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Targetmilestone OOo 3.0 in IssueZilla
Hi, I got requests from several people to introduce a new target for the next feature release (beyond 2.0.x). Neither the name nor the time frame for a next feature release is determined yet, but I expect that there will be plans proposed and discussed in the next weeks or months. For this reasons I would like to introduce a target milestone OOo 3.0 to make planning and doing for issues beyond 2.0.x more visible. This work can start in child workspaces based on latest SRC680 milestones. The time of creation of a new master code line is not determined yet. If we decide to have an earlier release than 3.0 it might happen that we create two different codelines and retarget a bunch of issues for 3.0 to a 2.x target. Please set only issues to a specific target if you or your team is committed to fix them in a reasonable time frame or the issue is of high priority (match P1 or P2 criteria). People which don't have the knowlegde or the resources to fix issues may use the voting mechanism for issues (http://qa.openoffice.org/scdocs/votehelp.html) to indicate their demand. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning-Free Code
Pavel Janík wrote: From: Stephan Bergmann <[EMAIL PROTECTED]> Date: Mon, 29 Aug 2005 17:59:29 +0200 > free. We plan to do this massive (in number of files affected) change > for post--OOo-2.0. I forgot to ask in first e-mail. Post-2.0. You think of 2.1 or 3.0? Or? We currently think of 3.0. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning-Free Code
Ken Foskey wrote: On Mon, 2005-08-29 at 17:59 +0200, Stephan Bergmann wrote: If someone think it's reasonable to suppress a warning, this must be discussed with the team members. It should also be discussed in public, using the mailing list [EMAIL PROTECTED] Please start the subject with “compiler warnings:”. * Initially I would suggest -Wno-reorder (I think) There are a HUGE number of errors caused simply by the order of the variables in the class declaration and I have only found one instance where it indicated a real error (parent initialisation depended on child data). The needle for this one is small and the haystack particularly large. Because of the pervasiveness of this change merges afterwards a PAINFUL! I speak from experience. I would think about doing this module by module as a separate exercise. In the low-level modules, up to offuh, I only came by a handful of such warnings, so I just changed the code there. Lets see what the experiences are when we go up the module tree, and we should definitely keep your words in mind, thanks. * Second possibly -Wno-unknown-pragmas. Not came by a single instance of that one, yet. There are a few pragmas for VC that are in the code and don't really affect things. I have bracketted them but effort for return is fairly low. * Before you start you might want to merge cws waratahbasctl. This is a warnings cws that has lingered for want of a QA person. Have a look at the assignment bug contained within. I will have a look at that one, thanks. * I also have a large number of patches that I can apply to save you time. I will also volunteer to assist :-) Are these patches visible anywhere? I ask because if each patch is concerned with a single module, for example, it would IMO make sense that the person assigned for that module directly coordinates with you what to do with that patch. * In the interim I would recommend adding immediately BY DEFAULT -Wparentheses to the gcc compile. This really does highlight a number of problems with the code, good return error for extra warning ratio. -Wparentheses is already covered by -Wall (remember, our aim is to make the code base -Wall clean). And yes, I too alredy found more than one error thanks to that switch... Thanks again for your input, -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning-Free Code
On Mon, 2005-08-29 at 17:59 +0200, Stephan Bergmann wrote: > If someone think it's reasonable to suppress a warning, this must be > discussed with the team members. It should also be discussed in public, > using the mailing list [EMAIL PROTECTED] Please start the subject with > “compiler warnings:”. * Initially I would suggest -Wno-reorder (I think) There are a HUGE number of errors caused simply by the order of the variables in the class declaration and I have only found one instance where it indicated a real error (parent initialisation depended on child data). The needle for this one is small and the haystack particularly large. Because of the pervasiveness of this change merges afterwards a PAINFUL! I speak from experience. I would think about doing this module by module as a separate exercise. * Second possibly -Wno-unknown-pragmas. There are a few pragmas for VC that are in the code and don't really affect things. I have bracketted them but effort for return is fairly low. * Before you start you might want to merge cws waratahbasctl. This is a warnings cws that has lingered for want of a QA person. Have a look at the assignment bug contained within. * I also have a large number of patches that I can apply to save you time. I will also volunteer to assist :-) * In the interim I would recommend adding immediately BY DEFAULT -Wparentheses to the gcc compile. This really does highlight a number of problems with the code, good return error for extra warning ratio. -- Ken Foskey OpenOffice.org developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] starbasic variables and type declarations
Dear Christian, > -Original Message- > From: Christian Junker [mailto:[EMAIL PROTECTED] > Sent: maandag 29 augustus 2005 21:22 > To: dev@openoffice.org > Subject: Re: [dev] starbasic variables and type declarations > > > Sven, > > 2005/8/29, Victoria, Sven <[EMAIL PROTECTED]>: > > > Note that I declared otxtfield of type Variant, not of type Object > > > because there are some rare situations where it would > fail declaring a > > > variable of type Object. > > > > ? > > Can you give more insight on this matter? > > I have never actually used Dim x as Object so I have no experience on > unexpected results. The Developer's Guide talks about prefering > Variant over Object so I just went that way not investigating on that > matter. Ok, I have seen most examples (still) using Objects, so I figured you might have some insight info on this, on why it is not good to do so. > > > Doc = StarDesktop.CurrentComponent > > So Doc is a document ... ok ... but what can I do with a document? > > [...] > > Surely there must be more to a document than only these methods? > > But how do can I find this information from this point on? > > Sure there is, the thing is that the Starbasic interpreter takes a lot > of work away from you, as do other scripting interpreters. The Basic > engine actually binds all exported interfaces your referenced object > to it (behind the scenes). That's why you don't need to use > queryInterface calls that can frequently be seen in Java/C++ code, in > order to invoke a method. That the queryInterface() call is hidden is one thing I can only applaud. > > It would be really nice if on the the api page of OfficeDocument > > (or XComponent) references to subclasses (or > implementations) are included. > > It has! Click on the "Use" link that appears for every idl object at > the top. At some places the lists are not complete, so if you find an > interface that can be accessed from a certain object and its not > listed there, just file an issue for it. Ah! that's much better indeed. > > I guess that the Variant construction is the way to go :( > > There is nothing sad about it, if you choose well-named identifiers, > Starbasic should be one of the easiest programming languages to read > (+ understand) in my eyes. hmmm... (here i go again...) autocomplete would make it _really_ easy. I have read that with Java the NetBeans IDE can be set to include autocomplete on UNO objects. From the point of a Java programmer defining everything as Object (Variants) is then a no-no. As for a Basic programmer on the other hand it is indeed easier to define everything as Variant because it is easier however the ms office visual basic editor has autocomplete too <\careful>. You may wonder why I am poised on autocomplete? Editors are better at supplying the information I need rather then me searching for it i.e. I'm lazy. Nevertheless, thanx for the feedback, it was helpful. Best regards, Sven Victoria > -- > Best Regards > Christian Junker > > - > 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] Warning-Free Code
Hi michael, michael meeks wrote: On Mon, 2005-08-29 at 22:49 +0200, Pavel Janík wrote: great. Can you do all of your work on 64bit operating systems? ;-) > The team members should also have a look at the 64-bit CWS > (ooo64bit02) to see what data sizes they already changed. In view of the long-standing non-functioningness of the ooo64bit02 cws - the fact that it breaks 32bit operation ;-), the sheer scale of the problem and the problems of keeping it synchronized with the latest developments - conspire to (in Kendy & my opinion[1]) ensure that this "1 massive cws" will never be finished, and would be really difficult to test & verify - and even harder to get momentum on getting it up-stream at all. Since Heiner is keeping the ooo64bit02 cws update from time to time I'm not aware of problems to keep it up to date with latestet developments, at least not a this time. It makes sense to think about to separate issues from this child workspace to get them integrated earlier and have the fixes available in time so that there would by a synergy between ooo64bit02 and warnings01. In our view it would be far, far better to split up the fixes out of that wherever possible and merge them as parts of other, smaller, incremental CWS' - that can be easily reviewed / shown to be safe, and serve to move the code base to a progressively 64bit-cleaner environment. That would also allow us to start running tinderbox builds over the pieces that are known to work to ensure they don't subsequently break ( at least at compile time ). ie. it'd be great to see people pulling nice looking bits out of 64bit02 and merging them IMHO ;-) If the participants see possibilities to divide the problem in meaningful parts this should be discussed on this list, otherwise we take the risk of uncoordinated and doubled work, HTH, Michael. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning-Free Code
On Mon, 2005-08-29 at 22:49 +0200, Pavel Janík wrote: > great. Can you do all of your work on 64bit operating systems? ;-) > >> The team members should also have a look at the 64-bit CWS >> (ooo64bit02) to see what data sizes they already changed. In view of the long-standing non-functioningness of the ooo64bit02 cws - the fact that it breaks 32bit operation ;-), the sheer scale of the problem and the problems of keeping it synchronized with the latest developments - conspire to (in Kendy & my opinion[1]) ensure that this "1 massive cws" will never be finished, and would be really difficult to test & verify - and even harder to get momentum on getting it up-stream at all. In our view it would be far, far better to split up the fixes out of that wherever possible and merge them as parts of other, smaller, incremental CWS' - that can be easily reviewed / shown to be safe, and serve to move the code base to a progressively 64bit-cleaner environment. That would also allow us to start running tinderbox builds over the pieces that are known to work to ensure they don't subsequently break ( at least at compile time ). ie. it'd be great to see people pulling nice looking bits out of 64bit02 and merging them IMHO ;-) HTH, Michael. [1] - correct me if I'm wrong Jan :-) -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning-Free Code
Hi Stephan, thanks for that announcement! - Added SAL_INT_CAST (for C) and > std::static_int_cast and Here (of course) sal::static_int_cast was meant ... std::reinterpret_int_cast (for C++) and here sal::reinterpret_int_cast. to sal/types.h That has already been correct in the code, this remark only clarifies the posting. Additions to namespace "std" would be violating the C++ standard. Nikolai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
