With https://invent.kde.org/frameworks/kirigami/-/merge_requests/1235, we have a path forward here, at least for QML apps.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Wed, Apr 3
Sep 13 2023
Jul 5 2023
Jun 15 2023
Jun 1 2023
Mar 23 2023
Aug 2 2022
I prefer actions always being in a sidebar, especially via mobile, so I believe that mimicking how desktop applications provide their actions is regressive.
Jun 26 2022
Jun 20 2022
Besides toolbars, KXmlGui also provides KShortcutsDialog which is a free shortcut editor. This will also be useful in any app that has lots of shortcuts.
Oct 4 2021
That makes a lot of sense to me!
Oct 3 2021
With Kalendar we ended up using quite a bit of stuff from KConfigWidgets and KXmlGui.
Jul 31 2021
In T14211#260926, @ognarb wrote:In T14211#260924, @GB_2 wrote:In T14211#255944, @ngraham wrote:I'm kinda confused. You mean that, the sidebar and the files view (content) should share the same colour? Like in Discover?
Yes.
Does not seem like a good idea to me. We should make an effort to help users distinguish the areas of the window more easily, like we already do with the titlebar and window content. Pretty much every platform has this separation. It's also more pleasing to the eye.
+1 personally I would like to see sidebar using a subtle grey and the content all white. This would give a nice visual hierarchy there white is the predominant color on the screen and this will also reduce the impression that Breeze is old-looking because it's too much grey.
Kinda like the Clock screenshot but with a sidebar even less greyish
Jul 27 2021
Yeah, enforcing wasn't a good word in this context.
In T12435#260970, @fhek wrote:Personally I think this would be a good layout to enforce onto our applications
Sure but I think we should make it easier to follow the HIG, creating common components, good defaults, etc...
Jul 26 2021
https://develop.kde.org/hig/ < let's not reinvent the wheel. Whatever is there can be addressed if it doesn't fit. If an application doesn't fit the HIG it can definitely be addressed.
Personally I think this would be a good layout to enforce onto our applications:
Jul 24 2021
In T14211#260924, @GB_2 wrote:In T14211#255944, @ngraham wrote:I'm kinda confused. You mean that, the sidebar and the files view (content) should share the same colour? Like in Discover?
Yes.
Does not seem like a good idea to me. We should make an effort to help users distinguish the areas of the window more easily, like we already do with the titlebar and window content. Pretty much every platform has this separation. It's also more pleasing to the eye.
In T14211#255944, @ngraham wrote:I'm kinda confused. You mean that, the sidebar and the files view (content) should share the same colour? Like in Discover?
Yes.
Does not seem like a good idea to me. We should make an effort to help users distinguish the areas of the window more easily, like we already do with the titlebar and window content. Pretty much every platform has this separation. It's also more pleasing to the eye.
Jun 24 2021
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"
Jun 20 2021
Next steps:
Jun 19 2021
That's great! @mikeljohnson, what do you think the next step for Koko is?
this has just landed 🎉
Jun 16 2021
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)
Jun 15 2021
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
Jun 14 2021
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.
Jun 12 2021
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.
Jun 11 2021
May 24 2021
May 16 2021
Oh alright, I thought that, using two colors, like the clock app depicted above, would appeal more without destroyed UX and usability. It would make apps look more "interesting" imo. Maybe I'm just saying all those because it happens in most other popular software.
May 15 2021
I'm kinda confused. You mean that, the sidebar and the files view (content) should share the same colour? Like in Discover?
I'm kinda confused. You mean that, the sidebar and the files view (content) should share the same colour? Like in Discover? Wouldn't it help users to identify whether what they look at is a sidebar if it has a different colour (like eff0f1)?
May 14 2021
Dolphin's sidebar is a scrollable view of content items, so logically it should have a white sidebar too. It's even attempting to do so in a frameless manner already, it just doesn't really succeed because there isn't a solid line border on all sides of it.
What about desktop-"focused" apps like dolphin? I think that those apps could look like dolphin: window content (large areas) should be lighter than sidebars and titlebars+toolbars, in breeze light. I haven't studied dark theme though to tell a lot.
It strikes me that there is an easy way to conceptualize this.
Seems to no longer be relevant.
Apr 17 2021
Apr 1 2021
I think giving the lightest color to the widest areas seems technically the best: You got the darkest shade for titlebars, the middle one for sidebars and the rest (usually) will have the lightest color. (Talking about Breeze Light).
Mar 29 2021
Mar 28 2021
Mar 22 2021
Mar 20 2021
reference from other vendors:
Kirigami seems to give a very light page background for lists, but a darker one for other content.
Mar 10 2021
Jan 19 2021
this project is like a dream come true compared to pretty much any other available desktop UI. :D
No, the hamburger menu button I implemented is only meant to substitute the menu bar if the menu bar is hidden for whatever reason. The button can be put anywhere in the application but it's most common use is to put it on the toolbar. It's a more feature-rich version of the current hamburger menu in Dolphin.
Unrelated to that, menu bars and toolbars can already be hidden by users in many KDE applications. So if someone hides the menu bar, my hamburger menu button should show up somewhere instead of leaving users without any menu at all.
But have I understood correctly that your suggestion can switch between both a hamburger menu, a toolbar and/or a menubar?
Thanks for your answer! That project does sound smart and I really appreciate you are working on something like this!
For suggestions and wishes there is a bit of a blurry line between filing a bug report and starting a discussion here.
What you are writing might be better suited as a bug report to Kirigami but I am not certain. In any case I'll answer here because you are talking about a topic I am currently working on.
Jan 18 2021
Dec 17 2020
Yeah, I agree with Arjen too.
Dec 16 2020
I don't have a clear vision/proposal for this.
Perhaps @nicolasfella can clarify for us. :)
Dec 15 2020
In T13256#246574, @ngraham wrote:Very interesting. Great investigation! That could really be nice if this works out for our use case.
Very interesting. Great investigation! That could really be nice if this works out for our use case.
My reading of this task is that it's not asking for a literal re-implementation of KXMLGui so much as a central place to put desktop-relevant QML components so that functionality doesn't have to be re-implemented for every QML app.
My reading of this task is that it's not asking for a literal re-implementation of KXMLGui so much as a central place to put desktop-relevant QML components so that functionality doesn't have to be re-implemented for every QML app. Maybe this is more like the QML version of KWidgetsAddons than the QML version of KXMLGui.
Dec 14 2020
@ahiemstra for the moment I used a conditional drawer using a more desktop-oriented drawer on the desktop and a contextDrawer on mobile. See https://invent.kde.org/education/kalgebra/-/merge_requests/6
What happens if you force toolbar header style on mobile? As far as I know there is nothing special excluding actions from the toolbar, it's just that we use a different header style on mobile, so it should just display your contextual actions.
This has been mentioned a few times in chat, Do we gain anything by remaking a monolithic beast like KXmlGui? I have been thinking about this, and I think it would be much better to have small independent blocks that you can put together. In other words, have a "WindowState" object that you can point at any QML window to have its properties saved/restored. Or have an "EditableToolBar" item that can be used to replace the fixed toolbar of Kirigami. This has the advantage that these objects become small, focussed things with a clear purpose, rather than a complex beast where you don't really know what is going on.
Dec 13 2020
I think the point is that a Tier 1 framework must not depend on another Tier 1 framework. So, the solutions are to either increase the Tier of Kirigami or to introduce another umbrella framework similar to KXmlGui, which does the GUI generation based on Kirigami and KConfig (I would prefer the latter personally).
KConfig is Tier 1, so I don't see any reason why third parties could use Kirigami, but not KConfig.
I'm not so sure we need XML (or JSON) to create something similar to KXmlGui for QML because QML is already a good enough language to declare a list of actions in a declarative way. The more fundamental problem is that Kirigami is a tier 1 framework and as such can't depend on other frameworks like KConfig. This is a problem because we would need to save the states of the toolbars for editable toolbars, split view dimension for resizable columns, read from standard shortcuts with KStandardShortcut, save window dimensions, ...
Dec 12 2020
This is done in https://develop.kde.org/frameworks/kirigami/ but it could still improvements ;)
Dec 11 2020
I am looking into what Qt calls "compile time selection" with Qt6. On the first look it looks exactly what we had with manually importing PlasmaComponents.
Dec 9 2020
Nov 22 2020
Oct 29 2020
see generic point
Is there a way to implement an "emulation" for applications that don't explicit support said back functionality?
Alright some notes from discussions:
There are 2 ways we can approach this: generic (sending mouse back events) and powerful (have a dedicated API for it)
There are pros and cons to each method
Generic:
- Pros: simple, doesn't require anything from app developers
- Cons: not extensible, won't work consistently with different apps, could lead to a poor experience nullifying the point
Powerful(API):
- Pros: Extensible, reliable, consistent
- Cons: Requires an implementation from developers (although gives users a good experience), not all apps will be supported
Some notes on implementation:
Some UX things we discussed:
Oct 28 2020
In T13815#243933, @ngraham wrote:My android phone has a hardware back button in the bottom-right corner of the device, below the screen. Almost every other Android phone I've ever seen has the same thing. Is that a thing that nobody does anymore?
In T13815#243933, @ngraham wrote:My android phone has a hardware back button in the bottom-right corner of the device, below the screen. Almost every other Android phone I've ever seen has the same thing. Is that a thing that nobody does anymore?
Newer phones have the option between a software bottom panel (with back, home, multitask) and full gestures. Gestures can kinda depend on the OEM. At least for oneplus, swiping in from the left of the screen is the same as the back button.
Anyway I'll stop derailing the conversation. I agree that an SSD global back button would be a good idea in PlaMo.
My android phone has a hardware back button in the bottom-right corner of the device, below the screen. Almost every other Android phone I've ever seen has the same thing. Is that a thing that nobody does anymore?
In T13815#243929, @ngraham wrote:On Android, isn't the global back button a hardware thing?
On Android, isn't the global back button a hardware thing? Also I'm not sure there's a global back button in iOS.
...Thus underscoring the need for a "KXMLGui for QML apps".
the api which plasmoids use to notify "apply needed" is kinda weird.
the "final product" must be not in Kirigami, but somewhere it can depend from KConfig (and better, KconfigXT so KConfigSkeletonItem and what not)
In Android, there's now by default no back button, but a gesture.
Oct 27 2020
In T13815#243856, @IlyaBizyaev wrote:In Android, there's now by default no back button, but a gesture.
In Android, there's now by default no back button, but a gesture.
On iOS, navigating back is also swipe-based AFAIK.
I don't see why Plasma Mobile would need a back button. Moreover, I still believe the consensus was that the bottom panel will eventually go away entirely, as long as it doesn't break VM testing.