findIndex is new in Qt 5.9

[1] https://doc.qt.io/qt-5/qtqml-javascript-functionlist.html

Note that visible propagates recursively so when the component containing a default-visible message widget isn't shown this will still animate. But then I don't know if that's a thing and how to fix that..

Should this be a var property so you could also pass a QIcon or "QtQuick Controls Icon"?

KMessageWidget names it closeButtonVisible

contentItem.hasOwnProperty("animating")

With Qt 5.8 this could become

namespace InlineMessageType
{
    Q_NAMESPACE
    enum Type {
...

with qmlRegisterUncreatableMetaObject
(purely informational comment)

Q_ENUM

(also informational, the code around it does the same, could be cleaned up eventually)

Wrong class name

There's no start-here in Breeze, just start-here-kde which won't fall back to start-here (which is distro-branded for you apparently)

Thanks, will fix.

I need something generic that's not tied to Breeze, hmm ... suggestions?

This was copy-pasted from the Cards code (that's why Marco's copyright is in the header). Marco?

I'm not sure it's a problem it will animate when you unhide with a parent.

I wouldn't have any objections, but Kirigami.Icon.source is 'string' too, so it wouldn't work currently.

Yes, but as mentioned in the review description I named it showCloseButton for consistency with another Kirigami component.

Will do.

Could be a nice follow-up, but it's good practice to emulate surrounding style in a patch.

See above.

Replaced with system-run.

Switched to homebrew implementation from your D11707.

I don't think either of these two lines will work as you intend as you've not constrained the label height anywhere

add some usage explanation here, like that should be added in the main layout of the ui you want to put it in, that is not visible by default, needing an explicit visible=true

a two rows synopsis of the ig would also be good here tough we have to wait for that i guess

this would make opacity of contentitem 1.0 even when animationg to 0?

also a color: root.icon.color (no checks needed)

with qqc2 api, here would return either root.icon.source or if not set root.icon.name

i kindof feel we should make a private component out of that, for overflowable toolbars.. (or maybe even not private) but this is for the future, this is perfect for now

if you need to know if an item is visible by itself, not caring of parents visibility, use opacity instead, at least that's what qt docs say.

what is the use case, tooltips?

even if at the beginning not 100% supported, i would prefer it making api-compatible with qqc2 (even if i don't like that api that much)
there is a class in controls/private called ActionIconGroup which exports the ptoperties that qqc2 uses for icons, so icon.name,icon.source, icon.color
not all of those need to be supported (i prefer to ignore icon.size usially) but at least name,source and color should

what is the use case for exposing this property in the public api?

please call this in a more generic way, like MessageSeverity, so can be used for other kinds of messages if needed, like passivenotification and inline dialogs

Will do.

e.g. setting a status bar/status tooltip text with the URL, yup

Can you give me a code example of how to use this in the template code?

Consistency with OverlayDrawer.animating - it generally seems like a good idea to be able to know when something is fully visible/ready.

"Severity" is actually less generic than "Type" and semantically wrong. While Warning->Error perhaps are a range, "Positive" isn't "more severe" than "Information". This is semantically an unordered enumeration (less specific) while "Severity" implies a scale (more specific).

as Action.qml is doing:
this is how Action uses it:

property ActionIconGroup icon: ActionIconGroup {

    id: iconGroup
}

ActionIconGroup can be renamed/moved btw, but is not important

a retrocompatibility alias iconSource: iconGroup.source could be possible, tough for new classes not needed, if the source of icongroup becomes a var instead of a string, passing qicons should stay possible.

the usage would then be:

InlineMessage {

icon.name: "konsole"

}

again, i'm not sold on this, but if we can make it coherent qith qqc2 it becomes a bit easier for new developers

No, because of enabled: !root.visible. implicitHeight is bound to an expression that's recomputed when visible has changed, and returns 0 when visible is false. That means by the time the Behavior would kick off in response to the implicitHeight property changing, it's already disabled. In other words, under the only condition when implicitHeights goes to 0, this Behavior is known to be disabled and the ScriptAction will not run.

Hang on, I focused on disagreeing with Severity, but I understand now your goal was to drop Inline to make it more generically useful, sorry. How about MessageType?