#5760 HIGH Update.: Objects accumulate on the clipboard, impacting system performance.

[Zarro Boogs per Child]

#5760: Objects accumulate on the clipboard, impacting system performance.
------------------------+---------------------------------------------------
  Reporter:  legutierr  |       Owner:  tomeu    
      Type:  defect     |      Status:  new      
  Priority:  high       |   Milestone:  Update.1 
 Component:  sugar      |     Version:  Build 650
Resolution:             |    Keywords:  review-  
  Verified:  0          |    Blocking:           
 Blockedby:             |  
------------------------+---------------------------------------------------

Comment(by marco):

 Replying to [comment:9 tomeu]:
 > One reason is that only the UI can now the number of elements we want to
 show. As you said, the UI can pass that info to the service, but I find
 that as adding complexity where it is not needed.

 Maybe it's just me, but I feel really weird that the UI should take care
 of deleting items from the clipboard when the limit is exceeded. It feels
 a lot cleaner to just have the service refuse new items when the clipboard
 is full. Would it really add a lot of complexity?

 You mention nand space below... Would we create a file on nand and then
 delete it, if we exceed the UI limit?

 > One bigger reason (but related) is that, although we currently lack a
 way of reordering items in the clipboard,  it has been specified since the
 beginning (and see #5755), so when we implement it, we should move the
 limit back to the UI or move the ordering of items in the frame to the
 service (bad design, in my opinion).

 I'm not sure to understand how this relates to the limit.

 > In summary, I think we should have a limit based on UI considerations in
 the shell, and another in the service based on the maximum amount of
 memory and temp nand space that we want to dedicate to clippings.

 I think it would be simpler to have a single limit in the service, based
 on hardware limitations *and* an hint from the UI.

 In the end you maintain the clipboard code so this is up to you.

 Regardless, I don't think we should use allocation to determine the limit.
 Calling get_allocation arbitrarily is always racy. And by Eben spec
 MAX_SIZE is independent from the actual widget size. We can probably do
 something like screen_height / grid_cell_size - 2.

-- 
Ticket URL: <http://dev.laptop.org/ticket/5760#comment:10>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system