Re: [api-dev] Re: Missing interfaces in OOo 3.2: Why not a blocker?
On Thu, Nov 26, 2009 at 6:00 PM, Michael Stahl michael.st...@sun.com wrote: yes, i removed the XTextField interface at the writer's SwXTextPortion Could you give a list of all interfaces that were removed (at least XTextContent and XTextField) so that we can check our code. Matthias - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Re: Missing interfaces in OOo 3.2: Why not a blocker?
Hi, On Fri, Nov 27, 2009 at 1:48 PM, Juergen Schmidt juergen.schm...@sun.com wrote: Daniel B. wrote: Since our (and potentially a lot of other) extension breaks with this change this is a major issue that prevents us from rolling out OOo 3.2. Reverting the change until OOo 4.0 would give us enough time to update our extension and roll out the updated version. So I support Michael's suggestion to re-implement the interfaces that are missing, at least temporary, and document the change so that people are aware of the issue and can adapt their macros/extensions. until now you are the only one with this problem. How many places using this code do you have in your extension? We gave you the necessary info to do it correct. It should be not really a big change i guess but anyway. I let it up to others to decide if it is a showstopper or not. But how can we prevent you from rolling out 3.2 when it is not already final and released? Either you change your broken or wrong extensions or we do the changes back. You have to do it anyway in the near future whereas we have double work. Sounds not really optimal ;-) We really shouldn't argue this based on who has the most work because of this change but based on what is the right thing to do in this case. The fact of the matter is that multiple interfaces were removed without advance notice. Sure, these interfaces may have been included in error in the first place but since neither the wrong interfaces nor the right way to do it were documented how could someone have known that he used something that wasn't even supposed to be there? So you can't really blame someone for using those interfaces. Okay, maybe you CAN blame them for using _anything_ that isn't documented but in this case that would have meant to just completely do without this functionality which wasn't really a good option either. So, removing the interfaces in general is fine, but not without giving people ample time to react to this change and to learn how to do it right. Just breaking their extensions/macros from one minor version to the next isn't very nice. But yes, I'm biased because our extension is affected. You are right that it's not such a big change, and I may have exaggerated a bit. But you must understand that it's a bit of a shock when you realize that some interfaces suddenly just disappear from OOo 3.1 to 3.2 without any warning or explanation. It also has the effect that you begin to wonder what else could have gone missing that maybe you didn't notice in your test cases. Anyway, we now have an explanation what happened and we can do the necessary changes. I still think it would be better to postpone the removal of the interfaces to a later version, but if really noone else has a problem with it I'm not going to argue any further. Regards, Daniel - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Re: Missing interfaces in OOo 3.2: Why not a blocker?
Daniel B. wrote: Hi, On Fri, Nov 27, 2009 at 1:48 PM, Juergen Schmidt juergen.schm...@sun.com wrote: Daniel B. wrote: Since our (and potentially a lot of other) extension breaks with this change this is a major issue that prevents us from rolling out OOo 3.2. Reverting the change until OOo 4.0 would give us enough time to update our extension and roll out the updated version. So I support Michael's suggestion to re-implement the interfaces that are missing, at least temporary, and document the change so that people are aware of the issue and can adapt their macros/extensions. until now you are the only one with this problem. How many places using this code do you have in your extension? We gave you the necessary info to do it correct. It should be not really a big change i guess but anyway. I let it up to others to decide if it is a showstopper or not. But how can we prevent you from rolling out 3.2 when it is not already final and released? Either you change your broken or wrong extensions or we do the changes back. You have to do it anyway in the near future whereas we have double work. Sounds not really optimal ;-) We really shouldn't argue this based on who has the most work because of this change but based on what is the right thing to do in this case. The fact of the matter is that multiple interfaces were removed without advance notice. Sure, these interfaces may have been included in error in the first place but since neither the wrong interfaces nor the right way to do it were documented how could someone have known that he used something that wasn't even supposed to be there? So you can't really blame someone for using those interfaces. Okay, maybe you CAN blame them for using _anything_ that isn't documented but in this case that would have meant to just completely do without this functionality which wasn't really a good option either. i don't want to blame anybody but i wanted to raise more awareness. If an API is not documented (which should be fixed always) ask before you use it. That would prevent situations like this. Nobody should rely on the given implementation when it is not documented. If yes than they have to live with changes. The users of our API can help a lot to improve APIs and the documentation by communicating their problems, their ideas etc. Don't hesitate to submit an issue. It's always a valuable contribution and don't take it personal if an issue/feature request won't be fixed. So, removing the interfaces in general is fine, but not without giving people ample time to react to this change and to learn how to do it right. Just breaking their extensions/macros from one minor version to the next isn't very nice. i agree at least a note on interface-announce should have taken place. But the developer forget it and didn't thought about the relevance i guess But yes, I'm biased because our extension is affected. You are right that it's not such a big change, and I may have exaggerated a bit. But you must understand that it's a bit of a shock when you realize that some interfaces suddenly just disappear from OOo 3.1 to 3.2 without any warning or explanation. It also has the effect that you begin to wonder what else could have gone missing that maybe you didn't notice in your test cases. i agree again and yes we should try to improve the overall situation. We need also better tests. When we allow even incompatible changes in the future it should never happen without a clear communication and a well documented workaround. Anyway, we now have an explanation what happened and we can do the necessary changes. I still think it would be better to postpone the removal of the interfaces to a later version, but if really noone else has a problem with it I'm not going to argue any further. as i mentioned before it's up to you to put it on or suggest it for the showstopper list on the relea...@openoffice.org list Regards Juergen Regards, Daniel - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Re: Missing interfaces in OOo 3.2: Why not a blocker?
Hi, On Thu, Nov 26, 2009 at 6:46 PM, Juergen Schmidt juergen.schm...@sun.com wrote: Hi, if we can all agree i would suggest that we don't change the code back. The correct way will work with older versions of OOo as well and the code have to be changed in the near future anyway. What's your opinion? I can also live with Michaels suggestion to implement this interface until OOo 4.0 but it's probably easier and better to change the code now as later and potentially forget it. Since our (and potentially a lot of other) extension breaks with this change this is a major issue that prevents us from rolling out OOo 3.2. Reverting the change until OOo 4.0 would give us enough time to update our extension and roll out the updated version. So I support Michael's suggestion to re-implement the interfaces that are missing, at least temporary, and document the change so that people are aware of the issue and can adapt their macros/extensions. Regards, Daniel - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Re: Missing interfaces in OOo 3.2: Why not a blocker?
Daniel B. wrote: Hi, On Thu, Nov 26, 2009 at 6:46 PM, Juergen Schmidt juergen.schm...@sun.com wrote: Hi, if we can all agree i would suggest that we don't change the code back. The correct way will work with older versions of OOo as well and the code have to be changed in the near future anyway. What's your opinion? I can also live with Michaels suggestion to implement this interface until OOo 4.0 but it's probably easier and better to change the code now as later and potentially forget it. Since our (and potentially a lot of other) extension breaks with this change this is a major issue that prevents us from rolling out OOo 3.2. Reverting the change until OOo 4.0 would give us enough time to update our extension and roll out the updated version. So I support Michael's suggestion to re-implement the interfaces that are missing, at least temporary, and document the change so that people are aware of the issue and can adapt their macros/extensions. until now you are the only one with this problem. How many places using this code do you have in your extension? We gave you the necessary info to do it correct. It should be not really a big change i guess but anyway. I let it up to others to decide if it is a showstopper or not. But how can we prevent you from rolling out 3.2 when it is not already final and released? Either you change your broken or wrong extensions or we do the changes back. You have to do it anyway in the near future whereas we have double work. Sounds not really optimal ;-) But don't get me wrong try to put it on the showstopper list. Juergen - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Re: Missing interfaces in OOo 3.2: Why not a blocker?
Hi, if we can all agree i would suggest that we don't change the code back. The correct way will work with older versions of OOo as well and the code have to be changed in the near future anyway. What's your opinion? I can also live with Michaels suggestion to implement this interface until OOo 4.0 but it's probably easier and better to change the code now as later and potentially forget it. Juergen Michael Stahl wrote: On 26/11/2009 16:58, Ariel Constenla-Haile wrote: Hello Jürgen, * On Thursday 26 November 2009, 12:36, Juergen Schmidt wrote: mmh, it seems that we have a classical problem where you have implemented a macro based on a not documented implementation detail. But the implementation gets cleaned up for 3.2. yes, i removed the XTextField interface at the writer's SwXTextPortion implementation because: - it is documented nowhere - it is only implemented in writer, not in svx/editengine - there is the TextField property which gives access to the field of the portion - the SwXTextPortion does not implement any interface of any other portion type (XFootnote...) except this XTextField - the original implementer of SwXTextPortion claimed that this interface was probably included in error - none of our regression tests broke The problem is that the correct way is also not well documented :-( indeed; i have just looked at the relevant parts of the dev. guide, and it is not documented how to access the field of a TextPortion of type TextField. In this case it would be correct to check the TextPortionType and in case of a text field ask for the property TextField. It should be possible to ask for the property always and do the necessary checks... yes, this is the proper way, and should work on all OOo versions. I am not sure if we can or should mark this as a show stopper because it was an implementation detail. And the clean up of the code makes sense and we don't really want to change it back. considering the lack of documentation, now i actually believe that this is indeed an issue that should be fixed: if the proper way of doing something is not documented, we cannot really complain that someone found a non-proper way that happens to work. (which is why i'm not replying here with an RTFM rant like i originally intended :) ) but in any case, undoing this change would only be temporary: in the next major OOo release (4.0), this interface will definitely not be supported. that should give people plenty of time to adapt their macros and stuff. Maybe the responsible developer can shed some light on this and give us some more reasons for the change. We have definitely to fix the documentation to reflect the correct way. indeed. i can update the dev guide: http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Text/Iterating_over_Text btw, is it possible to automatically generate lists of properties in the dev guide from the IDL file? To avoid such problems in the future it is probably a good idea to ask here on this list first before you use an API that is not documented. Often enough the documentation is simply missing or incomplete. We should be careful with the available introspection tools. They provide great help and are necessary but the user of these tools should at least check the documentation too. This way we can improve the documentation as well. this issue has the same background as the one with the TextCursor properties http://www.openoffice.org/issues/show_bug.cgi?id=100798 For the TextPortion issue, on a DEV300_m65 the documentation seems corrected (though I didn't check every property) http://svn.services.openoffice.org/opengrok/xref/DEV300_m65/offapi/com/sun/star/text/TextPortion.idl#130 yes, i did that. (but unfortunately not at the same time as the XTextField removal...) IMHO common properties should be moved to the TextRange service (both a TextCursor and a TextPortion are TextRanges). not necessarily: i think there are TextRanges which are neither TextPortion nor TextCursor. regards, michael - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
