#8748 NORM 8.2.1: Sugar cannot upload images from the Journal to TRAC

[Zarro Boogs per Child]

#8748: Sugar cannot upload images from the Journal to TRAC
-----------------------+----------------------------------------------------
   Reporter:  gnu      |       Owner:  tomeu                            
       Type:  defect   |      Status:  new                              
   Priority:  normal   |   Milestone:  8.2.1                            
  Component:  sugar    |     Version:  Development build as of this date
 Resolution:           |    Keywords:  8.2.1:?                          
Next_action:  package  |    Verified:  0                                
  Blockedby:  1053     |    Blocking:                                   
-----------------------+----------------------------------------------------
Changes (by Eben):

  * keywords:  => 8.2.1:?
  * owner:  Eben => tomeu
  * component:  interface-design => sugar
  * milestone:  Not Triaged => 8.2.1


Comment:

 Replying to [ticket:8748 gnu]:
 > I was reporting #8747 from a real computer, and decided to try to upload
 the faulty screen image from my XO.

 This should defiinitely be possible; I believe many screenshots have
 beennn attached to tickets this way.

 > I could click in the File text input box, and type, but I could not
 Paste into it.  I tried Ctrl-V.  I tried Shift-Ctrl-V.  Nothing happened.
 I tried bringing up the Frame and dragging the icon into the text box.
 That replaced the whole page (with an error page saying it couldn't access
 that file).  I tried clicking the Browse  (local filesystem) button.  Of
 course you can't Browse in a laptop that doesn't have a file browser or a
 file open dialogue.  Of course it didn't bring up the Journal.  It didn't
 do anything.

 I confirmed that you can't paste into the feild.  However, this is not a
 Sugar bug. That field doesn't accept manual entry either, and instead only
 serves to display the filename chosen with the browse button. It shouldn't
 be an entry, really. I tried pasting the URL into the description field,
 which worked fine by ctrl-V, the paste button in the toolbar, ''and''
 drag'n'drop (example:
 file:///home/olpc/isolation/1/uid_to_instance_dir/10011/c902676a-9e93
 -48fe-880d-620c62fb8860.png)

 The Browse button is another story. Though there isn't a hierarchical
 browser, as you state, that doesn't mean there is no way to choose files.
 We have an object chooser very much like the Journal for this purpose.
 After playing a bit, I discovered the problem, which is that the chooser
 appeared not within the window that invoked it, but instead within the
 most recent browse instace (in this case, the one with the image shown in
 it).  Moreover, since that dialog wasn't modal in the instance I invoked
 it from, it allowed me to spawn 20+ chooser windows, which I had to close
 individually.

 In the end, choosing a file in the ''other'' window did correctly enter
 the flename into the entry field on the ticket.  After this comment, I
 will attempt that again and complete the upload for confirmation that it
 works.

 In any case, this bug is somewhat serious, as it breaks our activity
 model, and will prevent many from uploading to various places, including
 our bug tracker. I propose that this needs a fix for 8.2.1 if possible.



 > The file name involved was a long, long, long name saying something
 about /isolation and a long random name ending in .jpg  I was not about to
 try copying it out on paper and then switching web pages and then try
 typing it in from paper.  For all I know, Browse is not *permitted* to
 access this file in the Journal, because it was created by a different
 "Activity" running under a different UID.
 >
 > It is long overdue for OLPC to throw out the whole Journal/Datastore
 paradigm -- and the crappy nonfunctional Sugarized software -- and replace
 it with the workhorse software that runs on every other Linux system.  The
 software every XO developer uses to get their work done, every day.
 >
 > But hey, as long as the majority of XO users have no real filesystem or
 browser, and have no real computer accessible to them, they sure won't
 report very many bugs...which makes the Sugar developers' life much
 easier.  And when nobody can develop on the machine, not because the
 machine or the kids are incapable, but because the UI doesn't allow it and
 the paradigm doesn't ever teach them about hierarchical filesystems, there
 isn't all the hassle of integrating patch contributions from hundreds of
 thousands of kids.

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