herzenschein

Hey there, I'm Herzenschein. I had no formal education in IT, I'm a translator originally. I work with software documentation involving open source Qt apps now, so I get to read quite a bit of C++ code. I get pretty hyped at modern C++ features, and I dabble a bit in Perl and Python.

without the need of the moc

I got a bit of a mind freeze reading that sentence since my first thought was "why would someone deliberately give up on Qt's reflection system" but only then realized they're still using QMetaObject (the thing that actually enables reflection and signals and slots), just building it with something else.

Afaik the reason why they're not using GitLab issues it's missing some features they need, which Bugzilla has.

Yeah.

https://community.kde.org/Get_Involved/Issue_Reporting/Why_not_GitLab_Issues

This was shared recently by a friend I follow: https://mastodon.social/@silvereagle/111484800732591545

Direct link: https://www.sofurry.com/forum/view/thread?id=58457&page=100000

That link has a few mentions of podcasts:

• 24/7 Chill Furry Lo-fi Radio https://www.youtube.com/@AquariusCrystalwave/streams
• Furry Refuge (Old streams) https://www.youtube.com/@furryrefuge3969/streams
• Catnip Radio https://www.mixcloud.com/CatnipRadio/stream/
• Furry Rave Crew https://www.mixcloud.com/FURRYRAVECREW/

Also, you should only use Layout attached properties when the object you're using it on is a child of a Layout, for example:

ApplicationWindow {
    ColumnLayout {
        anchors.fill: parent // Not a child of a layout, so you use anchors
        Controls.Button {
            Layout.fillWidth: true // It's a child of a layout, so you use Layout.fillWidth
        }
    }
}

So what you want to do is put a Kirigami.SearchField inside the global toolbar created by the Kirigami.Page. It's not a header.

In the first case you're putting it inside the page, and because it's a direct child of a Kirigami.Page, it is automatically laid out for you, which is fine, but not what you want.

In the second case you're putting it in the header of the ApplicationWindow, but you actually want to put in the global toolbar of the page, so it's not what you want.

In the third case you're just putting a SearchField before the initialPage, so it's loaded on the same level as the page, it's not what you want.

You can put it in the header property of the Kirigami.Page, but the header area of the page doesn't include the global toolbar, so they just happen to be close together by chance.

The way I'd have expected to do that would be to override the globalToolBarItem of the Kirigami.Page, but it's read only, so I don't really know how to help you with that. You should ask in the Kirigami Matrix room or in the Discuss forum.

I can't tell you why this is happening, but what is clearly happening is that your apps are being run under a nested kwin_wayland instance. It's as though you were running kwin_wayland krunner.

If anyone’s wondering, my main issue with Wayland was that it wasn’t setting the DISPLAY and WAYLAND_DISPLAY environment variables for some reason, and this would cause all kinds of software like Steam and Firefox to not even launch. I tried setting them manually but that didn’t go do well either.

My guess is that whatever fix you attempted here caused this, so you'd need to be more specific about what you tried.

I was thinking, with the recent news of a contributor to GitLab adding support for forge federation, some time we could see that being enabled in the KDE instance as well, I hope.

It would be cool indeed. It would mean that people on KDE Invent could make issues and MRs directly to the Freedesktop Gitlab, for example, if both were federated.

If, instead, you won’t do it and prefer to keep Bugzilla as the main issue tracking platform, could you tell us why?

Here are the reasons why: https://community.kde.org/Get_Involved/Issue_Reporting/Why_not_GitLab_Issues

The tldr is that Gitlab Issues is limited for users, developers and triagers compared to current Bugzilla, given the current KDE infrastructure. These are just technical issues. The moment Gitlab solves those limitations, KDE would gladly use it.

[...] since they’re right there by the code base.

Note the section "Bugs need to be filed against individual repos". At it stands right now, if a non-technical user finds a plasmashell bug, they can just go to "File a bug":

and they're greeted with this:

And then they can choose Plasma and then plasmashell, both with very descriptive text mentioning what should be reported there. It's not too bad to find the right place to report things, to be honest. And there's an "I don't know" field, which is great. :)

Finding issues can be a bit finnicky, yeah. But you can click on the search field in the first page, type what you want to find, click on Quick Search and you get a list of results based on your keywords, and you can also click on the Search button and then click on Simple Search to look for some keyword in a specific product. Once you know it's pretty simple.

Maybe keep the Overview text and icon color as white for better contrast. The blue background color already conveys selection I think.

Correct. The requirements are:

• put a link to the community anywhere in a Mastodon toot and a post is automatically generated on Lemmy
• the first line becomes the title/headline
• additionally, a recent change in Lemmy removed Markdown formatting from headlines, so instances that are sufficiently up-to-date will have links and hashtags show up as literal text instead of links: https://pawb.social/comment/1624631

Ah. This was merged two weeks ago. https://github.com/LemmyNet/lemmy-ui/pull/1977

So the issue isn't that Pawb doesn't have it enabled, it's that Lemmy's new versions lost it and KDE's instance hasn't updated to the broken versions yet.