The AbstractAnnotationItemDelegate is modelled after QAbstractItemDelegate
and should allow consumers of the annotation interfaces to customize the
rendering and the tooltip per annotation as wanted.
Reaching review candidate state, please start reviewing the code.
Target is Frameworks 5.52, so the one after the upcoming Frameworks version.
The current planned consumer of the new API is KDevelop 5.4, which may be
branched end of year or next year, so nothing urgent to push and giving this
another month of API reconsiderations is fine.
For some more verbose presentation of this patch see https://frinring.wordpress.com/2018/09/09/from-code-to-related-bug-report-or-review-in-just-a-hover-click/
I commented on some things - I did not try this, though.
What I would like to see is a comment // KF6: Merge KTextEditor::AnnotationViewInterfaceV2 into KTextEditor::AnnotationViewInterface (kossebau).
For me, this comment is really important, since this tells you that you will in 2-3 years (when Qt6 arrives) work on this and merge it down: Since there is only you (KDevelop) who is using this interface, so you have to maintain it ;)
Would you go over my comments and provide an updated version? Not all comments are real issues.
@since 5.52 :-)
I am asking myself: Is wrappedLineCount >= 1 always true? If so, can you add this as documentation? wrappedLineCount == 1 means no wrapping line?
Is this to be set by the user, and if so, is there any special meaning to a default-constructed QSize()?
Is this a bitmask? The << 0, <<1, <<2 notation implies that it is.
You export the class, but then the constructors are inlined. Could you please move the implementation to the cpp file? That leaves us more room to fixes by shipping an updated version of the library.
Typ: A delegate ...
Same here: Could you move the implementation to ktexteditor.cpp?
Same here: Please move the destructor to ktexteditor.cpp. You can keep = default there, but not here.
inlc. -> including. No need for abbreviations
Change trailing ':' to '.'
I think you don't need to type "\ref". doxygen will create the link for you anyways. Same below.
... or a nullptr, if no delegate was set. maybe? I am asking, since it could also return some default implementation.
Given you check for a valid pointers here, would it also be an option to pass references? Or would that violate Qt style API?
validness --> validity :-)
Is this copyright really correct?
This is v2 only, I think this should be avoided at all costs... We try to get to v2+... I think you can change this, since this is your work. Even if it's based on others, the work of others is in the other files.
You could do that via QPointer, if the delegate is QObject base. It's a poor man's solution which has many issues on its own, though. Maybe it's better to simply assume the user uses the interface correctly...
Do you really need the timer here? I thought update() goes through the event queue anyways?
2nd time this comment pops up. Do you have an answer? In Qt, this would be an extra setAutoFillBackgroundEnabled(bool) , or something similar... In any case - this needs to be decided before the interface goes live :-)
Maybe 4+4 margin or so?
Again, single shot timer needed?
I would prefer in-class member initialization here for the bools.
Yes. I see now that this can be confusing and semantically strange, if wrappedLineCount == 1 means actually no wrapping here. Unsure what ould be a better way to express this. One ould use the same name and define 0 to mean that no wrapping is done. And 1 would just be a bogus value? Proposals very welcome.
This parameter was inspired by QStyleOptionViewItem::decorationSize. I imagined it could be e.g. used if one ever starts to show avatar icons for commit authors in the annotations, or for other icon-based indicators which could be shown (bug fix, reviewed, etc).
There is no specification on the meaning of an invalid QSize with QStyleOptionViewItem::decorationSize. I would tend to leave this here unspecified as well for now, until this gets in real use or the QStyleOptionViewItem one gets specified?
Yes, as a line could be both begin and end of an annotation grouping (if both neighbour lines belong to different groups). Of course InGroup is mutually exclusive to GroupBegin and GroupEnd. IIRC (been some time since Nob 2017 :) ) I had used normal enum values, with another value GroupBeginAndEnd. But the resulting code using the enum was more complicated.
Okay. I had looked at the other interface classes, those I looked at, even if QObject-based, are header-only, that's why it was done like this. Will change, as I remember from other projets e,g. Windows has issues with this.
It is following QAbstractItemDelegate ::paint(...) signature here. So I would lean to stay with the current code. But as you prefer.
Indeed for the headerthere is no code copied over, well, besides the API being inspired by QAbstractItemDelegate. Reduced to mine.
Changed this for the header and also for the source. While the initial code was copied over from kateviewhelpers.cpp (thus the complete license header), comparing it now to the original, I would think it has been that much rewritten to match the delegate API, that it safely can be called a copyrightable product of its own, with no substantial parts of the original left (where not required by the general Qt API).
I copied existing code here, for consistency. No really sure when to call it directly and when to go via event loop.
Yes, this is a TODO question to you Kate developers :)
p.fillRect(0, y, w - 5, h, m_view->renderer()->config()->iconBarColor());
before starting to draw the annotation stuff and icons, which also cares for the displayed lines with no content.
Forgot that in the previous update, now added. Curious though why you do not expect Kate to offer users some similar annotation display experience one day if working on versioned text documents ;)