| | <<<Back 1 day (to 2017/05/11) | 20170512 |
| sebras | tor8: upgraded jbig2dec on :sebras/master I clustered it without regressions. | 13:18.45 |
| tor8 | sebras: "to a the"? LGTM otherwise. | 13:25.53 |
| sebras | tor8: unfortunately this doesn't fix the latest jbig2dec bug though. | 13:28.54 |
| tor8 | sebras: a couple of commits on -mini:tor/gradle | 13:34.59 |
| sebras | oh, a bytearrayoutouptstream will grow an internalbuffer? | 14:21.18 |
| tor8 | sebras: yes. "This class implements an output stream in which the data is written into a byte array. The buffer automatically grows as data is written to it." | 14:25.30 |
| sebras | what happens with title = path.substring(path.lastIndexOf('/') + 1); if the uri ends with a slash? | 14:31.01 |
| | I think you'll get IndexOutOfBoundsException in that case. | 14:31.10 |
| | and in the else you should ought to be able to assign title = key; right? | 14:31.45 |
| tor8 | well, we wouldn't be able to open a directory in any case, so that's an okay error by me :) | 14:31.49 |
| sebras | true, but maybe we should error out in a more reasonable way? | 14:32.17 |
| tor8 | sebras: or not bother setting the title that way at all | 14:32.52 |
| | it's only showed during the brief interval between starting the app and having loaded the document enough to get the real title metadata | 14:33.12 |
| sebras | that might actually be even better. | 14:33.44 |
| tor8 | path.getFileName is probably what I should be using though | 14:34.01 |
| sebras | true, also ContentResolver.openInputStream() might error out with FileNotFoundException if the uri is not found. is that ok? | 14:35.30 |
| tor8 | or rather uri.getLastPathSegment | 14:35.32 |
| | sebras: that's caught and logged with the IOException | 14:35.50 |
| sebras | even better. | 14:35.53 |
| | oh, I didn't know FileNotFoundExceptions inherits IOException. | 14:36.33 |
| tor8 | we'll probably bomb later with a null pointer exception | 14:37.37 |
| sebras | I was just about to ask about that. | 14:37.58 |
| | maybe it is better to error out and show a toast? | 14:38.08 |
| | Toast. | 14:38.11 |
| tor8 | toast? | 14:38.26 |
| | the Worker task for openDocument is going to bomb and log an error | 14:38.46 |
| sebras | yeah, that small oblong dialog message at the bottom of the screen that appears in some cases for errors. | 14:38.50 |
| tor8 | basically we'll just end up with a view that doesn't have any pages | 14:39.04 |
| | like we do for files that are completely broken | 14:39.14 |
| sebras | right. | 14:39.19 |
| | https://cdn.tutsplus.com/mobile/uploads/legacy/37_Android-Alert/Android-Alert_05.png | 14:39.58 |
| | that's a toast. | 14:40.02 |
| tor8 | I feel that's better than just dropping out of the activity | 14:40.14 |
| sebras | https://developer.android.com/reference/android/widget/Toast.html | 14:40.22 |
| tor8 | right. so that stays on the screen for a couple of seconds? | 14:40.24 |
| sebras | yes. | 14:40.28 |
| | and you can't interact with it. | 14:40.37 |
| | so it ought to be harmless. | 14:40.45 |
| | but I don't think we should show our internal error, just a message saying that we had a problem parsing the file. | 14:41.07 |
| | users probably don't care about the details. | 14:41.17 |
| tor8 | could be worth hooking that up to the worker task catch-clause | 14:41.18 |
| sebras | agreed. | 14:41.25 |
| tor8 | to run a "bomb" message on the ui thread | 14:41.42 |
| sebras | one question though, if we parse half of the file and then get an IOException, do we want to output the amount we got and then try to show that even though we know we didn't get the entire file:?" | 14:42.28 |
| | that seems similar to what we do otherwise. | 14:42.36 |
| | we _should_ log the error as you are doing right now though. that I think is important. | 14:43.23 |
| | also, would it make sense to make the Makefile in -mini and -old identical? | 14:45.09 |
| | in the gradle patch. | 14:45.45 |
| | also I switched to only using ' strings in build.gradle instead of " to avoid someone accidentally using ${} when they didn't intend to. | 14:46.50 |
| | basically I'd like for the gradle patches to be identical besides some naming and version numbers. | 14:47.12 |
| | ok, need to go out and track down some food. | 14:47.48 |
| tor8 | sebras: probably make sense to keep the Makefile and build.gradle files as similar as possible | 14:47.53 |
| sebras | not only that, also the AndroidManifest.xml and all the build stuff. | 14:48.12 |
| | it will be easier on both of us. :) | 14:48.24 |
| | as I said previously to robin, sorry for nitpicking, tell me to stop when I'm asking about irrelevant stuff. but at least I'm thorough. :) | 14:50.11 |
| | oh, and if there's something we should change in -old re: the build stuff I'm happy to do so. | 14:50.49 |
| | Forward 1 day (to 2017/05/13)>>> | |
Log of #mupdf at irc.freenode.net.
