Right now only replacing the icon in the action bar is supported.
That's why the term "Icon Pack" is used in the UI.
Known bug: In a PreferenceActivity the second level still shows the
default app icon in the action bar :(
Icon packs need to include an activity with an intent filter for
the action "org.k9mail.THEME_PACK".
Example:
<activity android:name=".SomeActivity">
<intent-filter>
<action android:name="org.k9mail.THEME_PACK" />
</intent-filter>
<!-- Version number for the theme pack format -->
<meta-data android:name="version" android:value="1"/>
<meta-data android:name="name" android:value="Fancy icon"/>
<meta-data android:name="author" android:value="cketti"/>
<meta-data android:name="icon_app"
android:resource="@drawable/ic_app"/>
</activity>
- Since the split-view change, MessageView is only a fragment, so we
can't call setTheme() anymore so easily.
Instead, use a ContextThemeWrapper and use that to inflate the
layout. This way the message header and attachment view
are styled correctly.
- The HTC WebView fix in SingleMessageView was returning the wrong
background color, when message view theme and global theme differ,
because it always used the global theme to retrieve it.
Fix: Specifically put the light/dark values in the themes.xml,
and get them using getContext().getTheme().resolveAttribute().
getContext() will use the ContextThemeWrapper from above, so
even if the global and message view themes differ, it aleays
returns the correct one.
The getThemeBackgroundColor() method added to the K9ActivityMagic
interface in 309eeb72ac is now not
needed anymore, and was removed.
This commit addresses 2 issues:
1) Before, a general GestureDetector was registered on the highest level in K9Activity
This resulted in EVERY inherited activity to have a useless, unused gesture detector.
But more than that, in MessageList, a second GestureDetector was assigned to the ListView.
On every fling gesture, both detectors called the onSwipe() methods,
which technically did the following:
- The one directly assigned to the ListView would work corectly by mapping the
(local) event coordinates to the right entry in the ListView
- The global one worked on screen coordinates, so the onSwipe() method would
likely select the wrong ListView entry (system menu bar offset).
- For some reason this "worked" fine, and only the correct entry was selected,
despite two detectors used.
2) The gesture detection for the MessageView caused problems when the message
itself was scrollable, i.e. wide HTML mails. A fling gesture inside the WebView
would scroll the message, but also switch the message.
This commit fixes all those by doing the following:
- Don't register the GestureDetector in K9Activity, instead make the member variable
accessible by subclasses.
- In the subclasses that need a detector register it
- In K9Activity.dispatchTouchEvent() check for mGestureDetector being null
- For MessageList:
* Remove the duplicate gesture detector assigned to the ListView
* in the handleSwipe() methods: calclulate pixel offset of the ListView to make
it work using the global screen coordinates
- For MessageView: Limit sensitive area to the message header, to prevent interference
with the WebView scrolling
- Respect current behavior:
* Force-enable gestures for the MessageList
* Respect user setting in MessageView
- Make sure that after a successful swipe gesture, any pending action is cancelled, to
prevent unwanted things to happen (such as expanding the header after changing
the message, or a context menu popping up in the MessageList).
See http://code.google.com/p/android/issues/detail?id=8497
The ScrollView around the WebView caused all sorts of problems. This
change removes the ScrollView and uses the undocumented method
WebView.setEmbeddedTitleBar() to set the MessageHeader view as "title
bar" of the WebView. This allows MessageHeader to scroll away making
more room for the WebView.
All of the "magic title bar" code was originally implemented by Jesse
for Kaiten.
Because WebView doesn't support a scrolling footer we can no longer
support scrolling buttons or attachments at the end of the message. Now
users can switch from message view to attachment view via a button just
below the message headers.
I also copied some code for which I was too lazy to create a separate
commit. It allows to display attachments we didn't use to show by
clicking on a "More..." button in the attachment view. Those
attachments are mostly images referenced by the HTML part (e.g.
background images).
Fixes issue 3291
Make the mTopView a ToggleScrollView. The only consumer is currently the MessageView, which uses a ToggleScrollView anyway. This should make it easier to reuse the anti-scrolling features in ToggleScrollView for ListView later on.
preferences Storage importers/exporters. Password/encryption key
prompting is now down in centralized place. On import, the password
prompt is given if the file to be imported uses an importer
implementation that requires a password and no password is provided.
On export, the password prompt is given if the chosen version is for
an exporter that requires a password and no password was provided.
For instance, for automatic backups, a password could be stored in
preferences and provided to the exporter, so no password prompt would
be given.
Update issue 662
We tried out the long press for a bit and deemed it too sensitive for general usage. It can cause problems with gestures and such, so I removed it again. I hope using the option menu is not too much overhead.
If you want to include it in your custom build or anything, then r 1976 and r1977 should be enough.
Update issue 662
Added the long press initiation of text selection. I also noticed we'll have to make sure text selection is not recognized as a gesture (or at least ignored as gesture).
- Created "controller" and "mail.filter" package
- Moved a lot of classes to new/other packages
- Removed unused classes: NoSuchProviderException, MessageDateComparator
cketti