[sugar] [PATCH] Journal able to use "open with" for activity bundles

[Eben Eliason]

On Tue, Jun 10, 2008 at 4:43 PM, Jameson Chema Quinn
<jquinn at cs.oberlin.edu> wrote:
>
>
> On Tue, Jun 10, 2008 at 2:30 PM, Eben Eliason <eben.eliason at gmail.com>
> wrote:
>>
>> Actually, I disagree with adding "Start" separately to the secondary
>> palette as this will appear redundant beneath the already existing
>> "Start" label in the primary palette.  The better solution (and I
>> think, the expected behavior) is to make the primary palette clickable
>> when the palette is anchored, such that clicking it enacts the action
>> of the button it is attached to.
>
> I agree that this is how palettes should work (of course, not the issue
> here).
>
> However, I don't understand your opposition to repeating the "start" option
> in the submenu. Any journal item already repeats the default option in this
> list; doing the same for activity bundles is only consistent. If we are
> going to change this, it is a separate patch.

Could you please clarify exactly what it is you are trying to do, and
exactly what parts of the GUI it's affecting?  I've taken two stabs at
this, and it seems neither are correct.  I read the code, but I don't
know what context it sits in.  The secondary palettes that appear for
activity icons (bundle or instance) all contain a "Start" or "Resume"
option, respectively.  The button in the toolbar of the detail view
reads either "Start" or "Resume", also as appropriate.  None of the
secondary palettes anywhere in the system repeat the default action of
the button within the secondary palette, as far as I'm aware, as this
would be redundant. (It would be even more redundant (in other words,
functionally, instead of only visually) if the primary palette were
clickable.)

>> Regarding the other options, I think it would be clearer (albeit,
>> admittedly, slightly more indirect) to place the list of available
>> activities in a submenu labeled "Start with" to convey the action that
>> selecting an activity will take.  This would be true of the submenu
>> regardless of whether or not the entry represents a bundle, leaving us
>> in a state where the only difference between bundles and instances is
>> the phrasing used within the menu.  Otherwise, they are functionally
>> identical.
>
> This is not a bad idea. Again, if you are serious about this, we should
> prioritize it and do it, as a separate patch; and I'd be happy to work
> through the options with you, in a separate thread.

Indeed.  I wasn't suggesting it should happen here, but I wanted to
clarify my view of what these buttons and menus should look like,
ideally.

- Eben