@dobey said in App Design Concept:
But why are they split this way in the first place? And why do I need them to be there at all?
That's clear, no one can use a phone with one hand, so I propose that the action buttons are on the left side, if someone wants to use only one hand, it is not mandatory to use the left hand you can use the right hand if you want, there is not a meter distance to change in excess if you use both hands,
the submenus that I have put on the left side, could also be placed in the center of the screen, so that using the right or left hand would not affect you, some app put it to the right and others to the left, I think it does not look good ,
put the icon on the right side is by symmetry in the top bar, if you think it does not look good, it is removed from that position, I particularly like to see it.
greetings...
@arubislander Thanks for verifying that.
So it looks like this issue with the slide-in animation is something that's just disabled on tablets in general (and probably on PC config as well).
Sadly the UITK hasn't been maintained for...I think years? and there's no current plan to maintain it.
But I agree, Dekko does have many good things that should be implemented in UITK.
Anyway, QQC2 has that page transition animation so apps that use it has it.
What will provide this "HUD" exactly? Will it function when running these apps on other platforms, or under other environments?
Menu export over D-Bus, mainly, or anything exported over D-Bus, plus any external scripts or programs relevant to the app.
A robust API (like KDE's DWD) would of course not be supported by most applications, but neither is any particular CSD implementation, and that's OK. But at least applications with different tool-kits could use such an API, unlike Gnome CSD which is just for Gnome apps.
Will it function when running these apps on other platforms, or under other environments?
Yes, HUD implementations are completely independent of the WM under X and relatively independent under Wayland. Gnome menu-less CSDs aren't supported on KDE, not to mention other operating systems.
What problem is it actually solving?
Same problems Gnome's HIG is solving, and many more. The "more" includes consistency, flexibility, discovery etc.
I think I may need to clarify the benefits a little better, but I think it ultimately boils down to some people thinking it would be valuable and other people thinking it's not worth it.
I'll post a pic of my device, just need time to stage it and take it
I'll do a couple (with and without desktop mode) bare in mind my port isn't complete
If every screen/page/scope...whatever it is would be customizable, then yes, it would be awesome. But since scopes are going to be obsolete, don't know if that pass Ubports design plans. Certainly looks nuch better then the old scopes, and as a concept looks better than any design proposal before.
is there a way to have in the your app section (the middle) something like a unified scope
back in the old topic : https://forums.ubports.com/topic/568/the-big-scope-question/8
I proposed to keep scope but to separate the content producer from scope rendering
Developpers add something like dispatcher in their manifest & return a json when called (optional arguments ?)
Home screen let filters and draw those jsons data.
well or providing a pull/merge request... ;-)
You could look at the examples of the near past and learn from them how to do it... if you're interested in trying I can post a links to the changes made in old telegram app or the clock for example (when I'm back at the pc)...
Move Topic
Looks like your connection to UBports Forum was lost, please wait while we try to reconnect.
Or perhaps this:
