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

List:       kwrite-devel
Subject:    Re: Review Request/New Framework: KF5::SyntaxHighlighting
From:       Christoph Cullmann <cullmann () absint ! com>
Date:       2016-09-17 15:56:15
Message-ID: 241521304.3258.1474127775815.JavaMail.zimbra () absint ! com
[Download RAW message or body]

Hi,

> In KTextEditor, we currently access the attribute by an int index.
> This index is then used to later map to the correct color depending on
> the scheme. While this may be efficient, I like the "Format" class
> more, since it has nicer API and still supports sharing.
> 
> In KateTextLine.h, you can see that the class has a member
> 
>    QVector<Attribute> m_attributesList;
> 
> where the Attribute class looks like this (API docs omitted):
> 
>    class Attribute {
>    public:
>        int offset;
>        int length;
>        short attributeValue; // (*)
>        short foldingValue;
>    };
> 
> At (*), I can imagine we when using the syntax-highlighting framework,
> we'd just save a Format (or Format pointer) instead of an int
> attributeValue. This will slightly increase the required memory, but
> let's assume for now this is ok.
> 
> So from this perspective, the Format class gives KTextEditor what it needs.
> 
> Also, if not explicitly set, the Format class just refers to default
> styles. This can be overwritten through explicitly setting itemData
> attributes (bold, italic, color, ...) - also ok.
> 
> What's good is that the Format class doesn't by default contain the
> colors itself - hence a KTextEditor::Document can have two views, one
> view using a light color scheme, and another using a dark one. So from
> a KTE's pov, this is exactly what we need (iirc, Christoph discussed
> that with you already quickly in Berlin).
> 
> In short: The Format depends on the Theme when getting concrete data,
> but the Theme itself doesn't depend at all on Format. This is ok imo.
> 
> What I also like is that since the Formats are shared, changing say
> the Formats of alerts.xml will also influence the included alerts in
> cpp.xml - this is not the case in KTextEditor, see the "Highlighting
> Text Styles" tab.
> 
> So all this sounds good to me, or do I miss something?
I agree, but I think we want to keep the small ints that reference to the format,
if that is shared, its fine anyways to keep a copy somewhere in an vector ;=)


Greetings
Christoph

-- 
----------------------------- Dr.-Ing. 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
[prev in list] [next in list] [prev in thread] [next in thread]