Hey everyone, @xyquadrat, @ngraham, @cfeck, myself, and others have continued this over at the Bugsquad project page here on Phabricator, with the idea of keeping a schedule going. Check out the calendar for the next event!

I'm closing this out. The calendar is created, and the first event is up there, with more to come.

I've spoken with @xyquadrat regarding kicking off the Bugsquad schedule with Krita, to align with a goal/fundraiser to eliminate bugs. Awaiting details from him, but tentatively we are scheduling for the 16th of September to start. A second date would be either the 23rd, or during the week.

Any movement on this? It would be great to use the dictionary in krunner. Still broken in 5.13.4.

In D15340#322453, @dhaumann wrote:

Btw, we forgot to add the themes to the Qt resource file, see also D15358

You can test the theme with the demo app in ksyntaxhighlighting: Go to the build-directory, then type ./bin/codeeditor <path-to-some-file-to-highlight>
Then, you can switch the theme with the context menu.

Thanks, I'll make sure to add to that file if I add more themes.

In D15340#322112, @dhaumann wrote:

Looks good to me.

Related: in order to have better unit testing, would you be willing to add a unit test to https://github.com/KDE/syntax-highlighting/blob/master/autotests/theme_test.cpp called

void testJsonData() { ... }

This test would iterate over all themes via Qt Resources and check wether all 31 default text styles exist, and also check for the existence of the editor colors. This would help us to catch theme issues early in the future.

Feel free to commit this patch now.

Thanks, I can. I'm getting an error in Arcanist, so let me diagnose that and I'll land it.

In D15337#322043, @dhaumann wrote:

Solarized dark still only has 28 colors, right? Can you add the missing ones?

• Added three missing definitions

@dhaumann, I've added these colors to KSyntaxHighlighting over here: D15340

You were right again. For some reason that Others= disappeared from my ~/.config/katesyntaxhighlightingrc so I didn't notice it. Even though it was defined and displaying fine in the GUI. Weird.

• Fixed Others definition

• Some Marker color tweaks to ensure Solarized interaction rule adherence

• Fixed Light scheme Error color

• Solarized Light Region Marker fix and small Dark tweak.

I've fixed the section. I'm actually working on the KSyntaxHighlighting themes now, you'll see those in another patch.

• Fixed section code

What made you step and and decide to contribute to KDE?

• Besides enjoying the DE, it appeared to be a community that was making smart decisions (2017 Goals for example) and was growing.

What was your point of entry to KDE?

• Nate's blog posts basically, and Nate himself.

In what area are you contributing to (development, translation, documentation etc.)?

• Right now a mix of development and bug triaging, with maybe documentation later.

How did you decide where to contribute?

• I decided to work in areas that will help in the 2017 Goals. I like the productivity goal to polish the DE, and I like the onboarding goal to make the project easier to join. Helping a long-time FLOSS project grow is something I'd like to do. Right now my development efforts are small patches, since I'm not much of a programmer right now. Just things I know I can handle. So I'm now focusing on bug triaging, to hopefully assist those who do know how to program well.

What steps did you follow to get involved?

• I started out talking with Nate, he helped me through the 1-2-3 of getting signed up with my various accounts and a dev evironment. He and Henrik recommended some Phabricator Tasks and bugs/feature requests to tackle. Mostly icon fixes, menu edits, stuff like that. From there, I just spent time browsing randomly through Phabricator, finding Tasks and Projects that were interesting. Watching the Activity feed on the right is also helpful to see what cool things are happening and might be worth looking at to offer comments or assistance.

What did you enjoy most in the process of joining KDE?

• The friendliness of everyone, and the ease of joining. There were no trials or tests to go through.

What where the difficulties you came across?

• The introductory process of reading Wiki pages. Even with the improvements to Get Involved, there is no easy 1-2-3, here is how you get started. For example, to get started as a developer, you are pointed to an article, which has lots of information, sure, but is not a set procedure really. I was looking for something like:
  1. Create a Bugzilla account, do this.
  2. Create a KDE Identity account, do this.
  3. Create a Phabricator account, do this.
  4. Get your dev environment setup, follow these steps.
  5. Pull down this Git repo (say, a tutorial repo), create a branch
  6. Edit this file, commit it, and create a diff via Arcanist.
  7. Once approved, land your commit like this.
  8. You have now followed the basic process and can contribute!

I love all of these HIDPI fixes lately.

I like this, but I feel this should be merged into T8712. The welcome team would make this one of their steps for on-boarding a newcomer.

I'd be glad to help out. This is something that would be a huge help in my opinion. I'm pretty new (I'll answer those newcomer questions shortly), and I know having an easier to find on-boarding group would have been great. Luckily, I found Nate and started bothering him, so it all worked out. But I'm sure a lot of people could use a helping hand to get settled into a KDE project.

I've taken the gist of the old Bugsquad page and added it as a section to the main Bug Triaging page. I reviewed the other old floating Bugsquad sub-pages and you're right, the content was mostly re-hash of the same material. So I think this is sufficient, and more visible than previously. I'll mark this resolved.

Bugsquad wiki section created and linked to calendar.

Calendar created thanks to Sysadmin. I've added a link to the Bugsquad menu on the left. It's just a query, so you can make your own if you want, such as for list view. You can also export an ICS of the query results, which is great.

I hope not, I'd rather keep it in-house.

Hi everyone just thought I'd drop a note here as well. I've had @sysadmin recreate the Bugsquad, but in Phabricator for easy collaboration. I'd like to resurrect it, with a set schedule of triaging days. I've asked @sysadmin about adding a calendar to the project, or allowing other Calendar edit access. If not, I'll create a Google Calendar people can subscribe to I suppose.

Yeah, maybe not all the stuff. Just what Bugsquad is, go check out Phab, here's the calendar, etc. Maybe just put it on the Triaging page. I dunno. I don't want to duplicate work though.

Hi @xyquadrat I've had @sysadmin recreate the Bugsquad, but in Phabricator for easy collaboration. I'd like to resurrect it, with a set schedule of triaging days as you started here. I've asked @sysadmin about adding a calendar to the project, or allowing other Calendar edit access. If not, I'll create a Google Calendar people can subscribe to I suppose.

I agree with keeping UNCONFIRMED/CONFIRMED. I was going to make an argument for keeping that as I think it makes sense. Bugs come in, someone looks at it, and reproduces it (or takes other action). So for the triagers I think it makes sense to be able to easily find bugs that have not been reproduced yet.

Ok, I've reviewed the prior list. I've done the following for each product:

• Check Bugzilla for age of any remaining bugs
• Check Git and SVN for age of commits (not created by automated systems)
• Check KDE Wikis for information about unmaintained or obsolete status
• Check Google/DDG for information about unmaintained or obsolete status
• Closed any open bugs left lingering in an unmaintained, dead product.
• Used gut instinct on any that may still be used, removing them from the list

In D15093#319245, @andersonbruce wrote:

I'm not sure if the author or the reviewer is supposed to check the "Done" box on the inline comments but I think that I have addressed all the various comments made, both inline and separately.

The author can. :)

Hey Nate, is there a reason why Documents was not added with this patch? I always end up adding it. I was reading through D10245#201638 and the discussion seemed in favor of adding it, along with the Desktop and Downloads.

In D15011#314963, @filipf wrote:

To add more to the analysis, since Kickoff is a plasmoid, what seemed like a good idea to me was to have a look at how other plasmoids are designed (especially with relevance to the elements touched on in this proposal).

The Clipboard plasmoid stood out to me because as another unibody plasmoid, it seems to me like it handles the search box gracefully. I created some pics, this time with Breeze Dark to switch it up a bit:

Behavior: (1) non-selected it doesn't have an outer glow or a colored stroke; (2) when hovered over the stroke inherits the selection color; (3) only when clicked on or typed it does it turn on outer glow and the text selection line blings

Copied into Kickoff it doesn't look too bad (left pic). Since Kickoff is and can be more transparent, if possible what would help blend it in more is to lower the opacity by maybe 15-20% (right pic):

Now as for adding differentation in Kickoff, my observations were:

• Kickoff isn't actually unibody -> if we look closely, Breeze Dark reveals that it actually places tabs into squares + other tabs such as the Application one already have separators
• Other plasmoids do make use of separators, adding them would not create a design inconsistency on the whole
• Although not as common, some plasmoids do also shade certain sections differently (e.g. plasma-pa), so at least what can be concluded is that shading a part of Kickoff differently also wouldn't be unprecedented

Invalid per @bshah. I can verify, as I've personally submitted bugs to Application Dashboard.

If this could be integrated into Patreon or Liberapay, that would be great. It is an easy way to tap into a pool of people interested in providing support, and makes it very easy for these people to do so. Especially Patreon. I support a number of FOSS projects monthly via these means and am always looking for more. :)

Awesome feature, thank you for working on this!

Ok I'll go through the lists later and get you a definitive one.

Do we have any traction on moving forward with removing these products? Or at least closing them out? What's the next steps?

I just wanted to mention here that I recently installed Manjaro on a laptop, and they included TLP by default. Out of the box I was getting battery usage on-par with Windows, very impressive. No USB/Bluetooth or other issues so far seen.

I just wanted to mention this still works fine for me and resolves numerous icon scaling issues.

Closing per Rick above.

Should this be closed?

I'm surprised Neon is using snap due to the appstream issue. It also has problems with respecting themes (or the lack thereof). Having used both for a variety of popular desktop apps, I would rather see Flatpak enabled as a backend than Snap.

Abandoned in favor of Bugzilla 392811.

Abandoned in favor of Bugzilla 392810.

Abandoned in favor of Buzilla 392809.

Abandoned in favor of Buzilla 371881 and 386138.

I like the bigger stars, but then again I seem to increase font size and whatnot for a lot of things.

Yeah I like it without since they are already on separate cards.

In D10352#211406, @nmel wrote:

Martin, thanks for investigation and for writing details about it. I propose we ask at the appropriate mailing list or forum anyway, just to make sure we are not trying to reinvent the wheel. There should be a lot of other KDE apps with the same problem and it's likely their devs already solved the issue. If not, we can try to extend KIconLoader for supporting the logic we need.

In D6313#239212, @cfeck wrote:

In other words, the icon theme designer can now decide if he makes HiDPI only bigger or more detailed by symlinking to either the less detailed or the more detailed svg, without duplicating the icon files?

Exactly, that is correct. They could also make special icons if they desire, just like the other folders (32x32, 64x64, etc).

@ngraham, in the initial description @broulik forced a @2x folder via symlink to test. Otherwise no change will be observed. :)

Nice placement too. I really, really like how this looks.