On Mon, Feb 04, 2013 at 01:01:48PM +0000, Andrew Chadwick wrote: > On 3 February 2013 08:55, Martin Renold <[email protected]> wrote: > > But my bigger concern is that it disrupts existing patches and experimental > > branches, making it probably much harder to quickly bring them up-to-date > > and test with the current code. It also makes it harder to investigate file > > history. Git can track moves, but you always have to be explicit about it, > > and suspicious about whether it has actually worked. > > Fair enough. Although of course it doesn't track moves or file > identities, being a content tracker (as I understand it).
That's what it claims in the docu. It maybe just marketing ;-) > Experimentally doing the move in a private branch shows content > similarities of >97%, typically 99-100%. File history (as exposed via > git blame, anyway) is just fine. > > The big loss would be to the validity of non-git patches out there, > and I don't think the gained neatness outweighs that yet. Losing non-git patches would be no issue at all for me. But I haven't been so lucky with my experiments. I tried again now, and indeed, in some cases it just works as if it were nothing! Great news. But in my first test it didn't work at all. What I have tried is to apply the "debug-gtk-pressure" branch from my "maxy-experimental" repository, which just adds a few prints. It's a branch with a single commit in it. If you apply it to master, you get two conflicts, edit the markers in gui/canvasevent.py and you are done. When you first move the "gui" directory in master, then no matter if you use "git merge" or "git cherry-pick", you get a "modify/delete" conflict. Git just claims that the file doesn't exist any more - no conflict markers, no hint what has really changed. On the plus side, I noticed that "git annotate" just works - even without the "-C" flag, to my surprise. Maybe there I just picked an unlucky example. But if anyone knows some git trickery to make this one apply, I would be glad to learn it - I think it I would have had use for it elsewhere already. > I think the idea was to avoid having to load subwindow modules for > windows which are not initially open, to reduce startup times. Ah... I didn't think of that. My guess would have been that the importing of a module takes almost no time compared to the GTK initialization of windows and widgets, but maybe I'm wrong. I don't remember who introduced this way of importing window modules. If it was me, it was probably just to minimize how often you need to list all subwindow names. (Import statements would have been one of those lists). > If this isn't considered valuable any more, we could have them registered > and unregistered as you say, which would probably be better for subwindows > belonging to loadable/unloadable plugins (which moves the decision of > whether or not to load additional code elsewhere, and somewhere the user > can control if we do it right). I don't have a strong oppinion about that really, either way. > >> One thing that's come up before when doing this is the security/safety of > >> importing the modules based on a string name: this would allow simpler > >> whitelisting. > > > > What kind of security/safety are you talking about here? What is the problem > > that would be solved? > > That introduced by b8c72b0e, which was really a stability fix by the > looks of it. It uses a whitelist to ensure that named windows in the > user's config actually exist in the current MyPaint. Ah yes, with an old config file we were trying to import window modules that didn't exist any more. This wasn't very robust design. The commit was just to ensure this particular problem never hits again - it would be great to address the underlying code design problem instead, of course. > A better solution is probably something along the lines of the little > plugin API sketched out at > > https://lkubuntu.wordpress.com/2012/10/02/writing-a-python-plugin-api/ > > extended as necessary for load/unload methods, pretty icons etc. It > uses the standard imp module to restrict the load to one or more > specific locations rather than the entirety of sys.path. That's good stuff. I didn't know about the imp module. -- Martin Renold _______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
