[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: Impending removal of Smart* code from katepart
From:       Christoph Cullmann <cullmann () absint ! com>
Date:       2010-04-12 7:17:40
Message-ID: 201004120917.40562.cullmann () absint ! com
[Download RAW message or body]

On Monday 12 April 2010 08:42:31 Hamish Rodda wrote:
> I completely understand your point of view.  I regret that I have not been
> able to remain active in kate.
> 
> May I propose a solution that should work for everyone.
> 
> The smart interface is, in my opinion, a fairly self-contained piece of
> code which could be separated from kate part with only a minimal interface
> into and out of kate.
> 
> The hooks out of kate that are required are simple - 100% accurate signals
> of exactly where the buffer has changed.  They already exist but are not
> exposed, from what I can remember.  However, for this plan to work, they
> must remain absolutely flawless.  This was the source of many of the early
> Smart* bugs.
> 
> The major hook back into kate is at rendering time, to get the extra
> attributes to draw.  I presume you already plan to provide an alternative
> to this, as you allude to above with talk of a replacement.  We can adapt
> the Smart* code pretty easily to whatever interface you wish for this.
> 
> We would then move the Smart* code either into a separate library/plugin
> should others still want to use it, or into kdevelop itself.
> 
> As you say, kate can then go back to happy thread unsafe existence, the
> Smart* code would not be loaded when running kateapp.
> 
> Then you can send any bug reports about Smart* to me, kdevelop, or
> /dev/null, as you prefer.
> 
> The only big loss to the functionality available with the smart interface
> will be to dynamic attributes, because they rely on receiving information
> about mouse position in the view, and cursor position.  This is an area of
> the smart interface that never really reached its true potential, sadly.
> However, the cursor position is already provided; mouse position
> translated to text cursor could also be exposed easily, allowing me to
> resurrect even this functionality if we still want it.
> 
> If we're going to go ahead with this, I propose we do it now, for KDE 4.5.
> We're going to end up with two different sets of bugs anyway as kdevelop is
> going to release against the current code (unless there is a change of
> heart with this development within the kdevelop devs), so we should
> mimimise the time that the old code is around for.
You can do so and move the code to kdevelop, as internal interface, the new 
TextBuffer provides signals for changes which work.
Still the interface for the ranges with attributes is not done for the 
replacement, see below for the current plan for fast lookup.

> 
> Do you have any design in mind for the "ability to add attributes to the
> new Kate::TextRange's and efficient lookup." ?
The text blocks will have set of ranges affecting it, if a range spans multiple 
blocks, which is unlikely, beside for selection, it will be added to all 
blocks spanned.
This way you ever only need to lookup the ranges for the block, given the 
block is small per default (256 lines), this should be fast.

Greetings
Christoph


-- 
-------------------------------------- Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann@AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel

[prev in list] [next in list] [prev in thread] [next in thread]