naveensingh
commented
8 months ago That kind of UI works best on large screens, probably the reason why you'd to show Dolphin here.
Closed RokeJulianLockhart closed 8 months ago
naveensingh
commented
8 months ago That kind of UI works best on large screens, probably the reason why you'd to show Dolphin here.
RokeJulianLockhart
commented
8 months ago https://github.com/FossifyOrg/General-Discussion/issues/124#issuecomment-1984902936
@naveensingh, I've used Dolphin on KDE Plasma Mobile 5 running on my Fairphone 4 (using postmarketOS). Its display specifications are available at https://www.gsmarena.com/fairphone_4-11136.php#:~:text=to-body%20ratio)-,resolution,-1080%20x%202340 if of interest. The functionality which I have listed was as useful in that form factor as it was in 16:9 1440p on my desktop. I fail to see why display form factor would in any substantial manner correlate with theat functionality losing its usefulness.
naveensingh
commented
8 months ago @RokeJulianLockhart I never tried the mobile version, care to share some screenshots?
I fail to see why display form factor would in any substantial manner correlate with theat functionality losing its usefulness.
Accessibility is important. The size of an individual UI element is inversely proportional to the number of UI elements. Too many UI elements means each UI element has to be tiny to fit on the device.
RokeJulianLockhart
commented
8 months ago https://github.com/FossifyOrg/General-Discussion/issues/124#issuecomment-1986265384
@naveensingh, there's no mobile version — it's adaptive enough to be at least usable on a smaller form factor:
That's just the window scaled on my desktop. As you can see, it's not wonderfully adaptive, but the primary section (which is all we care about for the purposes of this issue) remains perfectly usable. Do note that the touch targets expand when it's being used on a mobile device. Relevantly, I have used a lot of applications on my Android device which use tables for displaying information — mostly database and spreadsheet editors. As long as their touch targets are the standard size, it's no more difficult than when using a list, and definitely quicker when scanning multiple entries.
I'm not proposing that we modify the sizes of any of the elements, because we have the OS-wide scale factor which com.android.settings exposes for that. I'm merely proposing that the user be able to use a table view instead of a list should they desire it, especially when in landscape (considering that lists don't work well there).
naveensingh
commented
8 months ago Ok, I'll think about adding some more info in landscape mode.
RokeJulianLockhart
commented
8 months ago https://github.com/FossifyOrg/General-Discussion/issues/124#issuecomment-1986881820
@naveensingh, not necessarily more information, just how it's presented. Many thanks.
Checklist
Which apps should have this feature?
Contacts, File Manager, Gallery, Messages, Music Player, Notes, Phone, Voice Recorder
Feature description
The lists can of course by default solely contain the attributes they currently do, but should possess the capability to display every attribute of their child item without the need for the user to invoke/select/enter that item.
Why do you want this feature?
Notably, the File Manager list view type, and Contacts contact lists, are not tables, so I can't see multiple attributes simultaneously for each item.
Additional information
depicts what I propose. Note that I'm solely referring to the right-hand primary section. The left panel is irrelevant - it is the perview of https://github.com/FossifyOrg/General-Discussion/issues/125#issue-2144664555.