KDE/kdelibs/kate/buffer

[Andreas Pakulat]

On 11.04.10 11:50:15, Christoph Cullmann wrote:
> Niko Sams wrote:
> > On Sat, Apr 10, 2010 at 10:39, Christoph Cullmann <cullmann at absint.de> wrote:
> >   
> >> Perhaps (for the future), you should take a look how qtcreator does the
> >> parsing, after the last talks to Roberto, it seems that more intelligent
> >> it might be good idea to fork that parser or at least steal some (LGPL)
> >> ideas.
> >>     
> > Forget that, that's not an option.
> >
> > However what imho could be done is porting KDevelop to the new Buffer and Cursor
> > stuff. (But I have no idea what needs to be changed to do that)
> > I think we should:
> > - as a short term goal make kate and kdevelop as stable as possible
> > with the current technology
> > - as a mid term goal work out a plan what could be changed in which way
> > - as a long term goal have all all non-optimal code replaced by something better
> >
> > Unfortunately we are currently we are stuck at step 1, because david
> > and hamish (the only
> > ones who have in depth knowledge about what kdevelop does and needs) are short
> > of time.
> >
> > I think we can solve this issue together! No need to kill each other :D
> >   
> I like the idea of cooperation, but the current situation is not acceptable:
> 
> Nobody can do changes perfectly correct in kate part without breaking
> kdevelop and then getting constant complaints from either the kdevelop
> devs or users...
> To be honest, I don't like that.

/me neither and in fact we have the same problem inside KDevelop, maybe
not as bad, but some of the language stuff can only be fully understood
and maintained by David. And trying to touch things there in some areas,
will break havoc on the app.

I guess our (kdevelops) main problem is the timing of this, David and
Hamish worked 2 years on getting to the current state of smart-stuff
usage in kdevelop and fixes in kate. We're finally able to release
something. Now kate's implementation changed in way such that now
existing code-paths call GUI code that is not multi-threaded, without
anybody really knowing which code-paths those are. This basically means
throwing KDevelop 2 years back in time and we have to start all over
with the stabilization. Thats where the frustration comes from I think
(at least mine).

> I designed the new buffer in a time-frame of some weeks, it got unit
> tests from the start, it handles encodings lot better and it is faster...

Thats great.

> But what do I get: complaints and insults

Well, you'll have to expect complaints when completely changing the
implementation in ways that can potentially break existing code using
the implementation.

The insults are a different story of course, if I did that I apologize.
I know its not an excuse for insulting, but reading the discussions was
rather frustrating for me.

> I asked for input on kdevelop list, nothing, and now the whining is great...

I guess one problem is that this was done rather fast (IIRC 2 weeks or
so). Thats not a lot of time, not even looking at the fact that our own
release plans meant people focussed on getting their features done in
kdevelop.

In fact I'm kinda surprised that this crash hasn't been discovered and
worked-around earlier.

> I have not reverted milian's commit, but I won't tolerate any more
> invasive stuff.
> 
> If kdevelop gets crashs => lock your smart mutex in more places.

Thats easy enough to do, once we find a crash. To me the more important
question is wether we can somehow find out which code-paths changed so
we can efficiently fix kdevelop before running into the new crashes.
That way we could maybe release a 4.0.1 that works properly with KDE4.5,
before 4.5 is released. So do you think there's a way of getting this
information (other than by trial&error)?

> Could I get a list of the interface functions KDevelop uses of the smart
> range interface?
> I would then deprecate any other and kill the implementation, that the
> Smart* mess at least not spreads further.
> 
> Btw., if nobody steps up to provide a list, I can do my own, by grep -r
> for each interface function.

Well, I guess that would be fine. I mean anything thats not called from
code in kdevplatform/ or kdevelop/ is probably not used and I doubt that
David or Hamish would be able to give you a list without such a grep
call.

Andreas

-- 
Today's weirdness is tomorrow's reason why.
		-- Hunter S. Thompson