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

[Jameson "Chema" Quinn]

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


(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?

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).

>
>
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080610/0b1197fc/attachment.htm