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

List:       kde-commits
Subject:    Re: KDE/kdelibs/kdeui/widgets
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2007-05-14 17:37:46
Message-ID: 200705141937.52992.hausmann () kde ! org
[Download RAW message or body]


On Monday 14 May 2007 19:11:28 Laurent Montel wrote:
> On lundi 14 mai 2007, Simon Hausmann wrote:
> > On Monday 14 May 2007 18:45:54 Laurent Montel wrote:
> > > SVN commit 664690 by mlaurent:
> > >
> > > Allow to use a specify highlighter
> >
> > That looks like disfunctional API to me :-/. It's nice if that method is
> > called, but there's no way for a re-implementation to actually /set/
> > d->highlighter.
>
> If possible to redefine it with virtual function createHighlighter() if we
> create sub class from ktextedit.

Right, and how would that implementation of createHighlighter() in a subclass 
set KTextEdit::d->highlighter? :)

> > I wonder if the whole lazy creation of the spell checker is worth it.
> > KTextEdit doesn't do anything with the highlighter, so why not just let
> > people install a custom syntax highlighter the normal way, using
> > QSyntaxHighlighter's constructor or setDocument for example?
>
> How ? I don't understand how we can change it into ktextedit.

My point is exactly that KTextEdit doesn't do anything with d->highlighter 
apart from instantiating it. Instantiating the hightlighter automatically 
registers it with QTextDocument/QTextEdit through QSyntaxHighlighter's 
constructor. So I don't really understand why we need an API in KTextEdit for 
installing a syntax highlighter when it just works already.

If this is just about creating a highlighter "on demand" then I'm not sure 
it's worth this extra virtual method in the public API. If the creation of 
the syntax highlighter is /such/ an expensive operation for an application 
then maybe the highlighter itself should be fixed or that one application 
that has this special highlighter that is so expensive to create should 
perhaps do the lazy creation itself.

Simon

[Attachment #3 (application/pgp-signature)]

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