App list layouts are broken
Hans, assigning to you since this all comes from the modifications made to res/layout/applistitem.xml in b06792524ecaed6353.
Below are the screenshots with layout bounds.
Old layout, normal:
Old layout, compact:
New layout, normal:
New layout, compact:
Issues:
- Using the compact layout no longer makes more items fit in the list, since heights are now hard-coded (wtf?)
- The icon is no longer centered properly. Why are we using hard-coded margins to center it artificially now? Seems wrong to me.
- You also reverted some of my earlier changes. For example, the parent LinearLayout is no longer explicitly horizontal, which is a default but nevertheless lint asks for it to be explicit to avoid bugs.
- dip is just an alias to dp. Before we used dp everywhere. Changing some sizes to dip and leaving others to dp for no reason is weird.
Granted that I could have seen some of these issues before merging the MR, but reading XML layouts is a pain and I just assumed that you did what needed to be done to simply transition to AppCompat. You seemingly rewrite most of the layout for no apparent reason, so I'm a bit confused. Stable release stopper for obvious reasons.
See 8ed76f47eef59fa182e25.
Activity
It is true that I'm not very good at the layout stuff. appcompat changed a lot of that stuff since there are different widgets in use, different defaults here and there, and the introduction of a set of constants for laying out list items (e.g.
?attr/listPreferredItemPaddingLeft). There were odd little things here and there that were caused by what I think was these differences. Things looked good by measure, but I also did not know about a compact layout.I'm pretty sure I didn't add any lint warnings, I usually pay close attention to those. Indeed, the appcompat porting process was largely based around looking at those warnings. Perhaps that's something that changed in appcompat? Or we have different versions of the tools? I used ADT 23.0.2.
You obviously know a lot more about layouts than me, so I'm happy to defer to you on how you think it should go. No need to run it by me. My only concern is that things aim to be as plain appcompat as possible, i.e. using the provided constants, layouts, etc. Customization means more maintenance, and non-standard layout patterns that don't match what other devs might be used to from working with appcompat and API 14+.
I'm not good at layouts either, especially if they are done in XML. If you look at the git log of res/layout, you'll see dozens of commits from me about a year ago when I fucked up things on a daily basis.
But I got it to work nicely on all devices at one point, so I don't want it breaking.
Using standard constants is fine I suppose, as long as they don't break stuff like centering or the compact layout. I'll have a look at this over the weekend.
-
I think some breakage was inevitable with the switch to appcompat. Another idea is to consider the compact layout deprecated, with the replacement being the live search filtering that is coming very soon (its already in the "Setup Local Repo"). I'm headed offline in a hour, I'll check back in on this when I'm back online and see what I can do then.
How is a live search filtering a replacement for the compact layout? I find 48dp to be way too large, especially because the icons take way too much vertical space and few apps fit in my screen.
Granted that this setup with the "compact layout" setting can be improved, I'm open to suggestions.
Quickly finding what you are looking for and seeing more apps at any given time are different things IMHO. Furthermore, I don't think this has any relation at all to screen sizes. I'd even argue that it's the other way round - large icons are annoying on large screens like mine.
And I personally don't care about android-ish patterns that try to think for the user and remove settings. I hate the stock AOSP launcher because it has very few options and drives me nuts, for example.
