| Age | Commit message (Collapse) | Author |
|---|
|
This is one in a series of commits of trying to unclutter the context
menu, which was pretty unorganized.
Change-Id: I8a9473041730492a0b60c6b71fd7fd7996cedd89
Reviewed-on: https://gerrit.libreoffice.org/33768
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
The recents mechanism works like this:
Every time the file is opened, it saves that file to the shared
preferences set, by putting it in the first place, and removing the
oldest file from the list, if there are more than 4 recent files.
It also adds dynamic App Shortcuts if the device is 7.0 and above.
Screenshot: http://imgur.com/a/7kWOl
Edited the layout to add a new RecyclerView for recent items, as
well as the headers for both the recycler view's. Recent files
appear only if in home directory, below app bar and above the
file browser. This could be subjected to change in the future.
Screenshot of the recents section: http://imgur.com/a/qrqZq
Change-Id: I5c99aa26351d9ad2313e18b5b696d04a782e6155
Reviewed-on: https://gerrit.libreoffice.org/33759
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Refactored many fields of DisplayPortCalculator to not be
static, so that they could use the Context object from the
constructor. Once refactored, the static context object could be
removed from LibreOfficeMainActivity.
Change-Id: Ic23030b74a24c753a4a2d2086fc6301eeb9d8728
Reviewed-on: https://gerrit.libreoffice.org/33765
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I273ee17fc94e9d6e3b73ca0b9a4853a632123bd0
Reviewed-on: https://gerrit.libreoffice.org/33946
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Aleksandar Stefanović <theonewithideas@gmail.com>
|
|
Change-Id: I36f443c266670bd26aa6b813075e18653f372f52
Reviewed-on: https://gerrit.libreoffice.org/33900
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Moved LOKitThread back to LibreOfficeMainActivity, so that it could
use the context in the constructor. Once the Context became available
in LOKitThread, it was simply a matter of replacing static references
with the one passed in the constructor.
Also changed access levels of some methods in LOKitThread.
Change-Id: I0cc2c846c67b90907cbf3dce363666f9ab02d887
Reviewed-on: https://gerrit.libreoffice.org/33546
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Removed static context, and edited the access levels of some methods
in the classes, along with some general code style fixes.
Change-Id: I89c71fa38eaafb5cda721602cfc8dad10ba7d26a
Reviewed-on: https://gerrit.libreoffice.org/33557
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Removed references to static context, replaced them with the context
object already available in the class, and changed access levels on
some methods in LOKitTileProvider.
Change-Id: Ib52d325650377b77ec166ddbfb760f74c19067ff
Reviewed-on: https://gerrit.libreoffice.org/33554
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
This makes the dialog more modular, and it takes no parameters
instead of two. This is in the preparation of making
the classes more independent on each-other's states, which is very
important. Also, this follows the Android way of workflow better,
since there is no "wrapper" class around the dialog, but instead
the dialog is called directly.
Change-Id: I7571480a040efaf202fae3929cfe76d65c19653e
Reviewed-on: https://gerrit.libreoffice.org/33086
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Aleksandar Stefanović <theonewithideas@gmail.com>
|
|
Replaced empty spinner with the document title in the Main (viewer)
activity. Had to edit the themes to not disable title, and edit the
manifest to make the desired activities use that theme. If the theme
is set in the "application" tag, it will apply the theme globablly.
Also cleaned up and tightened the ToolbarController.
Change-Id: I5099860787b5f84d01c98c5e53ade519c2f89cc4
Reviewed-on: https://gerrit.libreoffice.org/33306
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Aleksandar Stefanović <theonewithideas@gmail.com>
|
|
Huge refactoring of the methods to use the passed instance of the
Context object instead of using the static one. I couldn't completely
remove the static object, because it requires restructuring of the
workflow so that it originates from the activity, and not from some
other random place. The way it was refactored is:
1. Find a place where the static object
(LibreOfficeMainActivity.mAppContext) is used.
2. Add a LibreOfficeMainActivity object to the method signature.
3. Repeat the process with a method that calls it, and repeat until
the LibreOfficeMainActivity object isn't available, so that it can be
passed through all the methods, to the place where the static object
was used.
4. Replace that static object with the parameter of the function.
The commit looks pretty huge, but it's basically just the simple
refactoring explained above. The memory leak isn't completely gone,
but this a progress towards it. Also moved the "global" objects of
Handler and LOKitThread from an Activity to an Application, which
is the correct place for "global" variables. Can someone explain why
Handler and LOKitThread are used? They seem to mostly do nothing, but
steeply increasing the complexity of the application.
Change-Id: Ib2be77fa3adea94d6b7849d0e2afa90bf318d68b
Reviewed-on: https://gerrit.libreoffice.org/33073
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Aleksandar Stefanović <theonewithideas@gmail.com>
|
|
It was coded pretty badly, so I cleaned it up. Most notably, it used
a static instance of the Activity, which is a huge no-no which
creates memory leaks. The irony is, it already had a reference to the
Activity used correctly in the constructor. One memory-leak fixed,
29 more to go (LibreOfficeMainActivity holds that static Activity
object which needs fixing). Also, simplified the "bottom toolbar"
in preparation for the CoordinatorLayout implementation which will
allow the activity to have fancy animations and smart interactions.
Change-Id: I31aa117f6179910db73a5256b0a287357e1dec83
Reviewed-on: https://gerrit.libreoffice.org/33010
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
Fixed typo in SearchController (SearchDriection -> SearchDirection)
Also tightened up the code.
Change-Id: Iedb6f95c9d8ed04cc166638250c2d565e92d79ff
Reviewed-on: https://gerrit.libreoffice.org/33011
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Because RecyclerView is more optimized, especially if there are lot
of items. This way, we don't have to recreate ListView and GridView
each time we switch view modes. Changed list adapter to appropriate
RecyclerView adapter, and created new grid adapter inline, next to
the list adapter, while deleting the older grid adapter file. Since
these adapters are almost identical in content, maybe we could:
a) Make them extend the same "base" adapter, to avoid duplicate code
b) Unite them into one adapter which would display appropriate views
at appropriate times.
Change-Id: I1545c2c245ca642a689dee584bffb15f90aac4a6
Reviewed-on: https://gerrit.libreoffice.org/32976
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Replaced the custom implementation of the drawer with the support library one.
This one inherently follows Material Design guidelines, and is much easier to
maintain. This implementation also allows for header in the drawer, and so
we could put something useful there to make the drawer even better. Also kept
the original way of programatically adding the menu items, although I find this
practice somewhat unelegant. Maybe we could have static list of items, and then
grey-out the ones that aren't currently available? Also added appropriate icons
to the menu items (which are vector drawables, of course), but I only covered
the providers that appeared on my device (I can't confirm that there are no
other providers), so if the provider is covered, it will have an icon, but if
I didn't cover it, it will appear just fine, but without an icon. Maybe we
could move the settings and sorting to the navigation drawer, also? It would
be cleaner and more elegant, IMO.
Change-Id: I02a051f0b75c6d4e16f518aa19fb9c6eef00f5e4
Reviewed-on: https://gerrit.libreoffice.org/32881
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I6d3a9354c702628e991c69176086efbbc28ddd74
Reviewed-on: https://gerrit.libreoffice.org/31753
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
Replaced old and busted icon design, with Google's generic app icon.
It is now a vector drawable, which means it will be sharp at any resolution,
while we only need to keep one tiny xml file for it. No folder thumbnail
support, but this a welcomed change nontheless.
Change-Id: Ie6e38a6ac8e6cf1bc2d22247c11b5de0bd0d8478
Reviewed-on: https://gerrit.libreoffice.org/32498
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Lowered all-caps navigation labels to something more professional.
Added a Spinner to the Toolbar in XML.
Reworked many lines of LibreOfficeUIActivity to remove possible NPE's, and also
removed redundant lines, which were mostly deprecated, as well as switching to
a newer implementation of a toolbar-spinner navigation pattern. There are more
deprecated methods, but I wanted them in a separate commit.
Change-Id: I15d5365ed7c00880873bf7874bc794008436bb99
Reviewed-on: https://gerrit.libreoffice.org/32497
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Import redundancy reported by Android Studio.
Change-Id: If46a43bb18268877d41d4957094acc543c4588fd
Reviewed-on: https://gerrit.libreoffice.org/32496
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
It builds correctly.
Note that the target version remained the same (22) instead of the current 25.
Change-Id: Ic14fc5b2e5aa04d621e86249d33c1d6d9bdce3c2
Reviewed-on: https://gerrit.libreoffice.org/32495
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I37b6fbf2639439a57c6d162b7817d009d1d49023
Reviewed-on: https://gerrit.libreoffice.org/32332
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Added variables to control state of bottom toolbars, and based
on their state open/close the bars
Change-Id: I5f9429b336451a354b95dcee18b71fb577c28559
Reviewed-on: https://gerrit.libreoffice.org/30298
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
as non-native mipmap resolutions don't get stripped from the apk (as
drawables would), but launchers and similar might still want to show the
higher-res version instead. Google Play store now enforces this.
Also rename to the common name for it ("ic_launcher" instead of "main")
Change-Id: I97318287f05556f5db0afaa0b23c0d8c9628465e
Reviewed-on: https://gerrit.libreoffice.org/31204
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I94036432e23b2d73b6e2006ed49f9890ae11aa05
|
|
and account for the libreofficekit changes
This reverts commit 50e9065cbbb2c62fa925cf5b561a85c715a0eb1e.
that did in turn revert 4ae8c3c20bd4a10ba141a32f01e23ac63636f9c3.
Change-Id: Ie02d8743b3608120ed63bfe2a014fa4139577b01
|
|
the linux build / libreofficekit also uses those and needs to be told
about this change as well.
This reverts commit 4ae8c3c20bd4a10ba141a32f01e23ac63636f9c3.
|
|
Change-Id: Ib0d2dac42814c9daf752f0421922fb093507eb7c
|
|
Change-Id: I0c0a8a540eccc022c405659f53da73bd87eced18
|
|
Change-Id: If42bf5757e2010fccc7061ccffda76048b2e0dda
|
|
Bunch of these were setting C++ or Make modes and icky tabs...
Also, reportedly Emacs can figure out to enable python-mode
automatically.
Change-Id: I50072488fb92cb4d27aa3f74f717a28ae3967543
|
|
Change-Id: I217fdc805ce425f8a4a17d0d0e924e532ec070de
Reviewed-on: https://gerrit.libreoffice.org/28983
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I6ffb450d935ae1f7b4900243b9ff2f8df408628f
Reviewed-on: https://gerrit.libreoffice.org/27829
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: Iaba74749c11cbac972fecf816e5bb090edd9e06c
Reviewed-on: https://gerrit.libreoffice.org/27802
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I87d83953094d31ed4e1bcf60c55dd19056a7994e
Reviewed-on: https://gerrit.libreoffice.org/28005
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I373db55ed819ed5d2a574ba2590032ee628218f4
Reviewed-on: https://gerrit.libreoffice.org/27634
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: Iecd6b5e13d6be14651f77d8e37f01117ba15a11e
Reviewed-on: https://gerrit.libreoffice.org/26883
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I350acc1735d5fd22a27434fc5ccf2ab39bf3d2cf
|
|
If we draw a black graphic handle manually, then it's possible to color
it later, this isn't easy if a bitmap is painted.
Change-Id: Ib4456fd5155862d52e3ffa79ee49c7bfd16fb742
Reviewed-on: https://gerrit.libreoffice.org/26860
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: If7262e114b5b4cd40e9c0a8929940199ea747595
Reviewed-on: https://gerrit.libreoffice.org/25025
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I3d484f7d7d9e466ae1b2ac4afe2b59d060fa8b77
Reviewed-on: https://gerrit.libreoffice.org/24537
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: Id81b16ff26283611f0b84929d831c827f847ab73
Reviewed-on: https://gerrit.libreoffice.org/24317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
removing the cache on each launch prevented opening files via intents
(i.e. from your mail application) unless the viewer was already running,
as it also deleted the temporary file that was created from the intent.
Change-Id: I0a4d9432f475e8434902ae11fc2b0c35fd25a71f
|
|
Change-Id: Icc086404a2ef32a38e972da9158f6156fdf74ef2
Reviewed-on: https://gerrit.libreoffice.org/23363
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I4586168d3af81f047a4ded59fc6d257f17554885
Reviewed-on: https://gerrit.libreoffice.org/22194
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I4382949a35df3877fc6c93a83d6e84cd892756a8
|
|
Background:
External SD cards are only partially supported by the Android system,
with a great deal of fragmentation on implementation across manufacturers
and android versions. There is no official support for OTG devices.
This commit adds:
1) External SD card support
2) OTG device support
Caveats:
1) Not tested on Android 6. Emulator crashes when opening
files on Android 6, using an unmodified build of the master branch.
2) OTG support currently works only if there is write access
to the OTG directory. The user must be aware of exact OTG directory
path or be able to navigate to it as well.
3) External SD card provider currently lacks file filtering.
Approach:
-----
Added new document providers.
External SD cards:
There are 2 different document providers external sd cards,
one for Android 4.4 and above, and the other for older versions.
1) New
Android 4.4 and above require usage of the DocumentFile wrapper class
to access files in external storage. Actual file paths are no longer
obtainable. As such, the underlying file will be cloned in a cache,
allowing us to get an actual file path and use LOK.
Some differences exist between 4.4 & 5+. The document provider handles
each case separately.
2) Legacy
Android 4.3 and below do not support the DocumentFile wrapper.
File object can be used in these versions, allowing actual file paths
to be obtained. The document provider guesses the root directory of
the SD card. If the guessing fails, the user is to navigate to
this directory himself.
OTG:
The OTG document provider resembles the legacy external SD card
document provider, requiring the user to locate the directory himself.
The document provider does not guess the root directory of the OTG
device as the location varies with manufacturer implementation.
-----
Supplementary Notes:
Attempting to use the internal app cache as the file cache like in
the ownCloud document provider did not work. Using the external app
cache works fine though. It could be because initializing LOK wipes
the internal app cache.
Would be good to test the ownCloud document provider to confirm if it
works.
Change-Id: Ie727cca265107bc49ca7e7b57130470f7fc52e06
Reviewed-on: https://gerrit.libreoffice.org/20738
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ibb15ac269ddfc61153d204079b070f7a5efbcbad
Reviewed-on: https://gerrit.libreoffice.org/21550
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I29f404dc5aee27b592eac7585c5142b91060fe5c
Reviewed-on: https://gerrit.libreoffice.org/21589
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I9a5940027423ff0791fa7da0b79b617412ce6b86
Reviewed-on: https://gerrit.libreoffice.org/21209
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
Change-Id: I3fba2c76c83381eb398c80947ef4849bccf7ab27
Reviewed-on: https://gerrit.libreoffice.org/21078
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
|
