#5274 NORM Never A: Object chooser

[Zarro Boogs per Child]

#5274: Object chooser
---------------------+------------------------------------------------------
 Reporter:  bert     |       Owner:  mstone        
     Type:  defect   |      Status:  new           
 Priority:  normal   |   Milestone:  Never Assigned
Component:  sugar    |     Version:                
 Keywords:  rainbow  |    Verified:  0             
---------------------+------------------------------------------------------
 The Journal just grew an API for choosing objects callable via DBus:
 {{{
    org.laptop.Journal.ChooseObject(s:xid)
 }}}
 Instead (or in addition to an X window id) the chooser should infer the
 activity and its window from the DBus connection.

 This has security implications. From IRC:
 {{{
 (02:03:36 PM) bertf: tomeu: can we make it take an activity id instead of
 XID?
 (02:03:53 PM) bertf: tomeu: sugar knows about the mapping ...
 (02:04:03 PM) tomeu: hmm
 (02:04:14 PM) tomeu: bertf: the thing is that this is from activities to
 the journal
 (02:04:18 PM) tomeu: the shell is not involved
 (02:04:37 PM) tomeu: bertf: but we have plans to put the journal into the
 shell for u2, perhaps
 (02:05:35 PM) bertf: tomeu: yes, but it is a request from an activity, not
 from some X window I guess. Anyway, etoys does not know its own XID so it
 cannot use the chooser
 (02:06:09 PM) bertf: tomeu: until now, no other Sugar API has required the
 XID
 (02:06:13 PM) tomeu: bertf: parent is not required, you can pass 0
 (02:06:45 PM) bertf: tomeu: oh, okay.
 (02:07:04 PM) tomeu: bertf: but then the dialog won't be transient
 (02:07:19 PM) tomeu: bertf: Browse has the same problem,entered a ticket
 about it
 (02:07:29 PM) bertf: tomeu: you could ask the shell to map the activity id
 to an xid
 (02:08:01 PM) tomeu: bertf: yeah, wonder if that's worth the pain, as we
 are going to move the journal
 (02:08:24 PM) bertf: tomeu: well, better get the API right now, I'd think
 (02:09:09 PM) tomeu: marcop1: what do you think about ChooseObject
 accepting an activity id instead of a xid?
 (02:09:37 PM) bertf: tomeu: probably the activity should be inferred from
 the dbus connection anyway ... otherwise one activity could pose as
 another one, which the security folks would not like at all I guess
 (02:09:40 PM) tomeu: that seems to make more sense, now that i think of it
 (02:10:07 PM) marcop1: tomeu: was about to say what bertf just said...
 (02:10:32 PM) tomeu: marcop1: can we do that right now?
 (02:11:29 PM) marcop1: it would probably be non trivial
 (02:11:47 PM) bertf: isn't that simply the "sender" keyword?
 (02:12:36 PM) marcop1: well the shell would have to maintain a
 sender->activity_id mapping
 (02:13:01 PM) bertf: we should ask the rainbow guys I think
 (02:13:17 PM) marcop1: main problem is that all of this would have to
 happen in the shell
 (02:13:22 PM) marcop1: not in the journal
 (02:13:36 PM) bertf: providing the XID as optional argument might make
 sense if an activity has multiple windows
 (02:14:09 PM) marcop1: yeah perhaps
 (02:15:39 PM) tomeu: bertf: but as you said, activities should not be able
 to request the dialog to be transient on any xid, as could be abused to
 cover other activities' windows
 (02:16:11 PM) bertf: tomeu: well, yes, teh shell would have to check that
 the activity actually "owns" that window
 (02:16:22 PM) marcop1: tomeu: the shell could verify if it's a "parent" of
 the acitvity window
 (02:16:25 PM) tomeu: can that be done?
 (02:16:28 PM) tomeu: oh, cool
 (02:16:41 PM) marcop1: transient doesn't quite mean parent
 (02:16:51 PM) marcop1: but I guess it would make sense here
 (02:17:15 PM) marcop1: because a transient window is displayed in the
 context of the main activity window generally (and in sugar)
 (02:17:56 PM) marcop1: sounds like something to discuss with m_stone
 }}}

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