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

[Eben Eliason]

On Tue, Jun 10, 2008 at 7:20 PM, Jameson Chema Quinn
<jquinn at cs.oberlin.edu> wrote:
>
>
> On Tue, Jun 10, 2008 at 4:28 PM, Eben Eliason <eben.eliason at gmail.com>
> wrote:
>>
>> On Tue, Jun 10, 2008 at 6:01 PM, Jameson Chema Quinn
>> <jquinn at cs.oberlin.edu> wrote:
>> > Sorry, I am stuck in windows land today, so I cannot confirm anything. I
>> > will respond based on how I recall things, and I'm pretty sure, but
>> > cannot
>> > vouch 100% for what I will say here.
>> >
>> > On Tue, Jun 10, 2008 at 3:02 PM, Eben Eliason <eben.eliason at gmail.com>
>> > wrote:
>> >>
>> >> 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.)
>> >
>> > This patch is for the secondary palette on the start/resume button on
>> > the
>> > details view. Say you have a picture you made in Paint. You'd have an
>> > arrow
>> > button in details, primary palette "resume" (= Paint), secondary palette
>> > "Paint" or "TuxPaint". This is not verbally redundant, but is obviously
>> > redundant in the sense that one of the options in the secondary palette
>> > is
>> > equivalent to the simple button push. It is this redundancy that I was
>> > copying, as my feelings were that inconsistency would be confusing, and
>> > that
>> > intuitive accessibility is a higher priority than non-redundancy.
>> >
>> > If you disagree, I am not really attached to this idea. I just didn't
>> > realize it was controversial (and clung to that blind-spot even when it
>> > meant assuming you misunderstood). I'd vote for redundancy, but it is a
>> > weak
>> > vote.
>>
>> I see.  Well I think I vote against it in the current implementation,
>> actually, since the redundancy (side by side, no less) could actually
>> be confusing (which one do I want!?  what's the difference!?).  My
>> first instinct was to think that it might be OK if we used a submenu,
>> to clarify the action more as I mentioned before.  After considering
>> this, however, I find that it's actually much clearer /not/ to do
>> that.  The reason that Paint is repeated (as per your example) is that
>> the Paint instance can be resumed by Paint, or other supporting
>> activities.  Including Paint itself in the list provides clarification
>> of the action by revealing the name of the default activity, which
>> otherwise wasn't revealed.  We could take a hint from Apple and append
>> "(default)" to the first in the list, with a separator, to make this
>> more evident.
>>
>> On the other hand, an activity bundle (not an "instance") can be
>> started, or resumed by another supporting activity.  Opening the
>> bundle as an object with another activity is actually a very different
>> action from starting a new instance of it.  The former creates a new
>> version of the bundle in the same "thread".  The latter creates a new
>> instance/entry in the Journal in it's own brand new "thread".
>>
>> I think we should do without the redundant "Start" option in the menu.
>>  I think this is still consistent with the other entries:  You either
>> create a new instance of the activity, or you open the bundle (as an
>> object) with some other activity.  You don't in general open the
>> bundle (as an object) with itself (eg. you start a new painting...you
>> don't open the paint bundle in Paint).  The exception to the rule is
>> an activity like Develop, which can indeed open itself.  However, that
>> will be handled naturally by the system, since Develop claims to
>> handle the bundle type already.  This is still very different from
>> saying "Start", which would create an /emtpy/ develop project; it
>> would instead open up to reveal the source code /for/ Develop. Make
>> sense?
>>
>> - Eben
>
> OK, as soon as I get back to Linux I will redo this patch without the
> redundant "start".
>
> As for my opinion on the ideal solution, I think that the menu should look
> like:
>
> Resume           \ just one clickable/highlight block
> with Paint       / across the two lines
> ------------
> with TuxPaint
>
> or
>
> Start
> --
> Resume                 \ just one clickable/highlight block
> with Develop           / across the two lines
> with DevelopProfiler

I vote for:
-----------------
Resume
-----------------
Resume in      >
-----------------

...for instances, and...

-----------------
Start
-----------------
Open in        >
-----------------

The submenu can then contain:

-----------------
Paint (default)
-----------------
Other 1
Other 2
...
-----------------

Another option, assuming we have (or gain) the ability to apply labels
to menu dividers, is to add a "resume with" or "open with" label to
the divider, and then simply group the available activities below
that.  (This amounts to what we have now, but with the added
indication that the action taken with respect to the activities in the
list is eg. "resume with".

> (ok, in magic pony terms, maybe DevelopProfiler and DevelopDebugger and such
> figments should go as other ways of starting, not resuming. But forget
> that.)
>>
>>
>> > (BTW: again, I have no way to test this right now, but I think that the
>> > journal list view item palettes are also redundant. Don't the secondary
>> > palettes have options for run, copy, delete? And run is the same as just
>> > clicking the object's icon?
>>
>> Yes!  This is slightly different, though.  There are two "types" of
>> "things" (hear me out).  There are "objects" (people, activities,
>> devices, etc.) and "buttons" (in toolbars, activities, etc.).  The
>> primary palette of an object identifies the object itself.  The
>> primary palette of a button describes the action of the button.  In
>> other words, the action of a button is part of its identity, as
>> evidenced by the fact that the primary palette contains a description
>> of its action.  The same is not true for objects, which have a list of
>> actions independent of their identity.  As a general rule, we always
>> make the default action (the one taken when an object is clicked) the
>> first option in the list in the secondary palette; it's not explicit,
>> but it will hopefully subconsciously convey the rules for interacting
>> with object in various contexts.
>>
>> Another way to think about it is that the redundant action in the list
>> is "merged" with the primary palette, which takes on the clickable
>> nature of the option that's left out.  The primary palettes for
>> objects won't be clickable, since they are not directly associated
>> with any action.
>
> Is there any clue, besides highlightability (ie, a font?) that shows the
> difference between a clickable and unclickable primary palette?

There is not. (There is a circumstantial one: the clickable ones won't
have object icons in them, since the icon of the button is directly
attached to the primary palette.)  This is meant as a backup, of
sorts, and not as the primary means of taking an action.  The prelight
on the button itself indicates the desired "clickability".

> Also, a quick reality check: I follow you, but we are aiming at
> cross-cultural kids. Whether this distinction will be intuitive for them is
> a separate question. Generally, if you have to explain it to us, the
> developers (and I do not feel too dumb for not having got that before you
> explained it) it may be too hair-splitting a distinction; definitely, if you
> care about it, there should be more clues (see previous paragraph).

Actually, I don't expect to need to.  The inclusion of the clickable
primary palette is a "safegaurd" which ensures that, should people
click on the word representing the action, instead of the icon, the
action will be taken as they expect.  Their instinct says "click on
the word stop" to stop it, and that should work.  (This may be more
true for the literate crowd, which places stronger weight on the
written language than the iconic one).  We've had reports of that.  On
the other hand, there's not one report (that I'm aware of) of people
clicking on the palettes of objects (not actions/buttons) expecting
something to happen.  (This may be for the same reason as above;
adults don't read an action and therefore don't expect one.  Here,
kids might actually try this, but I'm honestly not too concerned about
it at this point.)

>>
>> > BTBTW: This is actually a place where a nested
>> > "open with" menu makes even more sense, and I could write such a patch
>> > if
>> > this one clears.)
>>
>> That would be great.  Thanks!
>
> OK, on my list.
>