On Fri, Oct 17, 2008 at 7:06 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > On Fri, Oct 17, 2008 at 12:48 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >> On Fri, Oct 17, 2008 at 6:11 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: >>> This is a set of patches I worked on recently, and need to rebase on >>> the latest jhbuild before I post them officially. I wanted to expose >>> them for comments before I put in that effort, since there are no >>> doubt other things that will need to be changed upon review. >>> >>> Thanks! >>> >>> - Eben >>> >>> PS. I just noticed upon attaching that the first isn't actually a >>> clipboard patch, but it was part of a sprint on clipboard and >>> drag'n'drop in general, so I include it. >> >> [PATCH] Lock cursor to center of icons in favorites view on drag (#7408) >> >> Looks good, you can as well calculate again the hot point from the >> pixbuf in the context, instead of adding two private members more to >> the class. > > Oh really? I didn't see a way to pull that back out. Could you give > me a pointer?
You are right, I expected that gtk.DragContext would have an accesor as well as a setter. >> [PATCH] Add descriptions to clippings (#5751) >> >> Not sure if we should do the formatting in model/clipboardobject.py, >> that looks to me more like a presentation issue so should live in the >> view classes? > > I debated this back and forth. My decision to put it in the model > meant that we could simple return a description easily in the correct > format given the clipping type. Otherwise, the view needs to special > case based on the type of the clipping. It seemed to me (ignoring the > details of implementation) that I really just wanted "description" to > be "just a string" in the model, which the view could call up at any > point. From this perspective, it's natural for the model to return an > appropriate string, and for the view to color, size, position, etc. > that string as it wants, right? I'm ok with the concept of a single-line description of a clipping living in the model, but the _MAX_DESCRIPTION_LENGTH value seems to me like a UI decision. What about moving it to be an argument of get_description()? + if key == 'STRING': I'm not sure all text clippings will have the STRING target, I would do instead: + if key in ['STRING', 'text/plain', ...]: (I'm not really sure which are the most common targets that contain text, I would check the logs after a paste, these are printed in there). >> [PATCH] Prevent duplicate clippings on drag within clipboard (#8606) >> >> Sounds good as a temporary measure, but I think that Gtk+ has support >> in its trays for reordering elements with DnD. Or it may be some >> extension to gtk+? Worth investigating. > > Yes, that's the long term solution. I just wanted something to clean > up the behavior to prevent confusion in the meantime. There is a TODO > somewhere in there where I mention we should be rearranging instead, I > think. It might be the case that doing it right makes the rest of > this patch obsolete, but I'm not sure. Sure, I think that your solution is very good in the meantime. Thanks, Tomeu _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
