tag:blogger.com,1999:blog-17552332.post708385261916750422..comments2010-10-31T19:39:07.614+01:00Comments on dhaumann: Kate Internals: Smart Cursors and Smart Rangesdhaumannhttp://www.blogger.com/profile/06242913572752671774noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-17552332.post-55920850857407998942010-05-01T18:04:03.185+02:002010-05-01T18:04:03.185+02:00Ah forgot: KDevelop and Kile developers are aware ...Ah forgot: KDevelop and Kile developers are aware of it.<br /><br />Kile only uses it in the CompletionInterface, which btw just indicates that the design of the CompletionInterface is also flawed ;)dhaumannhttps://www.blogger.com/profile/06242913572752671774noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-40108004308286828402010-05-01T18:00:09.050+02:002010-05-01T18:00:09.050+02:00Kobby: no Smart* at all
RKWard: Uses SmartRanges, ...Kobby: no Smart* at all<br />RKWard: Uses SmartRanges, without checking whether the SmartInterface is valid. Have already <a href="http://sourceforge.net/mailarchive/forum.php?thread_name=201005011753.41314.dhdev%40gmx.de&forum_name=rkward-devel" rel="nofollow">contacted the authors</a>.<br /><br />Btw, while it's indeed not possible to catch all KTE users, I'm pretty sure that the KTE interfaces are not used that much, especially not Smart*. Kind of unfortunate, but in this case even an advantage ;)<br /><br />Btw, thanks for pointing me to RKWard.dhaumannhttps://www.blogger.com/profile/06242913572752671774noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-5136277918704671552010-05-01T16:54:56.203+02:002010-05-01T16:54:56.203+02:00lxr.kde.org is not going to catch stuff outside KD...lxr.kde.org is not going to catch stuff outside KDE SVN. We all have no idea how much code uses these APIs outside of KDE SVN. KatePart is LGPL, not GPL, so the source code of the affected apps might not even be available. And where it is, you might not have found it. E.g. you haven't found the KTIGCC 2 development tree (which is the app I was talking about), even though it's sitting on SourceForge. But that app is a big API abuser (I'd recommend not looking at the code, you might undergo a heart attack if you do ;-) ) and the KDE 4 version (KTIGCC 2) is not released yet anyway, so I wouldn't worry too much about that one if it's the only one. I'm more worried about e.g. KDevelop/kdevplatform and Kile. There's also (among the stuff packaged in Fedora, which is easy to query for) Rkward and Kobby which use libktexteditor.so.4, but I haven't checked whether they're using Smart* interfaces.Kevin Koflerhttps://www.blogger.com/profile/00136078113749660013noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-53464755537976370692010-04-30T08:19:08.370+02:002010-04-30T08:19:08.370+02:00@kevin:
There was never ever documented, that Kate...@kevin:<br />There was never ever documented, that KatePart will implement the smart interface in the first place. If developers of 3rd party apps don't check for that, little can be done.<br /><br />About fixing: I tried hard, but look at the API of it in ktexteditor, the original author exposed the complete internal structure, there is no way to fix anything. If you application doesn't use any watchers/notifiers but smart* stuff, than already that will lead to endless crashs in normal use, even if single threaded. That is for me unacceptable and atm the state of art for KDevelop: it somehow works, most times, but sometimes just eats your document and crashs, because the smart* stuff can't be used right.<br /><br />The whole interfaces stuff was designed to exactly allow this: BC extension and changing of the stuff the editor component exports to the outside world. If that is not allowed, the whole sense of the interfaces is really not there anymore.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17552332.post-1891645084246336262010-04-30T02:01:00.865+02:002010-04-30T02:01:00.865+02:00http://lxr.kde.org. Search for SmartRange, SmartCu...http://lxr.kde.org. Search for SmartRange, SmartCursor and SmartInterface.<br /><br />- kdevplatform (full of Smart*)<br />- kile (SmartRange in CodeCompletion interface. Very easy to switch.)<br />- kte_linter (playground, easy to switch)dhaumannhttps://www.blogger.com/profile/06242913572752671774noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-10725929593170039462010-04-30T00:55:23.490+02:002010-04-30T00:55:23.490+02:00The question is who uses the KTextEditor interface...The question is who uses the KTextEditor interface? My guess would be just a hand full of FOSS KDE apps. Kate, KWrite, KDevelop. Does Eric4 use it or is it pure Qt? So it might even be possible to write an email to each and every developer who uses the interface.<br /><br />I ask, who here uses this interface including the Smart* stuff?Mathias Panzenböck (panzi)https://www.blogger.com/profile/08100890214025847730noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-85004869458335489462010-04-30T00:14:43.621+02:002010-04-30T00:14:43.621+02:00What you say is true, and we are aware of that. If...What you say is true, and we are aware of that. If an application is using e.g. a SmartCursor and does not check whether the interface is supported, it indeed will crash sooner or later.<br /><br />On the other hand, the API is so much broken (see kwrite-devel archives for more information), it's simply near to impossible to fix the implementation correctly. The correct fix in this case are the Moving* classes.<br /><br />KatePart really has a lot of crashes right now (maybe some users do not experience them, but they exist), and almost all backtraces lead to Smart* handling. We have again and again tried to fix it ourselves, but we simply don't understand all the code (no, we are not too dumb :) )<br />We also wrote mails to the developer who wrote all that Smart* stuff. I almost never got a reply...<br /><br />Having said that, the current state is simply not bearable either.<br /><br />The decision to drop Smart* is not something we did just by random choice. It came to that because of the reasons mentioned above, after years of discussions...<br /><br />I'm not happy either with the solution. Technically it's a clean solution. But you are indeed right: As KTextEditor interface user you might have to say: This version works up to KDE 4.5. Then KDE 4.6 with the new version is required.<br /><br />This is suboptimal, indeed it sucks. But this is how it will be.<br /><br />> I'm sure this problem could be solved <br />> in a compatible way [...]<br /><br />We tried. For years. The answer is most probably "no"... I did not write "this might kill Kate" just for fun.dhaumannhttps://www.blogger.com/profile/06242913572752671774noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-3356386760525619142010-04-29T19:24:28.729+02:002010-04-29T19:24:28.729+02:00No matter what you component maintainers decide on...No matter what you component maintainers decide on your mailing list, you have to follow global KDE compatibility policies.<br /><br />This <b>will</b> break some applications. A smart cursor is something you use in your code because you <b>need</b> it, it makes no sense to "maybe, if it happens to be supported" use a smart cursor. So this recommendation of checking and only using it if available is just wishful thinking, apps will either be degraded or just error out entirely even if they did follow it, and I'm pretty sure many will just crash entirely, because apps which explicitly request a KatePart expect to be able to use all its interfaces, nobody expects an interface to get removed like this. (I have one such application which is going to just crash, though there is no release of the KDE 4 version yet, so this particular application is not going to have many affected users. And BTW, that app is also not setting any Notifier or Watcher on the smart cursor.)<br /><br />I'm really worried about the impact of this change on third-party applications using on the KDE platform. You can't really expect them to follow the kind of best practices you assume (third-party apps do all sorts of crazy things), and even if they do, they'll still have degraded functionality.<br /><br />I'm sure this problem could be solved in a compatible way, e.g. by starting the "update smart cursors" thread the first time a smart cursor is requested, or possibly by changing the implementation within the constraints of the interface.Kevin Koflerhttps://www.blogger.com/profile/00136078113749660013noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-39447404818490190862010-04-29T18:24:11.703+02:002010-04-29T18:24:11.703+02:00@Kevin: You are completely wrong here. We are enti...@Kevin: You are completely wrong here. We are entirely binary compatible. Kate Part will just not implement some classes anymore. Which is totally fine. In the API docs you can read everywhere that you first have to check with qobject_cast, whether an interface is supported or not.<br /><br />So this is not breakage at all, probably this got not clear. And what probably also got not clear is the fact that this Smart* stuff is killing Kate. <br /><br />We will remove it. We have discussed about it on our mailing lists for more than 2 years now about it.<br /><br />It's still broken. Unmaintained and what not.<br /><br />It will be removed, there will not be any further discussions. Sorry ;)dhaumannhttps://www.blogger.com/profile/06242913572752671774noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-71332301029138532382010-04-29T18:09:02.513+02:002010-04-29T18:09:02.513+02:00This kind of compatibility breakage is just plain ...This kind of compatibility breakage is just plain not allowed in a library which is part of kdelibs (which the KatePart is). I see why you want to do these changes, but they're completely inappropriate for any 4.x release, they need to wait for KDE SC 5 (whenever that will be, may be years from now).Kevin Koflerhttps://www.blogger.com/profile/00136078113749660013noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-57456476668196120552010-04-29T08:20:00.636+02:002010-04-29T08:20:00.636+02:00@Misbachul: probably not, at least it's unlike...@Misbachul: probably not, at least it's unlikely to replace Smart* so fast, because of the multi-threading afaik.<br /><br />@Niko: I agree here. Removing Smart* is one of the worst things for KDevelop. On the other hand if KDevelop migrates to Moving*, it has a very solid base for the next years. So I really hope this is doable!dhaumannhttps://www.blogger.com/profile/06242913572752671774noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-33502752800570556892010-04-29T08:12:09.040+02:002010-04-29T08:12:09.040+02:00While it really sucks to remove the Smart interfac...While it really sucks to remove the Smart interfaces and break compatibility, I fully understand the reasons for that. And once kdevelop is ported to Moving* all will profit from that. (maintained code, stability, performance)Anonymoushttps://www.blogger.com/profile/11777805168853811867noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-86055973088818403262010-04-29T04:50:54.519+02:002010-04-29T04:50:54.519+02:00i wonder if kdevelop 4.0 will already use it..i wonder if kdevelop 4.0 will already use it..Unknownhttps://www.blogger.com/profile/17833419928789443806noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-60681088511792153052010-04-29T01:26:30.757+02:002010-04-29T01:26:30.757+02:00Interesting read!
I'm looking forward to the s...Interesting read!<br />I'm looking forward to the solution to the scalability problem. It is a universal problem really: When some change happens that invalidates a huge amount of data, do you update it right away, when it's used, or something in between?<br />The third solution pretty much always involves analysis of typical use cases.<br />I use Kate for all my coding, by the way :)Unknownhttps://www.blogger.com/profile/10128346062237414083noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-42547229919777790922010-04-28T22:23:54.655+02:002010-04-28T22:23:54.655+02:00@Fri13: I refuse to say KDE SC simply because it&#...@Fri13: I refuse to say KDE SC simply because it's inconvenient. It sounds stupid. KDE is KDE. And that's that. Sorry ;) (PS: I *knew* that such a comment would come. ;) )<br /><br />@Diederik: Well, as a developer one certainly has a different perspective anyway. All in all, Kate indeed is quite good imo. And for KDE 4.5 it will simply be sooo much better... :) Certainly much more stable!dhaumannhttps://www.blogger.com/profile/06242913572752671774noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-2785324081579709322010-04-28T19:31:57.979+02:002010-04-28T19:31:57.979+02:00Wow quite an interesting read, and learning how th...Wow quite an interesting read, and learning how things work internally.<br /><br />All this enumerating makes it sound like Kate is a pretty bad editor, which I think is a bit misleading. So great to see it's getter even better! :)Diederik van der Boorhttps://www.blogger.com/profile/11435808496879023545noreply@blogger.comtag:blogger.com,1999:blog-17552332.post-13974426556541772942010-04-28T18:39:17.814+02:002010-04-28T18:39:17.814+02:00[Offtopic] Please use KDE SC from software and KDE...[Offtopic] Please use KDE SC from software and KDE from the community. It just makes it much easier for new users and existing users to follow the technology (but not those who refuse blindly from it) in future. Thanks [/Offtopic]Fri13https://www.blogger.com/profile/00914958546817888010noreply@blogger.com