Erik Blankinship | 1 Mar 01:02 2008

filtering result of an object chooser

Is there a way to filter the mime types of the objects presented with an object chooser (e.g., only png)?  Here is some sample code I am using:

import gtk
import shutil
from sugar.graphics.objectchooser import ObjectChooser

class FilePicker:

    def __init__(self):
        pass

    def show(self):
        title = None
        parent = None
        file = None
        chooser = ObjectChooser(title, parent, gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT)
        try:
            result = chooser.run()
            if result == gtk.RESPONSE_ACCEPT:
                jobject = chooser.get_selected_object()
                if jobject and jobject.file_path:
                    ext = os.path.splitext(jobject.file_path)[1]
                    f, new_temp = tempfile.mkstemp(ext)
                    del f

                    global _temp_files_to_clean
                    _temp_files_to_clean.append(new_temp)
                    shutil.copy(jobject.file_path, new_temp)

                    file = new_temp
        finally:
            chooser.destroy()
            del chooser

        return file

_______________________________________________
Sugar mailing list
Sugar <at> lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Marco Pesenti Gritti | 1 Mar 02:48 2008
Picon

Re: frame redesign

On Fri, Feb 29, 2008 at 4:59 AM, Tomeu Vizoso <tomeu <at> tomeuvizoso.net> wrote:
> Hi Marco,
>
>  have started moving the items in the frame around as Eben defined.
>
>  Can you give it a look and tell me what you think?
>
>  http://dev.laptop.org/git?p=users/tomeu/sugar;a=summary
>
>  First commit is "ClipboardBox to ClipboardTray. Make it a VTray
>  instead of hippo.CanvasBox.".

Hello,

here are some notes which I put together this morning on the train.
Traveling tomorrow, it will probably take a couple of days for me to
follow back, be patient :)

f8377e2c1a3db420cd00b0ca8f33f46a4314efd4

+        return True;

Patch looks fine. Please fix the ; above while you are changing that code.

3a608219960657a4b3d087306affb9b08ebe1c14

OK.

d7336f7358eba894616f47e32d8061bad6a3e4f0

Talked with Eben. The zoom buttons should actually stay in a toolbar. The
activity icons should be in a separate Tray, on the right of the zoom toolbar.
That way if activities scroll, the zoom buttons stays in screen.

0ad5327f664e49ce7e32fee4deb307165c5e7732

+        if new_level == ShellModel.ZOOM_MESH:
+            self._mesh_button.props.active = True
+        elif new_level == ShellModel.ZOOM_FRIENDS:
+            self._groups_button.props.active = True
+        elif new_level == ShellModel.ZOOM_HOME:
+            self._home_button.props.active = True
+        elif new_level == ShellModel.ZOOM_ACTIVITY:
+            self._activity_button.props.active = True

I think we should start using the new style gobject properties in new code.

There will be conflicts with the Tray vs Toolbar thing in the previous one.

af16fc5b4c2b15bee68656867355883146f07030
d61258768b33d8bb646c6bdf159ad46bc9059f19

What problems do you have there? I'll just note that sometimes it's easier
to use toggle buttons then radio, not sure if this is the case.

f0689cc5bde7235ce73be14414a2648070215959

        activitiestray.py               \
+       activitiestray2.py              \

I suppose the 2 is temporary. Any reason to do this? The rename will mess up
the history. Hmm, I guess I'm confused by this one, You are modifying both
versions of the tray and I'm not sure which one we are going to use...

3677745a10fbc7481fa1da02bd7b4c63e28d0deb

+        if home_activity.props.launching:
+            palette = Palette(_('Starting...'))
+            palette.props.invoker = FrameWidgetInvoker(self)
+            palette.set_group_id('frame')
+            self.set_palette(palette)
+
+            #self._start_pulsing()
+            home_activity.connect('notify::launching',
self._launching_changed_cb)
+        else:
+            self._setup_palette()

Maybe it would be cleaner to have the launching case inside _setup_palette too?

1c2ce9f1c374e85b3174a6a8868cb6fad15cb715

-        self.props.icon_name = name
+        self.get_icon().props.icon_name = name

Can we fix the toolkit and make this:

self.icon.props.icon_name = name

(should get even more convenient if we start using the new style gobject props).

+        view = deviceview.create(device)
+        self.pack_end(view, expand=False, fill=False, padding=0)

I'd rather pack_end the container then each widget, if that works as well.

+        """
         activities_tray = activitiestray2.ActivitiesTray(self._shell)
         panel.append(hippo.CanvasWidget(widget=activities_tray),
hippo.PACK_EXPAND)
+        """

Please remove this.

Thanks,
Marco
Benjamin M. Schwartz | 1 Mar 06:44 2008
Picon

Journal Object metadata


I have read all the documents I could find, and also the Sugar source, and
I am still confused:

How can an activity get an object representing all the metadata for its
current datastore object?

I ask because I am writing a trivial "Distribute" Activity, whose purpose
is to copy journal entries from one XO to another by sharing.  This is
working, but since the copy does not have any metadata, like MIME type, it
cannot be opened from the Journal interface by any Activity except
Distribute, which created it.

Ideally, I would like to acquire the metadata as a dbus object, so that I
may simply shove it over a DBus Tube and then pass it on to the receiver's
datastore.

--Ben
Bert Freudenberg | 1 Mar 13:12 2008
Picon

Re: Journal Object metadata

On Mar 1, 2008, at 6:44 , Benjamin M. Schwartz wrote:

> I have read all the documents I could find, and also the Sugar  
> source, and
> I am still confused:
>
> How can an activity get an object representing all the metadata for  
> its
> current datastore object?
>
> I ask because I am writing a trivial "Distribute" Activity, whose  
> purpose
> is to copy journal entries from one XO to another by sharing.  This is
> working, but since the copy does not have any metadata, like MIME  
> type, it
> cannot be opened from the Journal interface by any Activity except
> Distribute, which created it.
>
> Ideally, I would like to acquire the metadata as a dbus object, so  
> that I
> may simply shove it over a DBus Tube and then pass it on to the  
> receiver's
> datastore.

I'm not entirely sure what you are asking. All meta data for a  
datastore object is retrieved by the get_properties(object_id) call,  
the associated file (if any) by get_filename(object_id). This is  
documented at

	http://wiki.laptop.org/go/Low-level_Activity_API#Datastore

Anyway, get_properties() returns a DBus dictionary with all the  
metadata, that should be trivial to send on via a DBus tube.

There is no such thing as an activity's "current datastore object",  
at least as far as Sugar is concerned. Each activity holds onto its  
own current object_id, it's up to the activity how to do that. Your  
activity would presumably open one or more datastore entries, without  
it becoming its "current" object, right?

- Bert -
Tomeu Vizoso | 1 Mar 13:51 2008
Picon

Re: Journal Object metadata

On Sat, Mar 1, 2008 at 6:44 AM, Benjamin M. Schwartz
<bmschwar <at> fas.harvard.edu> wrote:
>  I have read all the documents I could find, and also the Sugar source, and
>  I am still confused:
>
>  How can an activity get an object representing all the metadata for its
>  current datastore object?

Can you please elaborate? Are you using the python API? If so,
Activity.metadata contains a dictionary with all the properties for
the current object.

>  I ask because I am writing a trivial "Distribute" Activity, whose purpose
>  is to copy journal entries from one XO to another by sharing.  This is
>  working, but since the copy does not have any metadata, like MIME type, it
>  cannot be opened from the Journal interface by any Activity except
>  Distribute, which created it.
>
>  Ideally, I would like to acquire the metadata as a dbus object, so that I
>  may simply shove it over a DBus Tube and then pass it on to the receiver's
>  datastore.

What if you serialize the whole entry (file + metadata) inside a zip
file and distribute that?

http://wiki.laptop.org/go/Journal_entry_bundles

The journal has already support for installing to the DS these
serialized entries:

http://dev.laptop.org/git?p=journal-activity;a=blob;f=journalentrybundle.py

Added because of http://dev.laptop.org/ticket/4380 .

Hope that helps,

Tomeu
Bert Freudenberg | 1 Mar 14:03 2008
Picon

Re: filtering result of an object chooser

On Mar 1, 2008, at 1:02 , Erik Blankinship wrote:

> Is there a way to filter the mime types of the objects presented  
> with an object chooser (e.g., only png)?

Not currently, but I agree that adding a query parameter would be  
rather useful. A work-around is to query the datastore directly and  
present the entries within your own UI.

- Bert -
Tomeu Vizoso | 1 Mar 14:14 2008
Picon

Re: filtering result of an object chooser

On Sat, Mar 1, 2008 at 2:03 PM, Bert Freudenberg <bert <at> freudenbergs.de> wrote:
> On Mar 1, 2008, at 1:02 , Erik Blankinship wrote:
>
>  > Is there a way to filter the mime types of the objects presented
>  > with an object chooser (e.g., only png)?
>
>  Not currently, but I agree that adding a query parameter would be
>  rather useful. A work-around is to query the datastore directly and
>  present the entries within your own UI.

This will work for now, but in the future activities won't be able to
freely access all the entries in the DS.

Which API do you suggest to add to ObjectChooser? I'm willing to look
into this in the near future.

Thanks,

Tomeu
Paul Fox | 1 Mar 14:46 2008
Picon

datastore "instance/" directory

on the low level api page:
    http://wiki.laptop.org/go/Low-level_Activity_API#Writable_Directories

  - it says:  "The "instance/" directory is used for transfer to
    and from the datastore (see above)." it's not clear from
    context what this means (the "transfer" part), nor what the
    "see above" comment refers to.

  - it's also not clear (to me, anyway) what the "non-standard
    location" comments in the table mean.  "non-standard", as opposed to
    what?

  - it's not clear what the answer to bert's first FIXME question
    is, re:  the volatility of "instance/".  is "instance/"
    really just as volatile as ("tmp/"?  michael's answer refers
    to "tmp/", not "instance/".)

  - the second FIXME question re: persistence, is still a good
    one.  the referenced ticket (#5033) is closed, but it's still
    not clear to me how long-lived the "data/" directory is. 
    i guess it's kept across upgrades, and so it would be up to the
    activity to version it, if necessary, correct?  and if the
    activity is removed, "data/" goes away?  (and is the answer
    the same no matter where the activity itself is installed?)

meta-question:  is this the right forum/format for raising
questions like this?  should i use the wiki's discussion page
instead? 

paul
=---------------------
 paul fox, pgf <at> foxharp.boston.ma.us (arlington, ma, where it's 28.4 degrees)
Bert Freudenberg | 1 Mar 14:55 2008
Picon

Re: filtering result of an object chooser

On Mar 1, 2008, at 14:14 , Tomeu Vizoso wrote:

> On Sat, Mar 1, 2008 at 2:03 PM, Bert Freudenberg  
> <bert <at> freudenbergs.de> wrote:
>> On Mar 1, 2008, at 1:02 , Erik Blankinship wrote:
>>
>>> Is there a way to filter the mime types of the objects presented
>>> with an object chooser (e.g., only png)?
>>
>>  Not currently, but I agree that adding a query parameter would be
>>  rather useful. A work-around is to query the datastore directly and
>>  present the entries within your own UI.
>
> This will work for now, but in the future activities won't be able to
> freely access all the entries in the DS.

I thought since this dialog involves explicit user interaction this  
is okay and not restricted by Rainbow?

> Which API do you suggest to add to ObjectChooser? I'm willing to look
> into this in the near future.

I'd simply add a query parameter to the ChooseObject() DBus call.  
Since no shipping activity uses this call directly AFAIK, it should  
be okay at to do at this time.

The Python ObjectChooser's __init__() could grow a "query" keyword  
argument so it would be compatible with existing code.

- Bert -
Bert Freudenberg | 1 Mar 15:33 2008
Picon

Re: datastore "instance/" directory

On Mar 1, 2008, at 14:46 , Paul Fox wrote:

> on the low level api page:
>     http://wiki.laptop.org/go/Low- 
> level_Activity_API#Writable_Directories
>
>   - it says:  "The "instance/" directory is used for transfer to
>     and from the datastore (see above)." it's not clear from
>     context what this means (the "transfer" part), nor what the
>     "see above" comment refers to.

I updated the wiki.

>   - it's also not clear (to me, anyway) what the "non-standard
>     location" comments in the table mean.  "non-standard", as  
> opposed to
>     what?

That comment was simply confusing - it referred to the fact that the  
standard Unix location for temporary data was /tmp. In a former  
design, /tmp would actually be virtualized for each activity, which  
would make SUGAR_ACTIVITY_ROOT unnecessary. I updated the wiki.

>   - it's not clear what the answer to bert's first FIXME question
>     is, re:  the volatility of "instance/".  is "instance/"
>     really just as volatile as ("tmp/"?  michael's answer refers
>     to "tmp/", not "instance/".)

Yes. I updated the wiki.

>   - the second FIXME question re: persistence, is still a good
>     one.  the referenced ticket (#5033) is closed, but it's still
>     not clear to me how long-lived the "data/" directory is.
>     i guess it's kept across upgrades, and so it would be up to the
>     activity to version it, if necessary, correct?

Yes. I updated the wiki.

> and if the
>     activity is removed, "data/" goes away?

Currently it does not go away I think, and would be reused if the  
activity would be reinstalled. This might be considered a bug.

>   (and is the answer
>     the same no matter where the activity itself is installed?)

Yes, install location has no influence on these directories. It only  
depends on wether security is enabled or not.

> meta-question:  is this the right forum/format for raising
> questions like this?  should i use the wiki's discussion page
> instead?

It's better to discuss here, and document the answers on the wiki.

- Bert -

Gmane