Format class: add functions to know if XML files set style attributes
ClosedPublic

Authored by nibags on Aug 27 2019, 9:43 PM.

Details

Summary

The functions isBold(), isItalic(), etc. return the resulting format between the combination of the Theme and the XML highlighting file. This one works very well. The problem is that if the Theme is empty, it isn't possible to correctly apply these attributes, especially the turn off of these.

These new functions let you know if the attributes bold, italic, underline, strikeout, color, backgroundColor, selColor & selBackgroundColor are specifically set in the XML files.

For example, if Format::definitionHasBold() is true, the Format::isBold(...) function returns the value of the bold attribute set in the XML file. If Format::definitionHasBold() is false, the bold attribute isn't in the XML file and Format::isBold(...) returns the value defined by the Theme.

Diff Detail

Repository
R216 Syntax Highlighting
Branch
format-new-functions
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 15720
Build 15738: arc lint + arc unit
nibags created this revision.Aug 27 2019, 9:43 PM
Restricted Application added projects: Kate, Frameworks. · View Herald TranscriptAug 27 2019, 9:43 PM
Restricted Application added subscribers: kde-frameworks-devel, kwrite-devel. · View Herald Transcript
nibags requested review of this revision.Aug 27 2019, 9:43 PM

I am thinking about whether overwritesBold() , ... is better than definitionHasBold(). Because the Format matches an itemData in xml. Or even boldHardcoded().

Any thoughts?

PS: Another solution is to port all xml files to not use hard coded colors. That's a lot of work, though.

src/lib/format.h
149

Better: If @p true is returned, ...

155

Could you add an empty line after a function such that the next doxygen block starts after the newline?

No idea if definitionhasBold or the other variants are better.
For the "PS: Another solution is to port all xml files to not use hard coded colors. That's a lot of work, though.": I think to hardcode e.g. bold/italic/... is actually not that bad in some cases. That can be themed nicely.

Shall we go with the definitionHasX style or change it?

dhaumann requested changes to this revision.Aug 29 2019, 10:01 PM

What I currently dislike is that definitionHasXyz implies the Definition class has something, which is not correct, since it's about whether the Format has an override. I would very much prefer: bool overridesBold, overridesItalic, overridesTextColor.

Can we agree on this?

This revision now requires changes to proceed.Aug 29 2019, 10:01 PM

As we have already members like

hasX

would it make sense to have

hasItalicOverride()

to be more consistent?

Yes, that is also fine with me, please do the changes and proceed.

I also like hasXXOverride().

In the case of bold, italic, underline and strikeout, functions such as hasXXOverride() are needed, since they are boolean values that can be turned off. But for the case color, selectedColor, backgroundColor and selectedBackgroundColor, do you think it's also necessary?

Because I think it's better not to add those functions; with the already existing functions hasTextColor(Theme) and hasBackgroundColor(Theme) is enough.

I believe you still need the hasTextColorOverride etc. hasTextColor is different and matches from the meaning isBold etc.

Background: The styleOverrides are yet another concept: if the user changes a color of a highlighting in the Highlighting Text Styles tab, then the style override is active. See http://blog.case.edu/bmb12/2007/03/06/kate_styles.png
That is: the style overrides are part of a Theme and typically only exist for Themes where the user changed colors.

But: Since the port to KSyntaxHighlighting::Theme is still not done, this currently is not used (iirc ???) in KTextEditor...

To make it short: if you want to know whether the colors are hardcoded, you also need the additional hasXxOverride() functions.

nibags updated this revision to Diff 65017.Aug 30 2019, 9:11 PM
  • Update function names
cullmann accepted this revision.Aug 30 2019, 9:49 PM

Think this is fine now, thanks.

Dominik, ok with this now, too? Or did I miss some name issues in the API? (tried to read all lines for spelling mistakes :=)

dhaumann accepted this revision.Sep 1 2019, 8:10 PM

Thanks!!

This revision is now accepted and ready to land.Sep 1 2019, 8:10 PM
This revision was automatically updated to reflect the committed changes.