Yeah, only the very cheap ones have it nowadays. We are now in the era of giant screens, there's no space for an entire row of hardware buttons.

Hi there. Sorry for the necro comment (just realized after posting!). I'm just currently trying to figure out how to contribute, and came across this, so I figure I'm in the target market (ie someone not currently contributing but looking to start). My background is in marketing/design/UX. I just wanted to share my personal experience with the current interaction path. I didn't manage to complete my desired goal, which was finding a good beginner task that would help Plasma Mobile, fit my skills and had someone who could help me get started.

Is there a reason for the wontfix designation? I've read this thread a few times and don't see one.

The Speaker and Hold buttons are too close to the red Hangup button and if I'm suffering from fat fingers it's going to be a nightmare, they should be further apart.

Hi there, we use GitLab Issues now to track Plasma Mobile related issues.

https://invent.kde.org/plasma/kwin/-/merge_requests/1751

I think supporting older Halium devices (like Nexus 5X) would make no sense. So, if Halium support was brought back, maybe it should be brought back for Halium 9 and upwards only? Also, that would make the kwin hwc backend less complicated as it would not need hwc version 1 anymore.

AMAZING!

tbh not a fan of that idea especially considering that we wanna minimize the amount of chrome at any given time

• I think the Koko information sidebar, when opened, should stay there as a sidebar rather than a overlay
• I think the "crop" tool is a bit behind the Gwenview's:
  • Crop area should be same size as the image by default, and should not be able to be bigger or outsite the image itself
  • You should be able to set a aspect ratio for cropping, potentially "keep the same ratio as original image"

Next steps:

That's great! @mikeljohnson, what do you think the next step for Koko is?

this has just landed 🎉

Sweet!

started work at https://invent.kde.org/graphics/koko/-/merge_requests/69 (nice)

bad example haha, I might actually work on this today, since it should be pretty simple (famous last words)

I wouldn't call video support niche, as I think a lot of people who take family photos will have videos interspersed with their images. This is certainly the case for me, my wife, and my parents.

tbf feature wise koko already has most of the gwenview's features excluding some niche stuff like video support, so it's not like it can really get more complicated than it already is :P

I generally agree with that, but I wouldn't want to take it too far, as I think you can with minimalism. At least for the desktop use case where there is generally plenty of screen real estate available, I think it would be good to at least display the toolbar as well without requiring additional user interaction.

I think something we should keep in mind is that a lot of current Gwenview users don't actually want to use most of Gwenview's features. I'm not saying we shouldn't have them, but we should make sure we don't add more complexity to the UI than we really need to in the most common situations. I think the most common situation is when an image is being opened via another app like Dolphin. In that case, I think it's best to focus on just displaying the image, which Koko already does in its current state.

I guess this is not relevant anymore

This is now located in https://community.kde.org/Get_Involved/development#Plasma_Mobile

There is now https://develop.kde.org/docs/kirigami/. it's not perfect but it's a very good start. Let's close this and create new issues to the develop-kde-org repo.

The fonts kcm is now in the system settings, however, the fonts dialog still needs to be ported to be mobile friendly.

Yes, I agree that 10pt noto sans is too small.

there, does that fix it?

Oh heck I accidentally removed something...

Hello!
Im an LMMS user that was referred here by an LMMS dev.
I was wondering if I could help judge the FX, and how I can apply to do so.

There's a new page specifically for Plasma Mobile contest, please take a look and give me feedback: https://community.kde.org/Promo/Plasma_Mobile_Audio_Competition

I am going to close this task as it is more of libgdx or application specific issue then the Plasma Mobile itself.

https://invent.kde.org/plasma/polkit-kde-agent-1/-/merge_requests/4 this is now work in progress. Hopefully it will be in Plasma 5.22 release.

In T14204#251475, @EspiDev wrote:

One issue is the fact that we may need to factor in the "tail" of the song (the kind of echo you hear at 0:13 of the second example above). It'd be best if the ringtone submissions have at least one repeat so that we can jump back in the audio file to the first repeat when doing loops (since the beginning will then include the tail of the tune).

Of course, for some ringtones we might not need to care about this at all, if we just repeat the audio file entirely and it sounds fine.

One issue is the fact that we may need to factor in the "tail" of the song (the kind of echo you hear at 0:13 of the second example above). It'd be best if the ringtone submissions have at least one repeat so that we can jump back in the audio file to the first repeat when doing loops (since the beginning will then include the tail of the tune).

Some other examples (that I personally like lol):

Current look of Koko: