Hi Daniel,
Thanks for the work on saving pages in the MRU! I don't have time to
review the patch carefully at the moment, but at least I've downloaded
and played with it and it seems to do the right thing.
[metadata use for saving last page]
> Denis, if you use Linux, I think you will like it. It is basically the
> logic we discussed (saving the last page accessed) without altering the
> xournal file. One thing we could do is to add a flag so this is saved
> only when the user wants it (and none by default).
At the moment I'm still a bit unhappy with the concept of gvfs metadata
that gets magically stored in a completely obscure location and format
-- I find a lot of the gvfs magic rather evil -- but if the GIO API
hides the backend mechanism and works seamlessly on systems that don't
have gvfs then I guess I'll eventually be able to live with it -- just
need some time to adjust to the idea.
However: presumably we don't need to store page numbers both in the MRU
file and in gvfs metadata? Presumably we should choose one -- windows
compatibility seems to suggest the MRU file is better, though
multi-instance issues suggest the gvfs metadata is better if we don't
want to handle conflicts between multiple instances of xournal keeping
their own MRU lists?
> But there is one message that i get every time I open a xournal that has
> annotations and I want to jump to a different page (see attachment):
> "Save this version and delete auto-save?" But I have autosave enabled,
> so I still dont' know where this message comes from.
I don't get this message when testing your branch, but I did get it
briefly for one particular file that I had been editing a couple of
weeks ago, and then it went away after a few times of getting this
message. This was with the "normal" version of xournal. So there's
perhaps a bug somewhere that only happens sporadically and perhaps got
triggered independently of your changes to the code (or maybe was made
more likely to happen by them?)
If you have a file for which this currently happens for you, you have a
good occasion to debug things. The message you see is triggered when, at
the end of open_file(), filename_actual is different from filename.
filename_actual is set up at the beginning of open_file() as the return
value of
filename_actual = check_for_autosave(filename);
That function returns g_strdup(filename) unless there are autosaves and
the user after being prompted elects to restore an autosave. So the user
should see another dialog box first and would have to actively select
the "Restore auto-save" option in it for filename_actual to be different
from filename at that point.
As far as I can tell, the code in open_journa() never changes the value
of filename or filename_actual after that point (I just double-checked
-- I don't think we leak any pointers to these local variables into any
of the journal data structures [otherwise we'd get a crash fairly soon?]
and I don't see any place where they get modified). So I thought it was
safe once the new journal is loaded to test
if (strcmp(filename, filename_actual)) { // we just restored an autosave
...
}
and prompt "Save this version and delete auto-save?" in that case (to
see if the user is happy with the auto-save that was just restored).
What seems to happen is that, at that point, filename and
filename_actual don't look identical to strcmp, even though I don't
understand why or how they would differ.
The 'exceptional' cases where one calls open_journal() on a PDF file
instead of a xoj file (and we call the PDF loader instead, or
ui.autoload_pdf_xoj is on and we end up loading something.pdf.xoj
instead of something.pdf) are handled by separate pathways and do not
get to the point where that dialog arises, so that's not the problem
either. So I'm stumped.
If you can put some breakpoints in open_journal() (or just add some
printf's) and see what the contents of filename and filename_actual are
at the beginning (when the value of filename_actual is first set) and at
the end (when they're compared to decide if we should bring up the
dialog box you get), that might shed some light on what's happening.
(I'd gladly do that myself, but I can't reproduce the bug...)
Best,
Denis
--
Denis Auroux
UC Berkeley, Department of Mathematics aur...@math.berkeley.edu
Institut Henri Poincare, Paris aur...@ihp.fr
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Xournal-devel mailing list
Xournal-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xournal-devel
