[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:       "Joseph Wenninger" <jowenn () kde ! org>
Date:       2010-04-12 12:38:39
Message-ID: 6808fa729aa42857fd80ed31a7a9eb99.squirrel () mail0809 ! jowenn ! net
[Download RAW message or body]

Hi!

I'm against completely removing the smart stuff. The interface is quite
good and convenient, I would only forbid calling the functions from
another thread than the gui thread and incrementally add a new threadsafe
interface and make the implementation more legible. Or fix the code using
the stuff from another thread than the gui one. And most importantly
removing this revision system and building a better, systems.

I like the interface, but the mutexes as various hacky places have to go
away.

Regards
Joseph

> Christoph Cullmann, 12.04.2010:
>> 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.
>
> Can you please point me to the new API for custom highlighting, or is that
> not
> yet written?
>
> Thanks
> --
> Milian Wolff
> mail@milianw.de
> http://milianw.de
> _______________________________________________
> KWrite-Devel mailing list
> KWrite-Devel@kde.org
> https://mail.kde.org/mailman/listinfo/kwrite-devel
>


_______________________________________________
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]