On Tue, Jun 10, 2008 at 4:28 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 10, 2008 at 6:01 PM, Jameson Chema Quinn > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > wrote: > >> > >> On Tue, Jun 10, 2008 at 4:43 PM, Jameson Chema Quinn > >> <[EMAIL PROTECTED]> wrote: > >> > > >> > > >> > On Tue, Jun 10, 2008 at 2:30 PM, Eben Eliason <[EMAIL PROTECTED] > > > >> > 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.
_______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
