Bug 403041 - Headings used as header items have insufficient padding by default
Summary: Headings used as header items have insufficient padding by default
Status: RESOLVED NOT A BUG
Alias: None
Product: frameworks-kirigami
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: Not decided
Assignee: Marco Martin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-09 14:38 UTC by Nate Graham
Modified: 2019-02-11 09:50 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Not enough padding (571.36 KB, image/png)
2019-01-09 14:38 UTC, Nate Graham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2019-01-09 14:38:53 UTC
Created attachment 117357 [details]
Not enough padding

Kamoso has this code in main.qml:

        contentItem: Config {
            id: configView

            QQC2.ScrollBar.vertical: QQC2.ScrollBar {}

            header: Kirigami.Heading {
                level: 1
                color: Kirigami.Theme.textColor
                elide: Text.ElideRight
                text: i18n("Effects Gallery")
            }
        }


It results in the header text not having enough padding by default. See attachment.

It would be nice to solve this issue generically in Kirigami so every user of Headings inside header: properties wouldn't have to fix it themselves.
Comment 1 Marco Martin 2019-02-11 09:50:35 UTC
not valid: Heading is a text element, and exactly why you should never use a Label directly in an header, you should never use an heading as well.
in those cases, a kind of container should always be used. either an Abstract/BasicListItem in a ListView or any other kind of container regardless when in a kind of scrollview which isn't a ListView, even just
Control {
    Kirigami.Heading {
       text:"foo"
    }
}

would be more correct already, since it would give it unit based paddings coherent with everything else.

With QML is super easy to shoot yourself in the foot, and is designed that way, because the priority there is flexibility, with QWidget is harder to do things that look super wrong, exactly because it's more rigid and less capable, but there is nothing i can do to change the nature of QML (in fact all the places where i tried, like the automatic toolbar and completely premade complex components gave serious problems as people always found them too rigid, so is a direction i don't want to go anymore)

this can't (technically) and shouldn't (in principle) be fixed, but i'll add a warning about it in the apidocs.

(unrelated, that piece of qml also has other errors, like having a flickable with a scrollbar directly instead of a ScrollView, which will give it different behavior than anything else)