[sugar] Clipboard errata (patches)
Fri Oct 17 13:06:43 EDT 2008
On Fri, Oct 17, 2008 at 12:48 PM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
> On Fri, Oct 17, 2008 at 6:11 PM, Eben Eliason <eben.eliason at gmail.com> 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.
>> - 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?
> [PATCH] Title clippings appropriately eg. "Text clipping" (#5751)
> OK, you may want to add a TRANS comment with a hint to translators.
> [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?
> [PATCH] Highlight clipboard on drag (#8604)
> [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.
More information about the Sugar-devel