Hi Indranil, First: thanks for doing it!
The issue with spurious scroll callbacks is something I encountered in the early stages of xournal development already, and once I got happy that do_switch_page() works properly I was careful to stick to that method of changing pages. The general issue is that, when one scrolls the canvas (as do_switch_page() does when its second argument is TRUE), this generates scroll events, which in turn can call do_switch_page() if necessary to change the active page (though, that time, the second argument is FALSE so there's no further scroll event being generated). Now, scroll events like all GTK events are processed asynchronously. So, when you are loading a new journal and creating its canvas items, the canvas changes size, zoom level, etc., and once all the new items are there, open_journal() moves the view back to the top: gtk_adjustment_set_value(gtk_layout_get_vadjustment(GTK_LAYOUT(canvas)), 0); But this generates a scroll signal (and then all the relevant updates) at a time that is rather unpredictable, and usually would be only after open_journal() has exited but could be sooner if something causes the event loop to take control again. So: I think you code near the end of open_journal() first asks the canvas to scroll to the top (the call to gtk_adjustment_set_value()) then asks for a page switch to the page you want, which updates the data structures and asks the canvas to scroll to the correct place. In a good scenario, the two scroll events get processed only after open_journal() exits, in the order they were generated, so first scroll back to the top, then scroll back to your favorite page. Each of them will involve a further call to do_switch_page() (the first one since the top of the canvas is not on the page you chose, the second one since your favorite page is not at the top), but things should end up ok. In the bad scenario, I assume what happens is that the first scroll event (to the top of the canvas) gets processed before the call to do_switch_page() you added at the end of open_journal() and, since you make do_switch_page() overwrite the preferred page number, by the time you run that do_switch_page(), if you don't save the value into load_pg it has been lost. So, in short: try deleting the line gtk_adjustment_set_value(gtk_layout_get_vadjustment(GTK_LAYOUT(canvas)), 0); and just doing the do_switch_page(). (but you might want to do it just before the autosave-restoration dialog box, i.e. putting it in the place of the gtk_adjustment_set_value(...)) so that restoring an autosave asks for whether to keep the autosave while showing the last used page?) Sorry, no time to test -- I'm busy at a conference... Best, Denis On 10/01/2014 07:49 AM, Indranil Sur wrote: > Hi Denis, Daniel, > I needed this feature badly .. so got my hands dirty .. and now I > actually have something thats working. > This is my first Open Source contribution .. infact first mail to any > list .. hope the community takes me lively .. and I must accept the > implementation is not that quiet polished. > > Firstly, instead of changing the MRU file structure, I went ahead and > created another MRU pagefile (or in the final implementation can be > individual file config.. ie serialize data like page no, exact view > coordinates etc). The rational behind creating a new file is that, this > way the program will be backward and forward compatible ... else for the > first time use of new version, users will loose MRU data .. or the > related code structure will get complicated. > > Secondly, I saw an issue while developing. I was stuck at an issue. For > some files the pages were loading properly .. while for some it wasn't. > After throwing in some custom logs I go these : > > 1. ---->open_journal > 2. new_mru_entry > 3. /home/indranil/Name_changed.__pdf.xoj > 4. ## 110 > 5. update_mru_menu > 6. !!! _do_switch_page (on_vscroll_changed) (221) > 7. !!! _do_switch_page (on_vscroll_changed) (0) > 8. !!! _do_switch_page (open_journal) (0) > > At this stage inside open_journal() at the end I am calling > do_switch_page(ui.mru[0].page, TRUE, TRUE); > > at (4) .. I got the proper last saved page number .. but before my > do_switch_page() at (8) is called we are getting scroll signals and in > the scroll callback its going first to the last page and then to the > first page (without any scroll) (happening 20% of the time) ... now as > ui.mru[0].page is also updated inside do_switch_page() to > capture any other page change .. so we are losing the page number. > > I have temporarily fixed the page loading in my patch by using a global > variable just in this case... but I think there is some issue with the > scroll callback .. or we are getting spurious scroll signals. Note: I > used the github's master code for this test on latest ubuntu... maybe > this will not be noticed in the sourceforge's code. > > > Please check and try the attached patch(on latest sourceforge's code) > and lemme know. Denis it really bugs if each time we need to go to the > page number .. so it will be a good feature. Further we can put a config > to enable and disable the feature. > > Regards, > Indranil > > On Mon, Sep 29, 2014 at 3:09 PM, Indranil Sur <indrafor...@gmail.com > <mailto:indrafor...@gmail.com>> wrote: > > Hi Daniel, > > I am not sure that inside the xoj file is a particularly logical place > to save a current page number. > For one, it causes files with identical contents to become different and > change for no reason (not ideal e.g. for people who sync files between > locations or to the cloud). It is also not particularly logical, if you > e-mail me a xoj file in which you last looked at page 5, that it should > open on page 5 for me as well. > > A more logical location might be in the mru file > (.xournal/recent-files). Since that one is local to an installation of > xournal (more or less), it is fairly harmless to extend its format > (plus, the current xournal doesn't read past 8 lines of the file). > See init_mru(), new_mru_entry(), save_mru_list() in xo-file.c (I can't > understand for the life of me why the reading of the MRU file is done > with g_io_... instead of plain g_fopen() etc., perhaps I was feeling in > a mood to explore glib features). > > It would be logical to simply store in the MRU list, along with the file > name, the page number on which it was last opened (in memory, extend the > MRU data structure to have not just a menu item widget and a file name > but also a page number; in the MRU file, up to you how to do it, perhaps > append :1 (or :pagenumber) at the end of each file name in the list > stored on disk?) -- and if we want to keep page numbers for more than > the last 8 files, increase the length of the list in memory and in the > MRU file but not in the menus. Then add to the file-open function a > feature to look up the file name in the MRU list and see if we have a > preferred page number for it. > > Does this make sense? > > Best, > Denis > > > On 09/07/2014 01:07 AM, D M German wrote: > > > > hi Denis, > > > > what do you think about saving in the xoj file, the current page? > > > > If you agree with it, how would like it implemented? I can do the work. > > > > --daniel > > > > -- > > Daniel M. German "Never underestimate the bandwidth > > of a station wagon full of > > Andrew S. Tanenbaum -> tapes hurtling down the highway." > >http://turingmachine.org/ > >http://silvernegative.com/ > > dmg (at) uvic (dot) ca > > replace (at) with @ and (dot) with . > > > > > > > > > ------------------------------------------------------------------------------ > > Slashdot TV. > > Video for Nerds. Stuff that matters. > >http://tv.slashdot.org/ > > _______________________________________________ > > Xournal-devel mailing list > > Xournal-devel@... > >https://lists.sourceforge.net/lists/listinfo/xournal-devel > > > > -- > Denis Auroux > UC Berkeley, Department of Mathematics auroux@... > > Institut Henri Poincare, Paris auroux@... > > -- Denis Auroux UC Berkeley, Department of Mathematics aur...@math.berkeley.edu Institut Henri Poincare, Paris aur...@ihp.fr ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
