On Tue, Jul 21, 2009 at 4:32 AM, Tomeu Vizoso<to...@sugarlabs.org> wrote: > On Tue, Jul 21, 2009 at 09:07, Albert Cahalan<acaha...@gmail.com> wrote:
>> Last I checked, the Journal interface... >> >> a. required piles of custom D-BUS code (very painful to do) > > This hasn't been a problem for other developers. Yes it has been. A few (?) developers succeeded. Everything else is a Python script. I'm only aware of Etoys in fact. Any others? Really, I don't see why there isn't a *.so file supplied in /usr/lib that could be used via dlopen(). >> c. would make the kid-friendly picture browser impossible > > How so? OK, here is what I need: Tux Paint gets a list of all Tux Paint images. For each one, it opens the thumbnail. It displays **all** thumbnails for the user, as large buttons in a scrollable grid. If a thumbnail does not exist, Tux Paint will open the main file and create a new thumbnail. The user may choose to delete an image. Tux Paint does so. The user may load an image. Tux Paint then must deal with the previously loaded image. It may be saved over an old copy, saved as a new copy, or thrown away. After doing so, the requested image gets loaded. (BTW, that choice is also offered elsewhere in the UI. It's given when the user hits the "New" button to get a fresh start. It's given when Tux Paint exits.) There is also a slideshow feature. The kid selects images from the visual selector, then hits the "Play" button. This isn't going to work at all with selection via the journal. Not that this works now, but on the laptops with both Sugar and GNOME there should be exactly one Tux Paint sandbox. Images shouldn't be held hostage in one environment. >> d. would cause performance-sucking data copies > > Doesn't seem to be a problem for Paint, in which way is TuxPaint more > exigent performance-wise? There is a visual file selector, so numerous images may need to be loaded. Giving this up would have a usability impact. Stopping and restarting Tux Paint in order to load a new file would be painful. Despite optimization effort, Tux Paint will never be fast-starting. (OK, it beats many Python things, but we still get bothered by the start-up delay) The built-in file selector can be somewhat fast; it does not need to load up all the fonts and sounds again. > If you are able to name drawings in the TuxPaint's sandbox, > then you are also able to do so in the journal entries. In the normal sandbox, there is little need for names. One of the nice things about a paint program is that large thumbnails do a pretty good job. We use 232x152 for a normal 1200x900; perhaps we'd like to increase that for the XO. Is there some way for the journal to deliver this? 320x240 could be nice. _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel