From: Benny M. <ben...@gm...> - 2010-03-07 20:19:11
|
2010/3/6 Doug Blank <dou...@gm...>: > On Sat, Mar 6, 2010 at 10:59 AM, Nick Hall <nic...@ho...> wrote: >> Benny, >> >> Do you really want to make the FanChartView stable? > > That was me that said that. > >> I get slow response times from it, and there is no busy indicator or >> progress bar. I also get about a 3 second delay before the popup >> appears after a right button mouse click. >> >> I wasn't expecting this to be available to normal users. > > I don't see that delay at all. Doug, if I do the following patch: Index: src/plugins/view/fanchartview.py =================================================================== --- src/plugins/view/fanchartview.py (revision 14674) +++ src/plugins/view/fanchartview.py (working copy) @@ -558,6 +558,7 @@ text, person, parents, child = self.data[generation][selected] if person and self.context_popup_callback: self.context_popup_callback(widget, event, person.handle) + return True self.queue_draw() return True Then the delay to show the popup goes away. Can you verify this has no side effects? You need to be on a big fan chart to have a long delay. Note that then queue_draw is only for change_slice I think, so it might be better to move this queue_draw to that method, to avoid regressions in the future. As mouse_up does a queue_draw, I'm not even sure it is needed here... Anyway, would be nice if you could add this in branch32 To open the submenu's still has quite some delay though, but that will be a Gtk issues, as that does not trigger code (it might trigger gtk.Widget code, but that would be Gtk doing things it should not do. Due to the fact the fanchart is one big widget, you can see that painting the widget once is slow, eg open a window over the fanchart, then move the window out of view, the fanchart in my case has no text, and I hear the CPU whirring to redraw the fanchart again Some other things about fanchart we need to remedy in trunk when time: * connect to signals to update on eg delete of a person visible. So the same code as pedigreeview to connect to db signals * Use self.dirty to not redraw if nothing changed. So build_tree should only call main if dirty. * Use busy cursor while working in main/build_tree Benny > > -Doug > >> Regards, >> >> >> Nick. >> >> >> Benny Malengier wrote: >>> 2010/3/6 jerome <rom...@ya...>: >>> >>>> yes a little bit annoying but just a visual issue, before a new beta, maybe to fix the load/diplay problem on 'Ancestry' category ! >>>> >>>> Gramps-3.2beta1 provides only one view on 'Ancestry' category (the PedigreeView). >>>> >>>> FanChartView is ignored and I cannot load any addons for this category :( >>>> >>> >>> If you look in the gpr.py file, you see that the status is UNSTABLE, >>> so it will not load for users. >>> I'll change it to STABLE. >>> Some plugins on the addons may also be unstable. It is up to the >>> plugin writer to decide if the plugin should be exposed to normal >>> users. It would be best to update the wiki page on addons, so that >>> unstable plugins are not in the main section, and it is made clear to >>> users they must run the _development_ version to see the plugin and >>> use it. >>> >>> Benny >>> >>> >>>> --- En date de : Sam 6.3.10, Benny Malengier <ben...@gm...> a écrit : >>>> >>>> >>>>> De: Benny Malengier <ben...@gm...> >>>>> Objet: Re: [Gramps-devel] Gramps 3.2.0-0beta1 >>>>> À: "Stéphane Charette" <ste...@gm...> >>>>> Cc: "gramps-devel" <gra...@li...> >>>>> Date: Samedi 6 mars 2010, 0h21 >>>>> 2010/3/6 Stéphane Charette <ste...@gm...>: >>>>> >>>>>>> It seems that it is a Makefile error, Jerome fixed >>>>>>> >>>>> it. You will want >>>>> >>>>>>> to patch the beta with it for distribution >>>>>>> >>>>>> This warrants a beta2, no? I can make time this >>>>>> >>>>> weekend to put it together >>>>> >>>>>> if we want it. >>>>>> >>>>> It sure is annoying. If you have time, an updated beta for >>>>> this would >>>>> be nice. Gramps is working however, so people can still >>>>> test with this >>>>> beta. >>>>> >>>>> Benny >>>>> >>>>> >>>>>> Also: James, I *really* could use the debian files >>>>>> >>>>> (control, rules, ...?) >>>>> >>>>>> you use to create the package. The ones I use in our >>>>>> >>>>> svn repository are >>>>> >>>>>> quite out-of-date. I think a while back you talked >>>>>> >>>>> about fixing up some of >>>>> >>>>>> the requirements, but I don't know if our repository >>>>>> >>>>> was updated. >>>>> >>>>>> Stéphane >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Download Intel® Parallel Studio Eval >>>>> Try the new software tools for yourself. Speed compiling, >>>>> find bugs >>>>> proactively, and fine-tune applications for parallel >>>>> performance. >>>>> See why Intel Parallel Studio got high marks during beta. >>>>> http://p.sf.net/sfu/intel-sw-dev >>>>> _______________________________________________ >>>>> Gramps-devel mailing list >>>>> Gra...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>> >>>>> >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > |