I know this is not really answering your question but I use yakuake on KDE, which is a drop-down terminal, and it uses F12 as the shortcut to open. Very fast, no hassle. Depending on how you set it up you can exit by F12 again, or it will hide when it loses focus i.e. you click somewhere outside of it.
I used to use Yakuake but realized I don’t always want a terminal. In fact, most of the time I do not want a terminal and if I do, I want it at a specific location. So most of the time I use the start->typing thing for firefox, steam, blender, and sometimes terminals that I am just going to use to run system-wide commands in.
@Kalcifer we use gitlab community edition which is completely open. Gitlab offered us a free ultimate subscription but we decided to keep using the 100% open source version instead.
Well their instance is open though, it’s just that the official Gitlab instance has more features that aren’t released in the OSS repository of the Gitlab software.
Still, if/when forge federation happens, I think it would be amazing if all major organizations that self-host their forge used one that supports this new feature (Forgejo), so the need to make all those sign-ups, usually just to open a single issue (shudder), on a million websites would finally vanish.
Who knows, if the idea picks up, eventually we might see it implemented into Gitlab too!
Well their instance is open though, it’s just that the official Gitlab instance has more features that aren’t released in the OSS repository of the Gitlab software.
I wasn’t intending to accuse KDE of using proprietary software! I apologize if it came across this way. My gripe is primarily with what you specified regarding GitLab itself.
I’d love to see Sourcehut myself tbh. But yeah, Gitlab is so annoying to navigate plus the need to have a fork of a repo on their server just to submit a single change is so annoying and leads to thousands of duplicate inactive repos which clog up the search results.
It’s a set of components (projects “hub.sr.ht”, wiki “man.sr.ht”, git repos “git.sr.ht”, mercurial repos “hg.sr.ht”, build service “builds.sr.ht”, bug trackers “todo.sr.ht”, mailing lists “lists.sr.ht”, I think that’s the main ones at least) which can be installed separately as needed (though at least the wiki is powered by version control so I think it needs at least one of the repo services). Everything created in these components is also separate except for projects which tie together multiple repos, lists, issue trackers and so on (for example, see sr.ht/~sircmpwn/sourcehut/ which is the main sourcehut project), as opposed to a strict “1 issue tracker per git repo” as with gitlab and a lot of the other “all in one” services.
It also emphasizes the git send-email workflow as opposed to the (in my opinion, supremely convoluted and annoying) PR workflow, which means you can just clone the repo, make your changes locally, and send patches. (Though you can still fork, push and then submit patches from the web interface if you want to, to get something similar to PRs.)
So KDE at the minimum could just have hub + git + lists (for patches), and keep Bugzilla as the single bug tracker, for example.
The builds/CI service is also supposedly excellent, but I have to say I haven’t used it yet and KDE is already using Jenkins anyway. Though of course, it does integrate with the other parts, CI for each commit and incoming patch set which is still useful to have. I think KDE is currently using GitLab CI/CD also.
I think that’s the main big parts, there’s more info about its features on the main website: sourcehut.org.
I do like the more modular approach that they took – many services unfortunately go the route of trying to make an “everything app” which often leads to bloat. This is of course not to accuse Gitea, Gitlab, Github, etc. of bloat, I’m just saying, in general, I do understand why they took this approach, and I can certainly appreciate it. I will say that, compared to the usual git services (Gitlab, Github, Gitea, etc.) it is severely lacking polish.
So KDE at the minimum could just have hub + git + lists (for patches), and keep Bugzilla as the single bug tracker, for example.
I personally despise bugzilla. It’s one of my least favorite parts about contributing to KDE. I personally find it very unintuitive, and messy. The UX of the service, on the whole, is not a pleasure.
many services unfortunately go the route of trying to make an “everything app” which often leads to bloat
I wouldn’t necessarily say that, it does work well for a lot of projects when used as an all in one package to have all development on, especially when it’s a public instance for many different projects such as GitHub. There’s just a lot of unnecessary parts and duplicated parts they have when specifically hosted for a single project, especially if there’s other infrastructure already in place. It feels kinda like running an Active Directory domain for one user and one PC (which I’m ironically considering doing, except that I have three computers).
I will say that, compared to the usual git services (Gitlab, Github, Gitea, etc.) it is severely lacking polish.
I do agree. One thing I can think of is that it would be very nice to have a link back to the project from a linked repo. Currently something that’s sorely missing imo. But they do say it’s alpha quality though ;)
I personally despise bugzilla. It’s one of my least favorite parts about contributing to KDE. I personally find it very unintuitive, and messy. The UX of the service, on the whole, is not a pleasure.
I get what you mean. I don’t mind it since I understand how it works, but for example I’m always apprehensive about clicking the submit button since I think maybe I accidentally edited some field I didn’t want to edit. There’s also some strange restrictions such having to upload attached files one by one and having to make a new comment for each of them. It’s certainly got its flaws, but the nice thing about it is that it’s a central bug database, with a lot more detailed categorization (bug status, dependencies, platforms, affected versions, product component, etc.) than what GitLab provides, which is pretty much just tags for all of those afaik, which is very valuable for a huge project like KDE. I’m not sure whether any FOSS alternatives that provide all that exist honestly.
I wouldn’t necessarily say that, it does work well for a lot of projects when used as an all in one package to have all development on, especially when it’s a public instance for many different projects such as GitHub.
Oh I wasn’t necessarily accusing Github, or any other service of being bloated, I was making more of a general statement.
the nice thing about it is that it’s a central bug database
I’m honestly not sure that a central database for bugs is the best of ideas. The issues for a project should, ideally, be tied to, and integrated with that specific project. I think that it encourages more community input – people can find the components that they like, and delve into that specific component, and its community without needing to worry about anything else in the ecosystem. It may be too overwhelming for someone to have to interact with everything from every other project in the ecosystem, instead of just what they are interested in.
I’m honestly not sure that a central database for bugs is the best of ideas. The issues for a project should, ideally, be tied to, and integrated with that specific project.
It’s very very useful when looking for bugs to at the very least have a central search, I’ve encountered issues before which are filed against a completely different app than the one I’m encountering it in (usually because the issue is actually in a library that both use), which I would have missed otherwise. Having a single database also allows then moving bugs between projects in cases such as that without having to recreate it and linking the old one to the new one.
It’s very very useful when looking for bugs to at the very least have a central search, I’ve encountered issues before which are filed against a completely different app than the one I’m encountering it in (usually because the issue is actually in a library that both use), which I would have missed otherwise. Having a single database also allows then moving bugs between projects in cases such as that without having to recreate it and linking the old one to the new one.
Perhaps a middle ground would be to organize individual repositories under an organization, like on github, where the organization has a global bug tracker, as well as each project.
Personally I think it’s so much better than PRs (not that I don’t think it can’t be improved), but to each their own I suppose. I’d also be happy if GitLab had an HTTP endpoint you could submit a single patch or an archive of patches to, or something like that.
(Apparently it does support submitting patch files directly. Via email, but not in the git send-email format. Weird. Will have to try it at some point.)
Afaik Gitlab has a CLI tool (maybe unoffcial, idk) that allows you to create MR’s from the commandline. I don’t believe you have to use the web interface.
First you can try disabling animations, i.e., setting the animation speed to ‘Instant’ (System Settings → Workspace Behavior → Animation Speed). Then the launcher will appear much quicker when you press ‘Start’ / the ‘Meta’ key.
Then you can try disabling some search plugins. To the right of the search field in the launcher, there’s a settings icon. Click on it and then on the ‘Configure Enabled Search Plugins…’ button. (The name of the button is misleading; you can also disable plugins here.) A good strategy is to first disable all plugins and see if this helps. If it does, enable each plugin you need, one by one, until the search becomes slow again.
Some level of unification would be good. They are simply too different. I’d be more than glad to offer design help for free. The email icon looks too much like ProtonMail’s. That is not OK.
I don’t have a proton mail icon on my desktop though. I don’t think that really matters. A consistency with the UI would be nice though. You could make an icon theme.
This email icon is a symmetrical blue/purple multicolor gradient with a shaded top. ProtonMail is an asymmetrical design in one color with varying levels of brightness and a blank top. The two look pretty distinct to me. Even without the different colors, the change in symmetry is quite obvious.
I do agree these don’t have unity in their design though as a set, they look pretty generic.
I would love to use the KApps for Calendar / Contacts / Mail for a better integration into KDE. But at this point Thunderbird is just so far ahead, I’m not sure KDE will be able to close the gap to make those apps a viable alternative
Thunderbird’s entire GUI locks up when a notification pops up. KMail can’t do that.
Thunderbird runs under Windows, KMail sometimes has at best an experimental Windows release but usually none at all. Decide for yourself how important Windows releases are for a Linux crowd.
I don’t care for them but Thunderbird has extensions.
Most importantly what doesn't thunderbird have that kmail has? Akondai server.
Kmail worked so badly with larger imap mailboxes, that I switched back to thunderbird recently.
Thunderbird has its problems but it works. Only other linux mail client that worked similarly well is evolution/gnome mail but I did not want to have gnome services running on my KDE desktop.
Seems so but I also don’t understand the Akonadi hate. When I still used POP3, mails appeared to be in the inbox twice but that was merely a cosmetic problem, IIRC. After migration to IMAP, I don’t think I ever had problems. That said, I’m currently not using any KDE PIM apps for unrelated reasons (my main PC is currently running Windows and Thunderbird is so much worse than KMail).
Then you did not try everything. With Linux a fresh installation is basically never needed. Last I’ve checked Akonadi is just a cache, never the actual data.
Praying for the day contacts and calendar events will be synced through Proton’s bridge. It could be a drop replacement of google services for a lot of people.
Oh great, so from disabling single mouse click to disabling that tap thing. I had hoped that in Plasma 6 I’ll have one few option that needs changing. Well, at least it’s configurable…
I agree, all these preferences (currency, time, date, measurements) shouldn’t need to fit in a determined locale box, but if you customize them it’s possible to run into issues. I believe choosing English (Ireland) might solve your issue? Either that or I have found a way to customize it way back and then forgot.
KDE
Oldest