| | <<<Back 1 day (to 2021/01/11) | Fwd 1 day (to 2021/01/13)>>> | 20210112 |
| artifexirc-bot | <ator> @sebras um, I forgot which of my bug fixes for 703211 are good... | 14:38.59 |
| | <ator> the one on tor/master or the set of three on bug-703211 | 14:40.19 |
| | <Robin_Watts> @ator You were going to look into the mupdf-gl UI for undo/redo. Any progress with that? | 14:58.50 |
| | <ator> @Robin_Watts afraid not, no progress yet | 15:07.03 |
| | <ator> @Robin_Watts there is one UI problem I'd like to discuss regarding undo though | 15:07.51 |
| | <Robin_Watts> Then can we try to avoid the rest of the commits going in being blocked by that? Either we can rebase the UI to the end (bad, cos it means we have nothing testing it), or we can put the UI in as it is now, and then improve it later. | 15:08.04 |
| | <Robin_Watts> Sure. go for it. | 15:08.08 |
| | <ator> it's customary to jump to the page/location where the edit that is undone/redone happened | 15:08.11 |
| | <Robin_Watts> Ah, ok. That's not possible currently, because we have no clue which pages are affected by a given change. | 15:08.50 |
| | <ator> could we add a callback to pdf_enable_journal that records some sort of cookie crumb trail (just an integer or blob of data) | 15:08.54 |
| | <ator> that gets returned from pdf_undo/redo | 15:09.00 |
| | <ator> the begin_operation stuff would call the callback, record the page number | 15:09.17 |
| | <Robin_Watts> and in the case of document metadata, it may not be any particular page. or even multiple pages. | 15:09.25 |
| | <Robin_Watts> begin_operation may not know the page. | 15:09.35 |
| | <ator> no, but it could call the callback the UI registered | 15:09.44 |
| | <ator> and the UI would hand it some opaque blob of data to associate with the operation | 15:09.55 |
| | <ator> this could be the page number or scroll position | 15:10.05 |
| | <Robin_Watts> Let me ponder on that for a bit. | 15:10.22 |
| | <ator> and then the UI could get it back when going to a certain history state | 15:10.31 |
| | <ator> give it a think anyway | 15:10.41 |
| | <ator> huh, something happened when I was playing with the history list and it dropped the 'future' | 15:11.47 |
| | <ator> if I create an annotation in mupdf-gl | 15:12.35 |
| | <ator> then go back to the "Set modification date" or "Create Annotation" operation, the ones after disappear | 15:13.37 |
| | <ator> if I go to a place before the "create annotation" they remain | 15:13.59 |
| | <Robin_Watts> If you undo, then any changes to the document lose all the changes after that point. | 15:20.49 |
| | <Robin_Watts> so undo then redo is fine, but undo the edit, loses the ability to redo. | 15:21.08 |
| | <ator> I don't do any changes though. I just click the annotation. | 15:21.09 |
| | <ator> and the redo option disappears | 15:21.17 |
| | <Robin_Watts> Urgh. Something is probably setting something in the document to the same value or something? | 15:21.45 |
| | <ator> click the *undo button* | 15:21.47 |
| | <ator> is this gated on the local_xref stuff maybe? | 15:22.02 |
| | <Robin_Watts> It shouldn't be. I have everything in bits at the moment. I'll look when I get it back together. | 15:22.24 |
| | <Robin_Watts> Can you open a bug with the document, and exact steps please? | 15:22.40 |
| | <ator> yeah. if I take the local_xref commits as well, this problem doesn't appear | 15:22.53 |
| | <ator> I think the appearance synthesis botches the redo | 15:23.02 |
| | <Robin_Watts> Ah! Yes. | 15:23.06 |
| | <Robin_Watts> Sorry, that makes sense, yes. | 15:23.13 |
| | <ator> because I go to a step between creating the annot and then synthesizing the appearance | 15:23.36 |
| | <Robin_Watts> In the latest code synthesising doesn't alter the document, hence nothing goes into undo/redo. | 15:24.39 |
| | <sebras> @ator IIRC we found other peculiarities in the code while looking at this a few weeks back. I think you might have checked in all those under the same Bug703211 heading. if you diff the first commit in the set of three with the one on tor/master you'll see that the latter only adds two if-statements. I'm suspecting that what we want is the union of the two. but I need to understand the details to say for sure. | 15:43.50 |
| | <sebras> @cgdae is 'x' to fopen() portable to macOS? it looks like a glibc extension for O_EXCL..? | 15:49.29 |
| | <Robin_Watts> Indeed. | 15:50.20 |
| | <cgdae> It's not just glibc, e.g. openbsd has it. but it's entirely possible that it's not everywhere, in which case could we put it inside an #ifdef ? | 15:55.05 |
| | <cgdae> (Not actually sure about whether fopen() skips unrecognised chars - would be useful if it did.) | 15:55.44 |
| | <cgdae> 'x' is vaguely official - e.g. see: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1339.pdf | 15:56.09 |
| | <ator> @cgdae any reasonable implementation does -- like the "b" flag for binary on windows | 15:56.34 |
| | <Robin_Watts> Woo Hoo! I have snapshot saving working. | 19:04.06 |
| | <Robin_Watts> I can load a form, fill it in, undo some of it, and snapshot it. | 19:04.34 |
| | <Robin_Watts> Mupdf-gl then reloads the snapshot, and the original document is loaded, with my modifications, and undo/redo history with the history at the same point. | 19:05.15 |
| | <Robin_Watts> This is intended for @paulgardiner and @fredrossperry to use for 'backgrounding' the app. | 19:08.55 |
| | <Fred> Excellent! | 19:09.31 |
| | <<<Back 1 day (to 2021/01/11) | Forward 1 day (to 2021/01/13)>>> | |
Log of #mupdf at irc.freenode.net.