File browser reshuffle 2.0 #11792
File browser reshuffle 2.0 #11792
Conversation
|
Look at it please: you can move to the top of addToMainMenu, then you will have fc.display_mode_type that is false for classic mode, or "list" or "mosaic".You can use it to shorten all checks. |
looking into it |
|
Looks cool. 'Mosaic' has always confused me - I'd be open to a name that reminds you more or a grid instead. In general I think one of the biggest hindrances to new users is settings overload, and while I don't want to remove anything, it's always good to make it easier for users to understand the basics. |
|
First impressions on wordings and placement: |
| text = _("Use this mode everywhere"), | ||
| text = _("Hide book covers"), | ||
| enabled_func = function() | ||
| return not fc.display_mode_type == false |
There was a problem hiding this comment.
We usually write
return fc.display_mode_type and true or falseThere was a problem hiding this comment.
what about return fc.display_mode_type == false ?
There was a problem hiding this comment.
That's opposite to what you need.
There was a problem hiding this comment.
Yes i know, what i am asking is: would you write that in a different way too?
There was a problem hiding this comment.
For this case it can be
return fc.display_mode_type ~= nil
|
We will not be able to have, say, Collections in Mosaic with covers and History in Mosaic without covers, right? |
|
(Haven't yet "read" the new wordings.) @hius07 and me mentionned around #11605 (reply in thread) that we didn't like not having the 6 modes directly available. But, with this change, there are issues:
|
you are not wrong there, I know this could have been written in a much nicer way, but I didn't want to be asking for help as I know another approach would be much more difficult given my level of experience (or lack of really)
wink, exactly what I was saying before.
what do you mean? you can certainly still do that, well with the caveat of the
That is quite the accusation there @poire-z, slow down. I am not trying to hide anything from anyone, I think I have been open about issues in the past #11586 (comment). that just went over the radar. |
do you any other suggestions, otherwise we could revert to display as in "display view"
cool.
again, any other ideas? I was actually quite proud of that one.
consider it removed.
I did think about this, however, this is something you do once therefore probably not needed right at the front of the menu.
not per se, my issue lies with many places using "Settings" (not like "x settings") but literally just "settings", I would like to reduce it to just one. I am happy to keep it as "settings" but the "settings" elsewhere would eventually go away.
that was an overlook, my bad.
that was already pointed out, as of now the answer would be no. But I don't intend to remove them. |
The obvious alternative to just |
I don't mind "Settings" being used here, so long as all the other ones slowly disappear -one by one-. Actually it makes some sense to use it here where it is broad and general. |
| }, | ||
| { | ||
| text = _("Classic mode settings"), | ||
| text = _("Classic view properties"), |
There was a problem hiding this comment.
Proposed change: "Classic view settings".
|
CircleCI warnings: |
I think you could still easily get Hide book covers to stick when switching between Grid & list. But if you switch to Classic, you currently can't know what was the previous state.
I mean just that: the caveat of the Have you got an idea on how to solve that? Your changes are too filebrowser centric. If you want stuff to be intuitive for History and Collections, you may need to triplicate lots of stuff there. Also, you can't use enabled_func on the Even if I don't dislike the intended look & feel, I don't think it's worth all these complications :) |
|
okay, back here. I have been thinking about this, how to solve the issues and so forth.
I was considering saving to G_settings and reading it.
I hear you, well read you.
lets not.
I hadn't consider this either. that steams mainly from alway using the same view for history and
well it would certainly be easier if you could help. I don't quite get your reticence (see below) so slow steps.
|
Keep the menu structure as is, change the wordings only. |
That would be an ugly option.
Above is my reticence: doing things right would need more conviction and interest and work and focus (and time, that I can't afford at the moment), and copiloting you would be painful, for both of us. (I'd rather waste myself a weekend and do it alone myself). Anyway, some ideas that would not require all the above suggested hard work (I hope I've been scary enough:)), keeping this as a UI only job: You could store the individual state of hide_cover/use_filename in an internal variable, no need to save it, it would be remembered only for the current menu session. When the menu is first opened and these vars are not there, you would compute their initial values from the initial mode. I think it's fine if we don't remember that when one month ago the use tested Grid with hide covers, and settled on List with covers, if he now switches to Grid he gets covers. You just need that if now when testing stuff, when he has hideCover, when he switches from Grid to List to Classic to Grid, he gets a sticky hideCover. If you don't want to triplicate things, the big loop that builds the 3 menu items (filebrowser, history, collections) should be reworked a bit, and should also build the Hide cover/Filename only menu items in the 3 submenus - setting the right initial values to the mentionned settings from the proper fb/history/collection current mode. |
Sorry (probably). :-) |
So I tried to make them "stick" and to adjust the for loops and failed miserably, so two options, three really.
|
Original PR here #11781
From the makers of the wildly successful Sleep screen rework #11549 and the yet to be merged status bar makeover #11678, We present to you the 'new kid in town', the new file browser (file cabinet) menu.
There has been a far less aggressive approach here, most of the work pertains the reduction of "view modes" and rewording of settings. Some logic was added for the functioning of the simpler view modes but besides that no changes in functionality were added or removed.
I am conflicted about the use of the word "mosaic" here, as what we get is a standard grid view that has nothing to do with actual mosaics, I would love to hear what you think, should it go, should it stay?
the following screenshots were captured on a non-touch kindle 4, so some options might not appear there. Anyway without any further ado,
Here it is the menu upon opening:
after going to the
Library view:Inside
mosaic and list view properties:and finally, inside the
file managementsubmenu:Important
I would like to have the classic view properties greyed out when 'classic mode' NOT selected but the usual
enable functiondoes not work in that case, any help there would be greatly appreciated.Last but not least, thanks to @Frenzie for his help, patience and support.
This change is