[dev] Re: Controlling undo/redo history and performing actions via the OpenOffice.org API?
Hi John, * The ability to hook a callback to the following events: o Whenever something is added to the undo history (with details of what the action was that was added, preferably by supplying the action as an object) OR whenever an action is performed which modifies the document (e.g. the Writer, Calc, etc. document) - again, with details of what the action was. o Whenever the 'undo' function is called (with details of what will be or was undone). o Whenever the 'redo' function is called (with details of what will be or was redone). API support for Undo/Redo has been added recently, and will be available in 3.4. There's also listener support for the Undo/Redo stack, however, you will only be notified that a change actually happened, you will not get all the fancy details of the change itself. The only concrete information about the action is its description, i.e. the string displayed at the UI. Since this is localized, and finally an implementation detail, it won't help you here. Besides that describing each change in detail in an Undo notification event would be expensive, it would also be a *very* complex data structure your listener would need to examine. If you're really interested in each and every change in a document, you should probably add dedicated (typed) listeners: I would assume (but am not sure at all) that every single modification to a document is notified by special listeners already. * The ability to save a full copy of the open document (Writer document, spreadsheet, etc.) to a given path (not the path of the document - i.e. saving a copy). OOo documents implement the XStorable interface: http://api.openoffice.org/docs/common/ref/com/sun/star/frame/XStorable.html#storeToURL * The ability to load a copy of a document into the existing window without prompting the user (the previous copy would have been saved, so I guess OO.org http://OO.org would not prompt for this), OR closing the current window and opening a new one (this second option is not preferred). Frames (where documents are displayed) implement the XComponentLoader interface: http://api.openoffice.org/docs/common/ref/com/sun/star/frame/XComponentLoader.html#loadComponentFromURL What I did find that seems promising are the following links: * http://openoffice.2283327.n4.nabble.com/api-dev-Attempt-for-an-UNO-Undo-API-td2954095.html that's a discussion preceding the actual implementation of an Undo API. * http://api.openoffice.org/docs/common/ref/com/sun/star/chart2/XUndoManager.html That's API-Undo support for chart only. In 3.4, it will be removed, and superseded by the new-by-then com.sun.star.document.XUndoManager interface. * http://openoffice.2283327.n4.nabble.com/api-dev-info-CWS-undoapi-new-UNDO-API-td3207049.html That's the announcement that the Undo API has finally been implemented. The third link also looks very promising, but I cannot find the referenced 'css.document.XUndoManager' in any of the API documentation. It is not online, yet, since the online version of the API documentation always follows the releases, and 3.4 is not released, yet. Nor can I find even 'css' or 'cws' in the API index, so this makes me think that maybe the undo/redo API is defined but not created yet - anyone know this for sure? css is a shortcut for com.sun.star, and CWS refers to a so-called child workspace, an entity where feature implementations happen before added to the main development trunk. Ciao Frank -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Relative URL
Hello Jan, how can I specify a relative URL for loadComponentFromURL() ? To my best knowledge, you cannot. In a possibly multi-threaded environment, relative would be completely meaningless, unless you explicitly pass the location to which your URL shall be relative to together with the URL - in which case you wouldn't need a relative URL at all. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Build broken - i116795
Hi Andreas, I can't edit anything in the bugreport. Whenever I try to change something I get this error message in big red squared letters: You tried to change the Ever confirmed field from 1 to 0 , but only the assignee of the bug, or a user with the required permissions may change that field. Maybe this happened because of the server move or user password changing. Strange, haven't seen this before. Though you don't have any special privileges in the DBA project in BugZilla, you should, as the submitter of the bug, be able to change nearly all aspects of it (except the assignee, as I just noticed - so assigning the bug to somebody else would indeed be difficult). I just tried logging in to BZ with some unprivileged account, submitted an issue, and did subsequent changes to it - which all went fine. So I am somewhat clueless about this problem. Can you confirm that you can edit the Product, Component, Version, Platform, Priority, URL, Whiteboard, Keywords, Depends on, Blocks, Status fields of the issue - in the sense that the respective fields are list boxes or edit fields? What exact changes do you try to do? Does just adding a comment still work, or is there more you attempt to change? And yes, I think this is basically caused by some problem with your BZ privileges, or some BZ setup, but I have no concrete idea so far. Would be great if you could help me tackling this, even if it distracts us, for the moment, from the concrete issue :-\ Ciao Frank -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Build broken - i116795
Hi Andreas, I've just wanted to post only a comment to tell you that your patch fixes it and still get the error. Uhm - the patches fixes it, *or* you still get the same error? To me, those are mutually exclusive :) Cofused Frank -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Build broken - i116795
Hi Andreas, hehe. your patch fixes my build. so the initial build issue is fixed. Okay, I'll commit the fix to our next CWS (dba34d) then. and the bug in issuezilla is still there even when only committing a comment I get the error message about the confirmed field. Hmm. Let me quote myself: :) Can you confirm that you can edit the Product, Component, Version, Platform, Priority, URL, Whiteboard, Keywords, Depends on, Blocks, Status fields of the issue - in the sense that the respective fields are list boxes or edit fields? Also, are you sure you are logged in with the same account with which you created the bug (andy...@openoffice.org)? Ciao Frank -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
[dev] Re: Build broken - i116795
Hi Andreas, It's CWS dba34b that breaks the build with system hsqldb(works with internal hsqldb). Please fix it. In this case oj is the canonic owner of your issue :) Can you please elaborate (in the bug) how to came to this conclusion, set the regression keyword, and assign the bug to oj? Thanks Ciao Frank -- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: sy...@openoffice.org with Subject: help
[dev] sub component tools/gnumake in IssueZilla
Hi, I took a GNU make sub component for the tools component in IssueZilla. Please direct any issues you have with the new GNU make build system to this sub/component. Thanks Ciao Frank - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] can i use MAP_PIXEL instead of APPFONT?
Hi limerlin, in XXX.src file： Set the size and location use of MAP_APPFONT My question is:Why use MAP_APPFONT? Can i use MAP_PIXEL? I think MAP_PIXEL more convenient。 While pixel might be more convenient, it would be a guaranteed way to break your dialogs. AppFont units are converted to pixels at runtime, based on your font size. This ensures that your text still fits into to the dialog and the controls. If you were using pixels, then the dialog would not scale with different font sizes, in particular, with different desktop themes. So, no, there is no way to use pixel units in resource files. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] GNU make build system and exported headers
Hi, just noticed (well, have been told) that in the new GNU make build system (oh, before I start any ranting: disclaimerGreat Stuff (TM), really!/disclaimer) it is expected that header files which are to be exported from a module reside in module/inc/module. And also, but my understanding might be wrong here: Files are exported *if and only if* they reside there. While it is great to clean up this which files are delivered from where mess we currently have, the above also implies that files from module/inc/module/* are not exported anymore, i.e. it is not possible to organize header files below the second module level. Instead, they all need to be thrown on a big fat header file pile. Is this understanding correct? If so, I think this is not a good idea at all: Consider modules such as toolkit, svtools and svx, where there is a more or less complex (well, let's say: well-arranged and -readable) folder structure below the module's include folder. Putting all those files into the flat module/inc/module folder will certainly not contribute to the readability of the source tree. So, are there plans to relax the above restriction? Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] GNU make build system and exported headers
Hi Björn, If so, I think this is not a good idea at all: Consider modules such as toolkit, svtools and svx, where there is a more or less complex (well, let's say: well-arranged and -readable) folder structure below the module's include folder. Putting all those files into the flat module/inc/module folder will certainly not contribute to the readability of the source tree. Why would you want to put them into a _flat_ structure? I don't want to. My understanding was it was required to, in the GNU make build system. Also note that from the named modules toolkit and svtools are already migrated to the new builds system. Just have a look at cws gnumake2. Uhm. You see me confused. The trigger of this question was a call from releng, which told me that in svtools, the content of svtools/inc/svtools/toolpanel had to be moved to svtools/inc/svtools, 'cause of the new build system, which would not support such sub folders ... Ciao Frank - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] help with dialog boxes
Hallo Kushal, nope, i dont have any dialog model yet. how can i get that from the XWindow(see code attached for reference)??? Ah, I see ... your code indeed works directly with window peers. This will also yield results (obviously, as you already have a working dialog :) ), however, it has disadvantages: One is the mentioned desktop/theme-dependency: Try switching your desktop theme to another (larger or smaller) font, and see how your pixel coordinates won't work anymore. Another is that parts of the API you're using is pretty unofficial, for instance, the window names to use at the toolkit are not officially documented, to my best knowledge. Okay, first let me suggest how you *should* do that, IMO :) - create the dialog you want in the Basic dialog editor. - search for the resulting .xdl file - include this file in your extension - at runtime, do the following (pseudo-code, more Java than C++, sorry): XDialogProvider dlgProv = ServiceFactory.createInstance( com.sun.star.awt.DialogProvider2 ) dlgProv. XDialog dialog = dlgProvider.createDialog( vnd.sun.star.extension://your-extension-identifier/path + /within/oxt/file/dialog.xdl; dialog.execute(); This has several advantages: - You can edit the dialog within Basic's dialog editor. While it is not the most convenient tool on earth, it still is better than creating the dialog programmatically. - Your dialog definition in the XDL file now has APPFONT coordinates, i.e. will not suffer from the desktop/theme size mentioned above. - You have access to the dialog model (see below), which will easily allow you to manipulate the dialog at runtime, using a reliable API. For accessing the model, just do XControl dialogControl = (XControl)dialog; XNameAccess dialogModel = (XNameAccess)dialogControl.getModel(); Now dialogModel contains an object which supports the css.awt.UnoControlDialogModel service. This includes support for accessing its children, removing and adding children, and property support as described in the service. The children then are UnoControl*Model instances, including full support for all properties described in the respective services. So, to answer your original question (how to add an image control) in this context: - add an image control to your dialog in Basic's dialog editor - set its Scale property (in the property editor) to the desired value - at runtime, retrieve the image control model: XPropertySet imageProps = (XPropertySet)dialogModel.getByName( imageControlName ); - set the ImageURL property: imageProps.setPropertyValue( ImageURL, vnd.sun.star.extension:// + your-extension-identifier/path/within/oxt/file/image.jpg ); = you're done :) Your second question about the font attributes would then be answered with: XPropertySet controlProperties = (XPropertySet)dialogModel.getByName( controlName ); FontDescriptor font = (FontDescriptor)controlProperties. getPropertyValue( FontDescriptor ); font.Weight = FontWeight.BOLD; controlProperties.setPropertyValue( FontDescriptor, font ); So, as you see, this approach would make some things easier ... If you'd insist on using your old approach for whatever reasons, then you'd need to lookup the window names (as to be passed in the WindowDescriptor) in toolkit/source/awt/vclxtoolkit.cxx - as said, they're not officially documented, so you'd need to look into the implementation. For an image control, fixedimage would be the name to use. For setting properties, you could still look up all the properties in the respective UnoControl*Model services in css.awt. Then, use the XVclWindowPeer::setProperty method of your XWindow: just pass the property name as obtained from the UnoControl*Model service description, and the desired value. This should work for all properties, including FontDescriptor. Hope this helps Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] help with dialog boxes
Hello Kushal, its my first time developing the dialog boxes, hence need some help. i have a dialog box to be implemented, for reference it can be seen here: http://wiki.services.openoffice.org/wiki/OpenOffice.org_Internship/Projects/2010/Customizable_html_export_for_Impress#Option_8 . the code i am using to put a fixedtext(label) on the dialog is: WindowDescriptor windowDescriptor; ehm ... What you do here is to create a mere window peer, without an associated control, or even control model. While this is possible, some things you'll want to achieve will become more difficult by this (admittedly, some will become easier ...) The correct way to do this would be - obtain the dialog model (I suppose you have one, yes?) - let it create a control model - insert this control model into the dialog model In pseudo-code, this would look like this XMultiServiceFactory controlModelFactory = (XMultiServiceFactory)dialogModel; XPropertySet controlModel = (XPropertySet) controlModelFactory.createInstance( com.sun.star.awt.UnoControlFixedTexModel ) controlModel.setPropertyValue( PositionX, ... ); controlModel.setPropertyValue( ... ); XNameContainer modelContainer = (XNameContainer)dialogModel; modelContainer.insertByName( MyControl, controlModel ); After the insertion, your dialog window (mxDialogWindow) will automatically have a new child window, which corresponds to the control model you just inserted. windowDescriptor.Type = WindowClass_SIMPLE; windowDescriptor.WindowServiceName = OUString( RTL_CONSTASCII_USTRINGPARAM(fixedtext) ); windowDescriptor.Bounds = Rectangle( 6, 46, 59, 13 ); Note that you're using fixed pixel coordinates here. This will work for your particular system/desktop/theme, but is likely to break on other desktops. The problem is that as soon as, for instance, the font size changes, your pixel coordinates will be wrong. Model properties (PositionX, PositionY, Width, Height), on the other hand, use AppFont coordinates: 1 means 1/8 of the average height/width of a character of the application's UI font. So, when you work with models instead of windows, your dialog will automatically adjust itself to different desktops. the question is,,, how can i set the font properties??? like bold,font size etc, i.e FontDescriptor At the model (controlModel in the above example code), you'd find a property FontDescriptor, being a css.awt.FontDescriptor structure, which has all the members you need. another question is how can i add images to mxDialogWindow, such that i can set its source URL at runtime along with other properties like stretch to fit??? Use the same code as above, but let the dialog's factory create an css.awt.UnoControlImageControlModel, and set its ImageURL and ScaleMode properties (http://api.openoffice.org/docs/common/ref/com/sun/star/awt/UnoControlImageControlModel.html) Ciao Frank - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] subsequenttests
Hi Stephan, I am not better at giving useful numbers here than you or anybody else are. If you want your tests integrated directly in the build, and think their failure rate is acceptable, go ahead, put them in the build. Will do. Probably as soon as your sb123 is integrated, so the necessary changes for splitting our existing complex tests into 100%- and less than 100%-tests does not conflict with your/Lars' work done there. People will start telling you if your assumption about tolerable failure rates matches theirs. (And if it doesn't, be prepared to remove your tests from the build again. Fine with me, and absolutely legitimate. Thanks Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] subsequenttests
Hi Stephan, So, I would be somewhat unhappy to throw all those they require a running OOo instance tests into the same unreliable category. See the list of sporadic failures at the end of http://wiki.services.openoffice.org/wiki/Test_Cleanup#unoapi_Tests_2. Many of them deal with problems during process shut down, and many of them are probably generic enough to not only affect qa/unoapi tests, but also qa/complex tests. Indeed, this list is horrifying. Given that the problems there not only affect UNO-API tests, or complex tests, but probably (potentially) each and every client accessing OOo via a remote bridge - shouldn't their fixes have a somewhat higher priority? (yes, that's a rhetorical question) However, if you have a complex test for which you can show that it works reliably enough on all relevant platforms and on all buildbots so that it can be executed during every build -- no problem to actually include that test in every build (i.e., go down the if there ever crop up new tests... route detailed in the OP). What would be your requirement for can show? 10 tests in a row which don't fail? 100? 1000? On one, two, three, four, five, or six platforms? In other words: I'd prefer doing it the other way 'round: Include tests for which we're *very* sure that they work reliably, and later exclude those for which reality prove us wrong. Personally, I'd put a large number (but not all) of dbaccess/qa/complex, forms/qa/integration, and connectivity/qa/complex (the latter only after the integration of CWS dba34b) into the reliable list. At the moment, I execute all of those manually for each and every CWS, but this is somewhat unfortunate, given that we (nearly) have a ready infrastructure to automate this. The trick is to let writing tests guide you when writing an implementation, so that the resulting implementation is indeed (unit) testable. See for example http://www.growing-object-oriented-software.com/ for some food for thought. However, how well this works out for us needs to be seen, indeed... Well, this the trick is ... part is exactly why I think that issueing a statement like from now on, we do tests for our code won't work - this is a complex topic, with a lot of tricks to know, so Just Do It! is an approach which simply doesn't work. But okay, that's a different story. Even if I (and others) get my fingers onto a TDD book (something I plan for a longer time already), this doesn't mean that everything is immediately testable without a running UNO environment (or even OOo). So, I continue to think having the infrastructure for this is good and necessary. One reason more to keep a subsequenttests infrastructure which can be run all the time (i.e. excludes unoapi) - we'll need it more sooner than later, if we take write tests serious. The subsequenttests infrastructure will not go away. And I urge every developer to routinely run subsequenttests for each CWS (just as you routinely ran cwscheckapi for each CWS in the past) -- it is just that its output is apparently not stable enough for automatic processing. Not even for manual ... There's a few quirks which gave me headaches in my last CWS'es, when I ran subsequenttests, and which finally often resulted in some Just Don't Do It habit. But that's a different story, too - and yes, we better should embark on fixing those quirks. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] subsequenttests
Hi Björn, Well, this the trick is ... part is exactly why I think that issueing a statement like from now on, we do tests for our code won't work - this is a complex topic, with a lot of tricks to know, so Just Do It! is an approach which simply doesn't work. But okay, that's a different story. I beg to differ: If code is not testable, it is not good and needs to be changed. You didn't get my point. Writing *good* and *useful* tests needs education, for most, if not all of us. Just do it! won't give you those tests, but just a pile of frustrated developers. So, the learning which is needed here (and the is needed here is the part which some of those saying just do it! miss) will be on a long and hard road. I didn't mean to say we should not take this road. I just wanted to say (and this was probably the wrong forum here) that words are easy, while doings are more difficult. If code is not testable, it is not good and needs to be changed. Sure. And if OOo is not stable for remote access, this needs to be fixed, since this is one of our most important features. And if a single feature of OOo is not accessible, this needs to be fixed. And if there is a crash somewhere, this needs to be fixed. And if code is not maintainable, this needs to be fixed. The list could be much longer. There are more things which need to be fixed than can be fixed, actually. It boils down to a question of priority. I fully agree to you that tests *are* very important (hey, accidentally, I just spent the whole day to write new tests for my current CWS'es changes!), but I would have a hard time arguing with my manager that I want to spend the next two years re-factoring the x*100.000 lines in my modules, to make them testable. So, seriously, please save me from this fundamentalist But it *must* be that way! phrases, and let's find compromises with reality. Thanks. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] subsequenttests
Hi Stephan, If there ever crop up new tests that do require a complete OOo installation, While I agree that the unoapi tests are quite fragile, the current subsequenttests are more than this. In particular, there are complex test cases which I'd claim are much more stable. (More precise, I'd claim this for the complex tests in at least forms and dbaccess, since we spent significant efforts in the past to actually make them stable and reliable.) So, I would be somewhat unhappy to throw all those they require a running OOo instance tests into the same unreliable category. I'm all in for disabling unoqpi tests in subsequent tests, but there are tests which I'd like to be executed by default, even if they require a running office. Other than that, I'd claim that for a halfway complex implementation, you pretty early reach a state where you need an UNO infrastructure at least, and quickly even a running office. So, I don't share your optimism that new tests can nearly always be written to not require a running OOo. One reason more to keep a subsequenttests infrastructure which can be run all the time (i.e. excludes unoapi) - we'll need it more sooner than later, if we take write tests serious. JM2C Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] How to get logs from non product builds
Hi Pavel, I have build a non-product build of 3.2.1 on Mac and cannot get any logs from it. I need output from RTL_LOGFILE_CONTEXT and similar macros. Wiki says that I should press Alt-Shift-Control 'D' to get some debug dialog but that does not work for me. RTL_LOGFILE_CONTEXT and friends are intended for profiling purpose, not for debug tracing. Thus, they're not captured by the usual mechanisms for debug tracing. See http://tools.openoffice.org/profiling/index.html for details, in particular for how to actually enable the RTL_LOGFILE_CONTEXT output - if profiling output is really what you want. However, if you want *debug tracing*, then you should use OSL_TRACE, OSL_ENSURE/OSL_ASSERT, DBG_ERROR/DBG_ASSERT. In a regular non-product build, OSL_TRACE output simply appears on the console you started OOo from, all others in a modal message box. For tweaking the output, Alt-Shift-Control is normally the right thing - however, on the Mac you might need to replace Control with the command key - not sure. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] How to get logs from non product builds
Hi Pavel, thank you for your explanation. I have recompiled some modules with profiling turned on. I need its output to easily see OO.o execution path. However my profiling logs are empty :-( They only contain data when OO.o is successfully started and terminated. That's difficult to diagnose from remote :-\, but what you describe sounds to me as if you want to use OSL_TRACE, not RTL_LOG*. OSL_TRACE directs it output to the console. In non-product builds (--enable-dbgutil during configure), or when a particular file is compiled with debug, OSL_TRACE effectively expands to printf, otherwise it is a no-op. How should that combination be pressed? Alt, then add Shift, then add Control and the D key? Or one by one in sequence? All at the same time. Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Prebuilt Mozilla DLLs on tools.openoffice.org differ from those in the installer
Hi Christian, Actually generating those prebuilts is something of a black art (esp. on Windows), so it might be hard to trace back why the differences wrt msvcr versions exist. Cannot speak for windows build, but dmake zip in moz after compiling moz will create those zips. I'd not call that black art :-) That's new then ... last time I had to bother with building SeaMonkey, it could be built with .NET 2005, but /not/ with .NET 2008, while OOo could be built with .NET 2008, but /not/ with .NET 2005. So, effectively, I always needed one build environment for building SeaMonkey and creating the prebuilts, and one for building OOo, using those prebuilts. The black art part was setting up the first of those two build environments ... Ciao Frank - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Prebuilt Mozilla DLLs on tools.openoffice.org differ from those in the installer
Hi Tor, So if you say that in an OOo installed from a downloaded installer, there are *Mozilla* libs (*not* OOo libs!) which are linked against msvcr90.dll, I'd b somewhat surprised. Do you have an example? Sure. For instance nspr4.dll and nss3.dll in an OOo installed from OOo_3.2.1_Win_x86_install_en-US.exe downloaded on June 25. Phh. Indeed: In the RC2 which I have here (and which should be identical to the final release), nspr4.dll is linked against msvcr90.dll. The strange thing is: In the respective WNTMSCIruntime.zip, which is committed to the sun-internal repository (in a module called moz_prebuild), and used during the build, the nspr4.dll is linked against msvcr80.dll. Conclusion: The files which finally appear in the install don't originate from the location they're expected to. Or I am simply not up-to-date - perhaps moz_prebuild is not the expected source of those files anymore. In any way, that's a question for our release engineering, I'd say. Ciao Frank - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Prebuilt Mozilla DLLs on tools.openoffice.org differ from those in the installer
So if you say that in an OOo installed from a downloaded installer, there are *Mozilla* libs (*not* OOo libs!) which are linked against msvcr90.dll, I'd b somewhat surprised. Do you have an example? Sure. For instance nspr4.dll and nss3.dll in an OOo installed from OOo_3.2.1_Win_x86_install_en-US.exe downloaded on June 25. ... Conclusion: The files which finally appear in the install don't originate from the location they're expected to. Or I am simply not up-to-date - perhaps moz_prebuild is not the expected source of those files anymore. Heureka! Both files you mentioned indeed do not come from the Mozilla prebuilts, but from the nss module. Nowadays, either SeaMonkey is built from scratch, or the prebuilts are used. In both cases, you get DLLs linked against msvcr80.dll. However, in module nss, the NSS libs are built, too, in the .NET 2008 environment, means they're linked against msvcr90.dll. This is (should be) completely transparent, i.e. if you download the prebuilts used from tools.openoffice.org, and use them in your build, but also build the nss module (there's a configure switch to disable it, IIRC), then the libs from the latter replace the libs from the former. So, in an ordinary OOo build, you should also get a nspr4.dll linked against msvcr90.dll. So, finally, http://www.quotationspage.com/quote/1114.html wasn't that appropriate over there at ooo-build? Ciao Frank - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] build verbosity
Hi, Starting with DEV300.m63, the build system of OpenOffice.org supports three different build verbosity levels, which can be controlled by an environment variable or a dmake parameter. A description of the different levels can be found at http://wiki.services.openoffice.org/wiki/Build_Verbosity. People maintaining a build bot might consider setting up a build verbosity level other than normal, for instance if they want to have the old yap-me-to-death build log. (though, seriously, a build.pl-feature to prefix the output of all spawned sub processes with a unique (process-)ID would be much more helpful in finding errors in the build logs of multi-process builds.) Have fun. Thorsten Behrens Frank Schönheit - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Moving to bost 1.3?
Hi, Currently, OOo uses boost 1.34.1 for platforms with a GCC =4, and boost 1.30.2 + a separated spirit 1.6.1 for all other platforms (see boost/download in the source tree). For various reasons, we'd like to clean up this mess, and move to a single version (containing spirit). This could be boost 1.34.1, but given that this version is pretty old already, we'd prefer a recent version - boost 1.39.0, that is. The work for this is ongoing in CWS boost134. In this CWS, a move to 1.39 has been done, and it compiles on the standard build platforms provided by Sun HH: Solaris Intel/Sparc, Linux 32/64, Mac OS X, Windows. We invite everybody porting OOo to another platform to give feedback to this project. As rumor has it, boost 1.39 creates problems when used on some platforms (either at compile- or runtime), so if your platform is know to be one of those, or if you just want to be sure - please give the CWS a try. If boost 1.39 proves to be too problematic, an option would be to indeed stay with 1.34 (on all platforms). This would require reverting a few changes in the CWS, but on the standard platforms mentioned above, an older version of the CWS, using 1.34, also compiled fine. Any feedback is appreciated. As an additional note, it has been suggested to not commit the boost*.tar.gz to boost/download, but make it a pre-requisite which needs to be downloaded before building. This would (for 1.39) save 50M in the repository for every version ever committed there. Opinions on this plan are also welcome. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build problems with CWS odff06 rebased to m50
Hi Christian, Frank Schönheit - Sun Microsystems Germany wrote: How to clear output trees? I'm a dummy concerning building. In cygwin, something like cd $SRC_ROOT find . -maxdepth 2 -name wntmsci12* | xargs rm -rf should do. nitpickthe * is not protected against expansion from the shell - but shouldn't matter since there is no soutput dir in $SRC_ROOT/nitpick Ehm - shouldn't the protect it? But I wonder why you don't simply suggest a dmake clean in toplevel. Because at least /me usually works in an environment where this doesn't work (no complete source tree) :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build problems with CWS odff06 rebased to m50
Hi Regina, ERROR: The following files could not be found: ERROR: File not found: emboleobj.dll ERROR: File not found: emsermi.dll ERROR: File not found: oleautobridge.uno.dll Sounds like some OLE-related module has not been built (correctly). According to trunk, emboleobj is built in module embeddedobj, emsermi in embedserv, and oleautobridge in extensions/source/ole. All three libs have in common that they are/should not packed (if not even built) when --disable-atl is given ( http://svn.services.openoffice.org/opengrok/xref/Current%20(trunk)/scp2/source/ooo/file_library_ooo.scp#418 http://svn.services.openoffice.org/opengrok/xref/Current%20(trunk)/scp2/source/ooo/file_library_ooo.scp#1037 ) This either means your build of scp2 was not successful, or contained remaints of a previous (non-disable-atl) build, or that your DISABLE_ATL environment variable is somehow broken: http://svn.services.openoffice.org/opengrok/xref/Current%20(trunk)/scp2/source/ooo/makefile.mk#224 What does echo $DISABLE_ATL on a console output? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build problems with CWS odff06 rebased to m50
Hi Christian, Because at least /me usually works in an environment where this doesn't work (no complete source tree) :) Doesn't dmake clean still work? If the question was: Should it work in an OOo env? I suppose it should. If the question was: Doesn't it work in the env you mentioned? No, it doesn't, since there's no makefile.mk for dmake to operate on. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build problems with CWS odff06 rebased to m50
Hi Regina, Searching with OpenGrok I see, that the file nametree.hxx is contained in DEV300_m49 but no longer in DEV300_m50. A file object.hxx exists but in store/source/ not in store/inc/store. Suggestions? If you did not clear your output trees after updating to the new milestone, a dmake depend=1 might help - it will throw away the old auto-generated file dependencies, and recreate them on the next dmake run. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: [l10n-dev] Localisation moved into own module
Hi Ivo, I guess that for building a language pack the OOo source tree would not be needed anymore, except maybe a few modules, is still a wish for the far future? MBA had the idea to move also all resource source files into a own module but we first need to discuss this a bit further Don't think this would be a good idea. I'd hate to deal with / build Yet Another 100MB monster if I just want to change a resource string in a project of mine. JM2C Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build problems with CWS odff06 rebased to m50
Hi Regina, How to clear output trees? I'm a dummy concerning building. In cygwin, something like cd $SRC_ROOT find . -maxdepth 2 -name wntmsci12* | xargs rm -rf should do. Alternatively, cd instsetoo_native build --from solenv --prepare should also do what you need, and also clear the so-called solver ($SRC_ROOT/solver, where all files built in a module are delivered to, to be used by other modules). Be aware that both approaches mean that you do a full rebuild of the complete OOo source tree after that. However, I often found the time spent for that a better investment than the time wasted for figuring out bugs caused by out-of-date build trees. a dmake depend=1 might help - it will throw away the old auto-generated file dependencies, and recreate them on the next dmake run. That doesn't help. I have also tried dmake depend=t and dmake depend=true. Hmm, sorry, no idea then. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: [l10n-dev] Localisation moved into own module
the DEV300 m51 milestones contains the cws l10ncleanup04 that moves all the translations that are spread over the office code to the new module l10n. Hey, wow, finally, well done! :-) Good news; not only for translators, but also for developers because now a recursive grep for some resource ID in the source directories doesn't produce a gazillion lines with localize.sdf content anymore. Indeed, that's great news, thanks! And if one wants to know to which source code module a certain dialog's message belongs, it should be possible to grep that from the one l10n/source/*/localize.sdf file. Just not for en-US :-( Well, en-GB most times probably will deliver the result. http://grok.services.openoffice.org :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] default patch owners for modules
Hi Caolán, Who should maintain the data included in the script? Developers themselves? Ideally I guess the developers who maintain/don't actually maintain a given module would update it themselves as owner there. That won't work. Most developers do not even know this list, and even if we tell them, they will have forgot at the time they resign from their maintainer role. The only feasible way is exactly what you're doing currently: Update as soon as we find it's necessary ... Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] default patch owners for modules
Hi Caolán, I generally use http://qa.openoffice.org/issue_handling/submission_gateway.html as my launch page for submitting bugs. Where do the default owners for patches there get filled in from ? Is it simply hardcoded into the html of that page ? i.e. I wonder if that page has fallen out of sync with reality in some cases. It definitely doesn't contain all the newer modules that have appeared, e.g. reportdesigner etc., and (no offence intended) mh is listed as the module owner for e.g. sal which doesn't seem quite right. http://qa.openoffice.org/issue_handling/create_submission_gateway.pl And yes, that's somewhat outdated. Feel free to check out, update, run, and commit the perl script :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Please fix these security flaws that could be considered bugs ...
Hi Malte, Wrt the wish to automatically remove entries where the document is no longer available: This is not so obvious for me. I sometimes open documents from encrypted containers or network shares which I mount on demand only, or from USB devices, so opening the menu in the wrong time would remove these items (not that I would care about it... ). I wish we'd had a The document ... does not exist anymore. Do you want to remove the entry from the 'Recent Files' list? [Yes] [No] message box for this purpose, raised when the user chose such a not-existent-anymore file. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Please fix these security flaws that could be considered bugs ...
Hi Rich, and maybe checking for unavailable files when the menu is opened, and making them visually different (either disabled, or coloured differently). threaded, of course, so that it does not block the menu, but updates it in the background, even while it is open :) Given that this is potentially expensive (consider files on the network, where checking the file existence can take minutes, depending on the network state), I wouldn't really consider this a good idea, even when done in the background. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] create/modify writer docs without running OO
Hi Dan, Using the tutorials in the wiki, I now know how to load, modify, and save writer docs using the API. However, we are writing a desktop app that we will distribute and would like to avoid distributing the open office executables (just the api libraries, would be preferable). All I need to do is add a graphic or two and some values in pre-specified locations. Is it possible to do this without using the OO services of a hidden OO instance and just either parse the doc or build an app from scratch using API calls? There's no stripped-down version of OpenOffice.org, but the ODF Toolkit at http://odftoolkit.org/ pretty much sounds like what you want. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Martin, From my perspective one reason for the high amount of regression is the high amount of integrated child workspaces short before a feature freeze. In the moment the ITeam (the QA representative) does the nomination before feature freeze. As an immediate action (for the upcoming 3.2 release) from my side I will limit this freedom until 4 weeks before feature freeze, in the last 4 weeks before feature freeze, In my opinion, it's strictly necessary then to have parallel development branches earlier than we have today. That is, if there are a lot of CWSes coming in, but not approved/nominated for the next release, then we should *not* pile them, but instead have a different branch to integrate them into. Else, the quality problems will be shifted to post-release only. An yes, extending the various phases we have - feature implementation, bug fixing, release canditates -, as suggested by Ingrid, would help, too. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Mathias et. al., The problem is ... Seeing many different explanations in this thread, and suggested solutions ... I wonder if we should collect some data about the concrete regressions, before we start speculating 'bout the larger picture. Oliver's table with the introduced in and found in was a good start, I think we should have this for nearly all of the regressions, ideally together with a root cause. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Ingrid, Two problems here. The worst one is that you cannot control that this new rule is applied. Who decides that a code change is too huge to risk it for the next release in two months or so? You won't count lines, don't you - that would be stupid. Those who are willing to act carefully are doing that already I am convinced. And those who are not acting carefully you cannot control really with this new rule. So introducing this new rule will basically change nothing. I beg to disagree. Of course, as you point out, there cannot be a definite rule of what change is too big in which release phase. But alone raising the awareness that large code changes are Bad (TM) after feature freeze might help. And if the analysis of current show stoppers reveal that a significant mount is caused by late big code changes, this is a good argument I'd say. So, let's not call this rule as it if you don't follow it, you'll be shot. I'd consider it a guideline which every reasonable developer would usually follow. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Thorsten, The problem is a bit more complex. The testers and test script writers do not have any time for writing new test cases for new functionality, they do not have time to check fixed issues in master, they do not have time to check code changes in a CWS as much as they should and at the end you are right, they do not have the time for real-life testing. That statement frightens me - way too many they do not have time, for my taste. Is there any chance to change this? Or have we already reached the point where the daily effort to keep QA running on the current (insufficient) level prevents us from investing the effort to make QA more efficient? For instance, is it possible that QA does not have time to write new automated tests because this is such a laborious and time-consuming task, but we do not have the time/resources to make it an easy and quick task? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] qa and qadevOOo
Hi Shuang, I notice there is a qa sub-module under each module, for example sw/qa, sd/qa.. but there is also a qadevOOo. Who can tell me the relation ship of these qa related modules? Does automation test of qadevOOo depend on qa of each module? How to build these /qa ? module/qa contains test cases for the module's code. Often, but not always, this is Java code which depends on the qadevOOo framework - so-called complex tests cases or UNO API tests. The concrete structure of the qa folder depends on the module, there's no general rule. To find out, I suggest you look for a makefile.mk somewhere in the qa folder (or subfolders thereof), and try what happens when you do a dmake. Either the tests are ran immediately then (which is the case for C++ test cases, usually), or the tests are compiled, and a subsequent dmake run or dmake run_test_name will will actually run it. Note that for the complex tests and the UNO API tests you need a running OpenOffice.org instances, started with the usual --accept=... parameter. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Ingrid, that now bite us, most of them have been found by users or testers *working* with the program. Adding more CWS test runs and so shortening the time for real-life testing will not help us but make things worse. I don't agree. Preventing the integration of bugs earlier in the production phase especially before the integration into the master trunk would give us much more freedom. Now we always need to react on show stoppers and react and react and uh then the release time line is on risk. All that, because the bugs are already in the product. If you instead detect the bugs before they are integrated into the product you can keep cool, refuse the bad CWS and thus not the release is on risk but only the single bad CWS. Hmmm ... difficult. On the one hand, I agree (and this is what you can read in every QA handbook) that finding bugs earlier reduces the overall costs. On the other hand, I suppose (! - that's an interesting facet to find out when analyzing the current show stoppers: found by whom?) that in fact the majority of problems are found during real-life usage. And nobody will use a CWS in real life. So, getting the CWS into the MWS early has its advantages, too. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Ingrid, There are more than the VCLTestTool tests. We have the performance tests and the UNO API test and the convwatch test. All those are in the responsibility of the developers. I think only convwatch is not mandatory. As far as I know, confwatch is mandatory, too. In theory, at least. In practice, I doubt anybody is running it, given its reliability. Which brings me to a very favorite topic of mine: We urgently need to possibility to run all kind of automated tests (testtool tests, confwatch tests, UNO API tests, performance tests, complex test cases - more, anybody?) in an easy way. Currently, this is *a lot* of manual work, and not remotely reliably (some test infrastructures are semi-permanently broken, and some tests produce different results on subsequent runs, which effectively makes them useless). As a consequence, a lot of those tests are not run all the time, and the bugs they could reveal are found too late. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Thorsten, Writing good test scripts isn't an easy tasks you are right. This is status for all software products. Writing test code costs more time than writing other code. Try it out with UNIT tests ;-) I know for sure. Writing complex test cases for my UNO API implementations usually takes the same time than the implementation took, or even more. Usually, but not always, I think it's worth it :) Okay, so let me make this more explicit: I see a ... remote possibility that our *tooling* for writing tests - namely the testtool - has strong usability deficiencies, and thus costs too much time for fighting the testtool/infrastructure, which could be better spent in the actual test. I might be wrong on that, since I seldom come in touch with testtool. But whenever I do, I feel it hard to believe we live in the 21st century ... Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Max, I just thought there is a higher chance of getting support for cygwin in the near time than having these automated tests in EIS. As far as I know, there's a group working on this. It would still leave us with the reliability problem (sometimes a test simply gives you bogus results, and the solution is to re-run it), but it would be a tremendous step forward. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Max, Do you know, how often a CWS returns back to development because of broken functionality, not fixed issues or process violation? of course in regards to process violation, nothing would change. I am talking about e.g crashing issues. If the developer tried it and it does not crash anymore, QA should not have to test the scenario again and waste time on reproducing the issue again(and again when closing the issue) Difficult to draw the line: Which issues need verification, which don't? Also, having seen a lot of misunderstandings (Oh! I though you meant *this* button, but now I see you meant *that* one!), I think it is a good idea that somebody who did not fix the issue verifies it. And the CWS is the the best place for this verification, I'd say. Also, IMO good QA engineers tend to not only blindly verify the concrete issue is fixed, but think about what they saw and did. Sometimes, this leads to additional issues, or discussions whether the new behaviour is really intended and Good (TM), and so on. At least this is my experience with DBA's QA, and I would not like to miss that, since it finally also improves the product. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Rich, summary - while release early, release often is very important, stable dev snapshots are as important. Yes, but how to reach that? In theory, trunk is always stable, since every CWS has undergone tests (before integration) which ensure that it doesn't break anything. Okay, enough laughing. Finally, that's exactly the problem here: Too many serious bugs slip Dev/QA's attention in the CWS, and are found on trunk only. If we fix that, trunk will automatically be much more stable. Easy to say, hard to do. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Max, yes, this is true, so would you say we could skip the step from going from verified to closed, doing this verification again? I'd say this gives the least pain/loss. (Though my experience with dba31g, whose issues were not fixed at all in the milestone which the CWS was integrated into, lets me be careful here. On the other hand, this was not discovered by the verify in master and close step, so ...) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Christian, Maybe in the cvs days. Now with svn there have been a couple of failed integrations, quite a number of changes that were reverted by other cws. Using the verified-closed step to find broken tooling/SVN/integrations/builds sounds weird, doesn't it? So, this shouldn't be a permanent argument (though it might be a good one at the moment), but only hold until the root causes are fixed. So I don't have trust in that number. And this makes it really hard to check when your fix was integrated in mXX, but later gets reverted by integration of another cws in mXX+4. You never can prevent that. If you verify-close the issue in mXX+2, you won't find the reversal in mXX+4, anyway. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hello KP, Promoting QA in community is not enough - you have to retain people. In order to retain people project needs to fix their issues, which inspires people to use milestones in daily work. Many of developers do not know how great it feels when issue you are interested in gets fixed relatively quick. Developers also do not know that it sucks when fix for your issue is delayed and delayed. I'd claim a lot of developers, if not most, know how this feels - in both ways. It's just that we have much more issues than developers, and developers have only a pretty small amount of time for fixing for retaining people. In combination, this might look like developers do not care for the issues reported by other people, but it's just not as easy as this. I think many users would rather have faster fixes than more stable milestone (you always can go to prev release/milestone). Uhm, I doubt that. What you're saying here is that we should sacrifice quality to more fixes. I believe this would be bad for OOo's overall reputation. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Thorsten, The time to master isn't a problem currently, I think. That's not remotely my experience. See dba31g (http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=7708OpenOnly=falseSection=History) for a recent example of a CWS which needed 36 days from ready for QA to integrated state (and add a few more days for the milestone to be finished). A few more? dba31a: 26 days dba31b: 42 days dba31e: 26 days dba31f: 13 days dba31h: 23 days mysql1: 17 days (and that one was really small) rptfix04: 9 days (though this number is misleading for other reasons) dba32a is currently in QA - for 9 days already (which admittedly is also somewhat misleading, since a regression was fixed meanwhile without resetting the CWS to new). Okay, there were also: fixdbares: 2 days dba31i: 7 days Don't get me wrong, that's not remotely QA's alone responsibility. Especially the first OOO310 milestones had a lot of delay between CWSes being approved and being integrated. But: time-to-master *is* a problem. At least for the majority of CWSes which I participated in, over the last months. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Mechtilde, So more testing on CWS is also welcome! Yes Full ACK to last sentence. And this is not only a task for the Sun people. The persons who are interested at a CWS must be able to test a CWS. And this also if they aren't able to build OOo on their own. I think especially we in the DBA team have good experiences with providing CWS snapshots at qa-upload. I am really glad that our community (including you!) does intensive CWS QA, and this way also found bugs pretty early. However, as good as this worked out for us, I am unsure whether this would scale. I suppose if *every* developer would upload his/her CWS, then people would pick a few only, and the majority would be still be untested. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hello Kirill, Uhm, I doubt that. What you're saying here is that we should sacrifice quality to more fixes. I believe this would be bad for OOo's overall reputation. What I mean to say is that we could sacrifice quality of snapshots to bring in features faster and to motivate QA volunteers to test in real life (fast-paced development is yet another usage motivator). Besides, it is questionable what is worse for reputation - having 2-3-4-5 y/old usability defects or bugs versus regressions. But bringing CWSes faster into the master would not yield the developer's output. In other words, we would not be able to fix only one more bug by that. At the opposite, I would assume that if we reduce the snapshot quality in the way you propose it, then developers would be able to fix *less* issues, since they would need to do more regression fixing, which is the more expensive the later in the release cycle it happens. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Mathias, I don't see a lot of sense in making tests mandatory just because we have them. If a test probably can help to find problems in areas where we know that we have them, fine. So when tests are defined it's necessary to see which problems they can catch and if that's what we need. I had a look on the regressions that I can judge - some of them might have been found with convwatch, for most of them I have serious doubts that any test we have would have found them. It's still working with the product that is necessary. So until now I fail to see which tests could help us further without burning a lot of time. Quite true ... A personal goal I set for the 3.1 release was to write complex test cases for (most of) the show stoppers found in the DBA project. Since we regularly run our complex tests on all CWSes, at least those concrete stoppers would not have much chances to re-appear. (And as it is usually the case with complex test cases, they also cover related areas pretty well.) Unfortunately, we didn't have too many 3.1 stoppers so far :), so I am not sure whether it will help. But it's worth a try, /me thinks. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] amount of stopper / regressions for 3.1 release
Hi Mechtilde, I don't think that the developer have to upload each CWS build. I prefer that the possible tester are able to pick up the CWS builds they want beside the normal test scenario. Ah, you're right, that would be most helpful ... Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] UNO API exception specifications (was: [dev] Error handling in OOo, shouldn't we show additional info.)
Hi Mathias, However a reasonable error handling would look like, IMO carefully re-designing UNO to add more exceptions specifications to (a lot of) methods is a must-have. +1 Just to play the devil's advocate: without careful considerations that would end in adding throws css.uno.Exception to any method, though perhaps it's the right approach for all generic APIs (generic APIs need generic exceptions - don't they?). Don't think so. I suppose the line is to be drawn (if at all) between ¨high level¨ and ¨low level¨ API (whatever that means :), where the former has an increased chance of throwing a WrappedTargetException (which I'd consider more appropriate than a generic Exception). OTOH designing exceptions right is very hard and often needs a lot of thinking. So I don't expect that we can fix that in a big bang release, we will need quite some time to fix that. I would be happy if we would allow for such fixing. I don't want to fix all of those at the same time, but being able to fix them incrementally, as they bite me, would be great. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Simplify Reference Casts by template constructors
Hi Rainman,
After a period of time of developing with URE, I find the C++ UNO
class Reference is not very comfortable for use sometime.
The problem is, when I have a reference of base interface XA and a
reference of derived interface XB, I can't make xA = xB directly.
Instead I have to query XA from xB like this xA = ReferenceXA::query(xB).
¨xA = xB.get()¨ would do, too, and be less expensive.
I wonder that whether we can use template constructors to simply this
situation.These constructors may something like this:
template typename interface_type
class Reference
{
template _interface_type
Reference(const Reference_interface_type rRef)
{
interface_type* p = NULL;
_interface_type* _p = NULL;
p = _p; // compiling time cast check.
_pInterface = iquery( rRef.get() );
The last two lines could be to just assigning (and aquiring) rRef.get()
to _pInterface.
}
...
Now we can simplify the cast code above to
xA = xB;
I am not sure we should do this, implicit constructors usually add
ambiguity ...
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] UNO API exception specifications
Hi Eike, OTOH designing exceptions right is very hard and often needs a lot of thinking. So I don't expect that we can fix that in a big bang release, we will need quite some time to fix that. I would be happy if we would allow for such fixing. I don't want to fix all of those at the same time, but being able to fix them incrementally, as they bite me, would be great. Unfortunately, adding exceptions to a method changes the API contract, so fixing things incrementally would incrementally destabilize API use. what do you mean by destabilize? The only problem I see is that classes implementing the respective interface need to be adjusted, too, which of course is error prone. If this adjustment is not made, implementations throwing the new exception might crash (at least on platforms where the compiler respects the throw specification on a method, and generates code to assure it). Nonetheless, I think that's manageable. (Side note: If the tool generating our C++ headers would have the - long-desired - feature to create a ¨#define DECLARE_XFOO¨, then the problem would be less severe, as then a simple recompilation would adjust the headers, and the not-adjusted source files would simply break during compilation.) We'll need some versioned API for this. I guess many are missing such thing and didn't do useful but not required changes for just the reason of API compatibility. Not sure we need versioning, but we definitely need to way to (carefully) break compatibility. As I've been told, this has been a topic on this week's engineering steering committee meeting ... Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Simplify Reference Casts by template constructors
Hi Rainman,
I have another ideal, it is better and safer than the last one I mentioned.
I add a conversion operator to Reference, instead of a constructor, here is
it:
template class base_interface_type
inline SAL_CALL operator const Reference base_interface_type ()
const SAL_THROW( () )
{ return Reference base_interface_type ( get() ); }
I tested some cases, and it works well.
How do you think it? I am not very sure it will work for all situation.
Uhm - implicit conversion operators are Evil (TM) :)
This is a place where my gut feeling says we should sacrifice the little
convenience we could gain (xA = xB instead of xA = xB.get()) for
clarity. At least clarity in reading code, but also clarity in reading
the error messages which the compiler would raise for incompatible xA
and xB :)
Admittedly, this feeling is not backed up by strong arguments, but I am
sure others could come up with some. Stephan?
Btw, did you compile the complete OOo from scratch with this change?
Would be interesting to know whether the existing code already survives it.
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] UNO API exception specifications
Hi Stephan, The only problem I see is that classes implementing the respective interface need to be adjusted, too, which of course is error prone. If this adjustment is not made, implementations throwing the new exception might crash (at least on platforms where the compiler respects the throw specification on a method, and generates code to assure it). What about language bindings other than C++? Basic an Python ignore are not affected by changed exception specifications, as far as I understand. Java code would need to be recompiled, which would break until the code is adjusted (right?). However, this is probably something on the ¨to-be-accepted¨ list, if we allow for such a change in the UNO API (and this allowance was my premise for this discussion). What other language bindings are there? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] UNO API exception specifications
Hi Rony, *The former: it is just frustrating to have a program bomb and get a message like exception occurred. (Yielding the message: go, figure...)* which nicely fits into the original thread :) Fixing those exceptions (which I consider buggy in the current messageless-shape) to carry a meaningful message would address the original problem of the thread as well as the API consumer's problems. (MM: Sorry, could not resist :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi T. J., May I agree, wholeheartedly? From my own long years of dealing with users (some of them very angry), I conclude that the *error* is what bothers them, not the error *message*. They just want to get their work done. A little techno-babble is only a small point. ... Consider the opposite case, where user and programmer are _under_whelmed by lack of information. A real case: Line 1: Error saving the document filename : Line 2: Error writing file. I would *kill* for a little techno-babble here (for once, I get to wear the angry user hat). Then I could report the bug, with a chance that somebody could fix it, even without a reproducible case. Okay, I see your point here. I am still not convinced that transporting the information via css.Exception.Message is the best idea ever, and won't cause problems later on, but I definitely see your point. Logging errors is an excellent idea. Keeping such logs short enough to avoid burdening the file system, or performance, but long enough to be useful, is only a small problem, with several possible solutions. But logging is a longer-term enhancement, No. Logging facilities are available, and the same script which produces a add file/line info to exceptions patch could equally easily produce a add logger calls patch. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Okay, I see your point here. I am still not convinced that transporting the information via css.Exception.Message is the best idea ever, and won't cause problems later on, but I definitely see your point. See my other mail in response to Stephan's comment, which I saw after I wrote the above ... Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Stephan, For one, end-user oriented exception messages simply do not work in general (think about the category of unchecked or runtime or programmer made a coding mistake exceptions---what use is it for the end user to see a localized Index i=7 was out of bounds of array xyzStrangeList (ranging from 0 to 3)?). For another, common practice *is* to put developer-oriented data into exception messages. For randomly picked evidence of the latter take, for example, a quote from Item 45 of Effective Java: The string representation of an exception should not be confused with a user-level error message, which must be intelligible to end users. Unlike a user-level error message, it is primarily for the benefit of programmers or field service-personnel for use when analyzing a failure. Therefore information content is far more important than intelligibility. (Of course, there is nothing wrong with questioning common wisdom. I just personally think that common wisdom is indeed right here.) And the quote you cited might be an indication I am wrong here :) (though I could try to debate about the difference between an exception's string representation and the exception message :) As a consequence, this would mean that our error handling infrastructure is even worse than I thought: If we cannot use Exception.Message to transport user-messages, or information to *generate* meaningful user messages, then ... With very few exceptions (sic), none our exception classes has additional fields for transporting the necessary information. (Not to mention ... I remember having seen an exception class with an error code field which was not even documented, and used non-UNO SFX-internal error codes. Argh!) So, let's pave our exception messages with techno-babble, for the sake of usability ... who cares :( Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Mathias, When we talk about seldom, hard to reproduce errors, then let's introduce a logger which is permanently switched ON, or at least switched ON for log levels = LogLevel.SEVERE. (by default, loggers are OFF, i.e. do not log any event, regardless of the LogLevel.) Everything that must be switched on doesn't help read again, please: ¨permanently switched on¨ was what I wrote :) Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Without having the bigger picture how good error handling should look like while we are at it, and mentioned UNO incompatibility already ... I just came across (yet) another issue where a severe error was silenced instead of propagated to the caller (and thus caused document corruption), simply because the respective UNO method (XFilter::filter) was poorly designed, and did not allow to throw any but a RuntimeException. However a reasonable error handling would look like, IMO carefully re-designing UNO to add more exceptions specifications to (a lot of) methods is a must-have. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
/implement, thus making it even more unlikely (than today) to ever happen. For instance, by putting file/line into the exception message, we will close the door for putting other meaningful information into Exception.Message, because in two years from now on, some people will say that adding other content will break the file/line info feature ... Without having the bigger picture how good error handling should look like, how can we know the suggested solution will fit into this bigger picture, instead of preventing it? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Mikhail, The first idea was to provide information similar to the assertions. Each extension could use the macros wrapping the existing text and adding the file name and line number. Since usually the text is based on the constant string literal, the generation of the string would not affect the performance. As much as I agree that error handling needs to be improved, I don't like the idea to pollute exception messages with information about the file where the exception happened. This information should be separated from the mere message, since the latter is (potentially) to be shown to the user, but the former usually isn't. But perhaps I get you wrong here, since you also talk about a details window provided by the InteractionHandler, which would imply that either the handler needs to strip the error location from the message (ugly and error prone), or that you want to transport the location by other means than by appending it to the message. In case of exceptions that have no arguments ( and we have many of such cases ), Shouldn't we change those exceptions to actually *contain* a message? And, more important, teach ourself to *not* throw exceptions which do not contain a message? If our exceptions had a message, it would be easy to search for the message in our code base, and find the place where it is thrown. As said above, exception messages are often displayed to end users (imagine Basic scripts), so I always strongly disliked the throw FooException() places, since this results in FooException. being displayed to the end user, which is in no way helpful, and simply a usability bug. So, to make it short: We should provide meaningful error messages when throwing exceptions, this would solve the problem, too, in an even broader context. we could use a default macro for each type of extension, that would not take so much time I think. That could be actually done by a relative simple script. Don't let that script run over my modules, I continue to consider places without a message a bug, and prefer fixing this bug instead :) In result the InteractionHandler could get the requests containing additional information. This information could be shown in a kind of details... subwindow of the error message. There were already suggestions from UX to extend the error messages with such a details window. The framework and applications also would have a chance to provide this additional information in this way. See above - how should this additional information be transported, if not mangled into the Message member? In general it looks from the first view to be realistic even for OOo3.2. From other side it is only a very quick first view, so any suggestions, corrections and etc are very welcome. http://wiki.services.openoffice.org/wiki/Category:Logging We have good experiences with this. For instance, our JDBC-SDBC bridge is paved with logger calls. When logging (for this particular logger) is not enabled, then this costs nearly no time, since it is just about noticing that nothing needs to be logged. However, when it is enabled, then the result is a log file which we can use to examine what went on on the user's machine (Since the user has to explicitly enable this, and send us the log file, this isn't a privacy problem). In particular, the component has a central method for throwing exceptions, and there, all to-be-thrown exceptions are logged. Together with method entry guards (enter foo( bar ), leaving foo with result x), this allows a pretty good analysis. So, my suggestion would be to create dedicated loggers for your components, and log the to-be-thrown exceptions. Of course, you then cannot display this information to the user in OOo's UI. However, I strongly doubt that information like This exception was thrown in SomeClass::doSomething() line 12345 is really something which belongs into the UI. That's a diagnostic, and diagnostics are nothing you should slay Joe Average with. (And no, hiding diagnostics behind a Details button doesn't really make it better.) For diagnostics, use a dedicated diagnostics channel, which can be enabled by the experienced/willing user on request. Just my 2^W50 cents. Ciao Frank - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Mikhail, My intention was to allow user provide the developer with information that identifies the source of the error. That's understood. It would be useful in case of problems that appear once a year, and look to be mysterious from the first view. Ugly is a taste-related comment, so it is hard to argument for/against it. As for error prone transportation, a screenshot solves this problem easily. The error-prone (and also the ugly, but let's omit that :) related to something else: When you transport the file/line information via the error message, then you need to strip it before you actually display the message to the user. I would consider this an essential requirement, from a user experience point of view. While it is helpful to you as a developer when somebody gives you a screeshot reading Access denied. foobar.cxx, line 134, it is certainly not at all helpful for the average end user who does not intend to send you the screen shot, but is happy with the Access denied message already. Moreover, it is not only not helpful, it will definitely (IMO) alienate the average end user. (Access denied might be a bad example, since this end-user message is probably generated from some error code, and not an actual exception message, but I hope you get the idea.) As a consequence, you *must* strip the file/line info before displaying the message, and this is what I called error-prone. (If I had a wish, I'd vote for changing UNO incompatibly, and adding a Stack member to the css.uno.Exception class instead. Oh, well, just dreaming :) By the way, the rework would take much more time, than the script adding the lines. From this point of view, it is better to let the script run and have at least the line numbers in the messages, than to dream how we change all the extensions in our office. s/extensions/exceptions/, I suppose? Well ... I hate to say that, but the approach you suggest is clumsy, in my opinion, for the reasons outlined above. And the argument We do not have the time/resources to make it right, let's do it the quick and dirty way instead is something which I hear too often (and suffer from too often, months or years later), for my taste. But okay, that might be only me. In any case, I *strongly* suggest you ask user experience what they think about slaying end users (who do not want to send you the screenshots) with file/line information. But even if all of them have messages ( thousands of unique messages? ), the filename and linenumber will stay the best unique identifier, as actually assertions prove. One other note: Did you try how this adds to library size, if all those exceptions are padded with additional strings? Don't want to say it's not bearable, just wanted to mention that you should keep an eye on this, too. Completely agree, we should. But again, I would not mix those two solutions.. See above. In my opinion, the one solution is not a solution, but a hack only :) [logging] This is a nice solution. It would help in our case, although the minus is that it has to be turned on before the problem happens. And some problems of the mentioned kind, are hardly reproducible. Reproducibility is a problem indeed. Seeing that our latest versions towards 3.1 have this OpenOffice.org improvement program feature, where user actions are anonymously logged, I wonder whether log all thrown exceptions is something which belongs to OpenOffice.org improvement, too. That is, if a user volunteers to let OOo collect data which helps us making OOo better, why not also logging the thrown exceptions then? Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Error handling in OOo, shouldn't we show additional info.
Hi Stephan, Even if there happen to be exception instances where the exception message is designed to be meaningfully presented to an end user (do you indeed use localized exception messages?) (yes, indeed, we do) this is not true for the majority of exception instances (where the exception message is something that can help a knowing person track down the problem, but not something that is meaningful for the average end user---for example, it is always in English). Which I'd consider a bug. If I run an arbitrary macro in Basic which uses the UNO API, any exception which is caught there is reported to the end user. Speaking techno-babble which is not meaningful (I tend to think that Basic developers still are allowed to be, though not necessarily are, average end users) is a usability issue, in my opinion. For the latter, I see no problem with augmenting the exception message with file and line information (other than the ugliness inherent in C/C++ macros). For the former, you should simply exempt those instances from Mikhail's wholesale macrofication, I would say. I suppose our fundamental question indeed is whether Exception.Message is an end-user feature, or a diagnostic means. If it's the latter, then file/line are well suited there - but it's this premise I doubt. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Get started
Hi Roman, Max already have you some pointers, but one note on the following: I using VisualStidio 2005, so could you help me to get started? As far as I know, VS2005's compiler is not supported for the current code line anymore. You should get an Express edition of Visual Studio (it's for free, and lacks some features, but those are not essential for OOo work). Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [releases] Re: [l10n-dev] Re: [releases] Re: [l10n-dev] changed strings in 310_m1
Hi Pavel,
We might have a communication problem. In my understanding, changing
resources so that the effective strings stay the same, but maybe
identifiers change, or strings are moved within files, or such, is an
alloed change.
string is and ordered set of: { actual string, identifier }.
If you change identifier, the string is changed.
Okay, this is completely new to me (and I bet I'm not the only one).
Apologies for the problems caused in OOO310.m1 then, and I'll know the
next time.
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] changing the patch mechanism for external sources
Hi Ause, in the current scenario, there is only one active patch per source tarball which has to contain all required changes for the build. as discussed in issue 40246, this may lead to duplication and hard to maintain patches. with the changes done in the cws ause099, each change now will reside in its own patch. for the local module makefiles, the only visible change is PATCH_FILE_NAME - PATCH_FILES. this variable now hold the list (and apply prder) of the existing patches. That's great news indeed, it will make patch maintenance (and more importantly getting rid of patches) much easier. Thanks! Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] idlc warnings - why ?
Hi Oliver,
can one give me a hint, why i get warnings for the following *.idl files ??
...
module bw {
module stv {
module tvs {
module structedit {
module tool {
interface XGetSomething :
com::sun::star::uno:: XInterface {
string saySomething([in] string
_something);
};
};
};
};
};
};
I suppose both the warning are triggered by the underscore at the
beginning of the in-param. (one warning explicitly when compiling the
file, one warning implicitly when including the file in the service
definition IDL).
IIRC, this violates UNO naming conventions, though, admittedly, I think
the convention is bogus in this case :)
Ciao
Frank
--
- Frank Schönheit, Software Engineer frank.schoenh...@sun.com -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] RSS feed to EIS?
Hi Bernd, Well the fine grained control suggestes by you Frank is not as easy to implement as it might first look like: there´s lot of places where different kinds of changes to data in EIS is being made and each one would have to be reviewed and decided upon wether and what kind of mail users on such CC list should get when a change occurs. For example owners and QA Reps already get mails on status changes, so I suppose users on such a CC list should get them too except that for the situation that they are also the owner or qa rep than they should not get 2 identical mails for the event of course. And what about comments added would you want users on such a CC list to get email for that or not. And what about other minor important information like when somebody changed the location field of the CWS or just did set the flag that the CWS is help relevant would you want an extra email for that too or not and so on... We could *define* such a CC field as if you're subscribed here, *every* change is notified to you. Period. Finally, that's how other tracking systems (and I really think CWS data in EIS in this respect is pretty much the same as issue data in IssueZilla) work, too. As for the duplicate mails: I suppose making the set of reciepients unique immediately before sending the mail shouldn't really be difficult. With such a feature, we would have the subscribe for selected changes in all CWS - that's the RSS feeds, and the subscribe to all changes of in selected CWS - that's the CC list. So, something for everybody :). I of course would use the latter ... Btw. I'd also say that members of a CWS, as well as the owner/QA-rep, should be handled as if they were subscribed to the CC list. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] RSS feed to EIS?
Hi Philipp, Btw. I'd also say that members of a CWS, as well as the owner/QA-rep, should be handled as if they were subscribed to the CC list. -1 the QA-Rep at least is not going to profit from these mails in the least. Even as a member I don't want these notifications, there is enough crap in my mail inbox every day already. I can see some usefulness to me as owner but actually even then I don't really want to get a mail every time one of the other one or two members commits anything; usually what they are doing is rather independent. Not sure if we have a misunderstanding here - I was not talking about commits, as in svn commit. I was talking about changes to the CWS'es administrative data in EIS - adding a comment, changing one of the CWS properties, changing the CWS'es state, and the like. This is something which IMO happens seldom enough so that it won't really spam your intray. Like in IssueZilla, there could be a mechanism in the back-end which prevents mails from being sent to the instigator of the change himself. That way, you would only be noticed of changes done by other people to your CWS. On the other hand, if you say this is still too much, I'd be happy with the explicit opt-in you mention, too. Ciao Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Moving files in a Subversion CWS
Hi Bjoern, As an (ugly, very ugly) workaround for now, we might need a command in the cws tool that registers the moved files by their old name (the name it is known as on the master) somewhere. This could be either in a svn property (on trunk??) or in a administrative file somewhere. It should at least be noted, if changes to a file are wandering to /dev/null. Perhaps a postprocess hook which sends mails to EIS, keeping track of moved files, and issueing warnings upon integration when some change is about to be lost? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Moving files in a Subversion CWS
Hi Heiner, I wouldn't call for a complete ban but it looks like one has to be extra careful. Restructuring should be done in CWS which lives only a very short time. Best, say, opened on one milestone and integrated in the next (as first CWS) this would minimize the potential for data loss. I'd say that anything which does not *eliminate* the potential for data loss should be a no-go. Sorry, but I really do not like finding out short before a release (or even short after it) that some important fixes done during the last 6 months just silently vanished. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] RSS feed to EIS?
Hi Ariel, I'd like to keep truck of some CWS activities in EIS (well, mostly when they get integrated), are there RSS channels to this kind of info? I've been searching with no luck, so I guess there is none, but... I'd love to have some kind of CC functionality to EIS. That is, you can subscribe yourself to a CC list for a given CWS, and then all changes to this CWS are mailed to you. Pretty much how CC lists in issue tracking systems work. Would be most fine grained control over how many mails you get (only the ones you're really interested in), and should on the other hand be pretty simple to implement :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] RSS feed to EIS?
Hi Ariel, I'd like to keep truck of some CWS activities in EIS (well, mostly when they get integrated), are there RSS channels to this kind of info? I've been searching with no luck, so I guess there is none, but... I'd love to have some kind of CC functionality to EIS. That is, you can subscribe yourself to a CC list for a given CWS, and then all changes to this CWS are mailed to you. Pretty much how CC lists in issue tracking systems work. so this means: No there is no such a functionality. Uhm - well yes, I really wasn't too explicit here :) Would be most fine grained control over how many mails you get (only the ones you're really interested in), and should on the other hand be pretty simple to implement :) does this mean Please, file an issue? In that case, who owns that (component/subcomponent/owner)? Not sure if EIS RFEs are handled via IssueZilla, too. I'd say component=tools, subcomponent=??, owner=bei (Bernd Eilers). Usually, Bernd is reading here and picking up easy-to-fix ideas quickly, but an issue might help. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Moving files in a Subversion CWS
Hi Stephan, So, back to good old manual merging: Remember which files you moved in your CWS, and after every rebase, check whether they miss any changes to the original files. Sigh. With the additional hurdle that nobody will warn you about the lost changes. If the compiler finds them, that's fine, but if you just lose a small bug fix, then may not notice this at all. However, what worries me deeply is the [not] true data loss scenario upon svn merge --reintegrate described at http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branchmerge.advanced.moves . A disaster waiting to happen, I would say. Or am I missing something? I tend to agree here. Just recently asked Heiner about this, and in my opinion, both scenarios effectively mean we should completely ban svn move, as it has a pretty large potential to silently destroy our code base. Which is a pity, as this is *the* feature of SVN which made it worth suffering the additional complexity introduced with it. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Build m37 breaks with HsqlDatabase.java:53: package helper does not exist
Hi Eike, Looks like connectivity/prj/build.lst needs a dependency on qadevOOo, or am I mistaken? You aren't, /me thinks. Feel free to write me a P1 issue, so we can fix this in the next build. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Build m37 breaks with HsqlDatabase.java:53: package helper does not exist
Hi Rene, Looks like connectivity/prj/build.lst needs a dependency on qadevOOo, or am I mistaken? You aren't, /me thinks. Feel free to write me a P1 issue, so we can fix this in the next build. but please guard this with an ENABLE_QADEVOOO or however it is caled variable so that it doesn't break when --disable-qadevooo is specified. Sure. And can such stuff please be communicated? Which such stuff? Assuming that I didn't introduce the build breaker intentionally, the conclusion is that I simply wasn't aware of the fact that connectivity did not yet depend on qadevOOo, and that I forgot to check this. That said, there was nothing to announce, since I can't announce what I am not aware of. So, what do you refer to here? Or is it that you don't share the above assumption? TIA Whatever that means. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Who can closes an issue[ was: Fwd: [l10n-dev] Spanish version : issue in OLH
I find it very abnormal that the person who shoots an issue can't close it. abnormal is a somewhat strong word :), but yes. I suppose the ability to resolve/close issues is bound to the canconfirm privilege - which users don't initially have, instead they need to apply for it. Sadly, we don't really have control over IssueZilla, so it's effectively impossible to change/enhance IZ's permission system. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] SVN and lineends
Hi, modifying a .cxx file on Windows, and committing it to SVN, followed by a svn diff -r PREV file, shows me that *the complete* file changed with the commit. Doing a svn diff -r PREV -x --ignore-eol-style file shows me only the changes which I just did. Conclusion: We have a problem with our line endings - we certainly do *not* want to have a thousands-line-change-set for every file we modify/commit on Windows, do we? Shouldn't we set to svn:eol-style property to a reasonable value (native, probably) for all our source files, globally? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN and lineends
Hi Heiner, Let me hear your thoughts. Should we go to svn:eol-style native? For which file types? Or should we stay with Unix and require that people use editors which preserve the line end conventions? Is that even possible for the more popular editors (I use vim, so I wouldn't know). This requirement can hardly be fulfilled, I assume. At least not without alienating a lot of developers. For instance, there is (AFAIK) no such option in Microsoft Visual Studio, and I would *hate* to switch between two applications when debugging/editing a source file. For the file types, I'd be happy with an initial list containing .cxx .hxx .src .hrc .txt .mk .pmk .java .cpp .h. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
Hi Björn, Given that pre- and postcommit hooks are basically working the same, using this precommit hooks as a base to create a postcommit hook should be easy. See issue 95199 for my currently prepared (and already implemented) solution, though a post-commit hook also sounds interesting. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
Hi Bjoern, I just tried to add an svn:ignored dir. That works. Sure - svn:ignore is just for ignoring the item in status and recursive commits. If someone does a svn diff in a module, and sees: ? source/somenewfile.cxx ? source/somenewfile.hxx he might be tempted to do a 'svn add *; svn ci -m my message' and goes to grap a coffee. When he returns he has happily commited the output trees. That seems kinda dangerous to me. Well, admittedly the intention for my svn:ignore request was never to prevent people from committing them. As I wrote in my original mail, it's about the noise produced by svn status which bothers me. (For instance because I usually check my CWS for uncommitted files before passing it to QA or finally deleting it). If somebody really commits an output tree, we can still a) shot her and b) do an svn delete (which nowadays is much easier than fixing the same problem in CVS would have been.). If we svn:ignore output trees, we should also prevent them from being commited (if we have a list of platforms that are svn:ignored, we could also specifically look for those in the precommit hook). I am undecided here. If you wish - do it. It might be harder to achieve, as it requires people to update the script when new platforms are born, and in opposite to updating svn:ignore, that's nothing an ordinary developer can do. BTW this is just as dangerous when having the output trees in global ignore in the config. I never claimed to invent the idiot-proof solution :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] SVN-ignored files
Hi, now that we start working with SVN-based CWSes, those module output trees (common[.pro], unxlngi6[.pro], wntmsci12[.pro] etc.) become somewhat inconvenient, as they clutter your svn status output, for example. http://wiki.services.openoffice.org/wiki/OOo_and_Subversion#Ignoring_output_trees discusses this, and suggests to add those names to the global ignore list, claiming this is better than adding them as per-directory property. I beg to disagree, for the following reasons: The global ignore list applies to each and every location in the source tree, where we actually want to ignore those output trees only in the module directories. So, using the global list is overkill, and makes using files/folders, which match the respective pattern, in other locations unnecessarily difficult. Second, using the global ignore list for that purpose is something which everybody needs to do for himself (and for those of us working on different Windows machines without roaming profiles, it means doing it on every machine). Third, The Book, in http://svnbook.red-bean.com/en/1.5/svn.advanced.props.special.ignore.html, has a sentence which also suggests we should use svn:ignore instead of the global ignore list: The global list of ignore patterns tends to be more a matter of personal taste and ties more closely to a user's particular tool chain than to the details of any particular working copy's needs. Surely the our output tree names/locations are a facet equal across all working copies, so we should address the issue in the repository. In short: Can we please add the platform-dependent output tree names as svn:ignore property to all modules? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN-ignored files
Hi Heiner, On 10/16/08 11:00, Malte Timmermann wrote: In short: Can we please add the platform-dependent output tree names as svn:ignore property to all modules? +1 +1 -1 I tried to explain why I think the property-approach is better, please also elaborate why you think it isn't. Just saying no without explaining why has a small taste of ... dictatorship. (And the only your argument I saw so far, on the Wiki page, is it's clumsy, which isn't really convincing.) Thanks Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN-ignored files
Hi Heiner, Well, this +1 or -1 one in s a kind of vote and you normally don't have to explain your votes. Note that I didn't say We will not do this, I'm the maintainer of this stuff, basta! :-) Just a vote. Ah, okay ;) These are roughly 50 platforms times 191 top level dirs, about 9550 entries to maintain. That I call clumsy. Since most of the platforms are only interesting to a few people I feel that having this in the so called global ignore list might not be unreasonable. (Didn't know we have that much platforms ...) Well, every time we switch to a new compiler on a new platform (which happened quite some times in the younger past), every developer working on the respective platform has to adjust the global ignore list in his Unix Home, and in $(APPDATA)\Subversion on each and every Windows machine he's regularly using. Multiplying all those developers with all those profiles probably does not sum up to 50*191, but in opposite to maintaining the SVN property (which can be done by simple scripts), maintaining the config files is manual work. So, I still think putting the stuff into SVN is better ... (Hey, what did we do the migration for if we don't use all the cool new SVN features?) ... at least for the *most common* platforms - what the *#+%$# is unxhpxr? And how many people will ever encounter it in real life, compared with unxlngi6, unxmacxi, and wntmsci12? As for I can't use the platform names in the ignore list readily: Well this is a good(TM) thing. You should not use this names, they are reserved for the build process. Well, yes, sure. Except that the ignore list you suggested in the Wiki also excludes files like common_data.txt ... Also, the reservation of those names only is true for the module root folders (i.e. the location where the prj sub folder resides), not for other locations. At least this would be my understanding, though you could say that the names are (by definition) reserved globally, and I'd easily accept that. If you insist on using them, well there is always the --no-ignore switch to svn add, or you just explicitly add a path with this name. Once a path is under version control the ignore list has no effects anyway. I know (I meanwhile read the FM :) - I intentionally wrote makes it difficult, not makes it impossible. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN-ignored files
Hi Heiner, [...] Well, you probably already noticed that I'm somehow not very enthusiastic about maintaining these 1 entries. Remember, you'll have to add the properties every time someone invents a new top level directory, which means with most milestones. We have 191 modules so far, and certainly *much* more milestones than 191, so the most is surely exaggerated. And you have to change all 200 of them if someone adds a new platform. But if someone volunteers for this task I won't veto it. Oh, and it can easily be introduced by a CWS, so no Releng is needed for this :-). Sigh. I'll take the list of platforms you mentioned (is it complete? Is it correct), and Just Do It (TM). Finally, this will give me a chance to practice my Perl, and (more important) to play a little with SVN, which is still pretty new to me. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: testautomation the effects on the CWS process
Hi Thorsten, I know that developers want to start it from the command line. Well, developers want a way to easily judge the quality of their work. I don't care whether testtool can be run from command line, it's just the environment I'm used to ... If you give us a possiblity to run testtool scripts by pressing a button in a web front end - well, fine (for now, until we have the all-in-one-QA-solution we recently talked about :). So, please consider make a tool to well, do something. In the majority of cases, it's currently used to compile and build and link and ... But there's no technical reason it cannot be used to run tests, all kind of tests, that is, including UI tests. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
Hi Heiner, Yes, this can (and should) be done by RE, if we decide drop the VCS keywords. Most probably not m33, but at some time in the near future. would be good. Another huge change which could be done in the same milestone is to convert tabs to 4 spaces, something I know Kendy and some others are advocating. Uhm - but this will *certainly* give *a lot* of resync conflicts, won't it? As much as I am for having spaces instead of tabs, the trouble we would get with such a global conversion is not worth it, IMO. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
Hi Heiner, 'svn merge -x -b' is your friend ... You mean ... I really should go reading this Handbuch? :) Could be done, and the earlier the better I guess. As long as we still have CVS-based CWS'es, which need to be migrated ... not sure. Finally, migration will probably usually happen by create a CWS in SVN, based on the latest milestone, and *patch* in the changes of the CVS-CWS. In this case, svn merge is of no help. Instead, it would require people to create the SVN-CVS on an pre-tab-replaced-by-spaces-milestone, then apply the patches, then lift the SVN-CWS to a post-tab-replaced-by-spaces-milestone. Not a good workflow, IMO. So, if we really want to do this replacement, I would do this only when we can really rely on the power of svn merge being available in all cases. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
Hi Heiner, As long as we still have CVS-based CWS'es, which need to be migrated ... not sure. Finally, migration will probably usually happen by create a CWS in SVN, based on the latest milestone, and *patch* in the changes of the CVS-CWS. In this case, svn merge is of no help. Instead, it would require people to create the SVN-CVS on an pre-tab-replaced-by-spaces-milestone, then apply the patches, then lift the SVN-CWS to a post-tab-replaced-by-spaces-milestone. Not a good workflow, IMO. So, if we really want to do this replacement, I would do this only when we can really rely on the power of svn merge being available in all cases. The trick would be to migrate CVS stuff to a SVN based branch @m32 and then rebase with svn merge to something newer ... = problem solved. Yes, that's what I tried to describe above - it's a two step migration of the CWS, instead of a one-step one. I don't have a feeling for working with SVN, yet, so I cannot judge whether this is really a big overhead. Not to mention that even if it isn't, people will forget it's two-step instead of one-step ... Finally, I wouldn't do everything now and immediately, just because it could be done easily. Let's just get this SVN migration done (and I'd consider it done when people *halfway* know how to use it, and when no CVS-based CWS for DEV300 exist anymore), and then let's start with something else - like tab replacement. Doing too much at the same time just makes life unnecessarily difficult. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
+1 for the proposal +1 Is this something which can/should be done by release engineering, for instance with the switch from m32 to m33, globally? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] STL Implementations clash
Hi Andrey, I am writing an OO.org extension that is a thin wrapper around a C++ library, which is compiled externally. I think the latter is the problem - you need to compile the library within the same environment as you compile OOo, in particular against STLPort. Note that that's a requirement before releasing the final version of the extension, anyway: Since the library will to be part of your extension, anything except compiling both with the very same settings would open the door to too much compatibility problems. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] help sought: building moz2seamonkey01 on Windows
Hi Christian, What I am looking for is a volunteer who could do the Windows build the CWS moz2seamonkey, including the Mozilla-build (i.e. without the above-mentioned configure-time switches which effectively disable it). If this said volunteer could work with Pierre/me to solve any problems which might appear during the build, this would be even better, if course :) I could build that CWS on our Windows buildbot. All I have to do is fiddling the configure parameters...(because Mozilla is imho disabled per default on that Bots). I'll buy that one then, thanks. (I admit I had hope that some of the people saying please replace the stone-aged Mozilla code with something new would step in :) I think I'll stop by your office for the details Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] help sought: building moz2seamonkey01 on Windows
Hi Rene, (I admit I had hope that some of the people saying please replace the stone-aged Mozilla code with something new would step in :) Not on windows, no :) :) We're glad about any help on the other platforms as well. Currently, Pierre does Linux, and Eric builds on Mac (and /me has to find the time for Windows). Any helping hand on other platforms (and probably even on the same platforms, with some other compilers or the like) is appreciated. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Basehttp://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sitz der Gesellschaft: - - Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten - - Amtsgericht München: HRB 161028 - - Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer - - Vorsitzender des Aufsichtsrates: Martin Häring - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] the NEW STYLE service may import great complexity to implementation.
Hi Juergen, Hoping to see your marcos soon~ hehe. i am not fan of macros and the skeletonmaker can be already used for both (declaration and forwarding). I think it is no real overhead and changes are not so often. Which is merely wrong - in case we're talking about API which is currently being developed. In such a situation, I often come across new facets of the problem which require the API to be adjusted (yes, this might be a deficiency of mine - finally, one should be able to first design properly, and then implement, right? :) About the overhead: Feeding skeletonmaker with the type library path and the like arguments is not really fun. Doing this *every time* is *definitely* overhead compared to typing DECLARE_XFOO just *once* in the header. I agree that it would be or can be smart for the developer but not for people who wants to read/understand Hmm? What's difficult to read about DECLARE_XFOO or FORWARD_XFOO? or debug the code later on. Every decent debugger has a step into feature. Applying this to a FORWARD_XFOO line in the header is not much different from applying it to an explicit forwarding in the .cxx file. Anyway i will think about it ... This is also what you said last time I brought up this idea/request :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
