[sugar] Clipboard errata (patches)

[Tomeu Vizoso]

On Fri, Oct 17, 2008 at 7:06 PM, Eben Eliason <eben.eliason at gmail.com> wrote:
> 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.
>>>
>>> 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