Opened 11 years ago

Closed 11 years ago

Last modified 7 years ago

#425 closed defect (fixed)

Activity instance titles should appear in the primary palette, along with the activity name.

Reported by: HoboPrimate Owned by: tomeu
Priority: Unspecified by Maintainer Milestone:
Component: Sugar Version: 0.84.x
Severity: Critical Keywords:
Cc: FGrose, garycmartin, bert Distribution/OS: Unspecified
Bug Status: New

Description

This would help in diferentiating between multiple instances of the same activity, as well as make naming activities that much more usefull. I think their title should be the primary title on the primary palette.

Change History (10)

comment:1 Changed 11 years ago by wadeb

In the specific instance of Browse, it would be especially great if the icon updated to match the favicon from the currently opened website, just like it's supposed to do in the Journal.

comment:2 Changed 11 years ago by eben

  • Owner changed from eben to tomeu
  • Status changed from new to assigned
  • Summary changed from Running activities on top of the frame should be titled with their activity name, not their generic name to Activity instance titles should appear in the primary palette, along with the activity name.

Agreed. In fact, the designs do show that this was the intention: http://sugarlabs.org/go/DesignTeam/Designs/Frame#02. I don't have strong preference about whether the activity name or instance title appears on the first line, but I recommend that the title comes second, as it will likely be longer and more chars will fit when the string isn't bold.

Both appear in the primary palette, so there's no behavioral difference. Note also that this should be true in all activity palettes; not just those in the Frame.

Regarding the browse idea, I don't think we should change the icon, but I do think we could explore the possibility of allowing activities to badge themselves with small icons, which could indicate status, alerts, message counts, or other details. Another ticket for this idea seems appropriate.

comment:3 Changed 11 years ago by FGrose

  • Bug Status changed from Unconfimed to New
  • Cc FGrose added
  • Distribution/OS changed from SoaS to Unspecified

comment:4 follow-up: Changed 11 years ago by erikos

  • Milestone changed from Unspecified by Release Team to 0.84
  • Severity changed from Unspecified to Minor
  • Version changed from Unspecified to 0.84.x

The issue is, that activities use set_title on the gtk.window (moon, log for example). And we construct the title of the window one.

comment:5 in reply to: ↑ 4 Changed 11 years ago by garycmartin

  • Cc garycmartin added

Replying to erikos:

The issue is, that activities use set_title on the gtk.window (moon, log for example). And we construct the title of the window one.

Can you point me at an Activity you think does this right? iI's been on my list of todo's for Moon for a while, happy to make the fix, think the current behaviour goes way back to the helloworld sample Activity.

comment:6 Changed 11 years ago by bert

  • Cc bert added

I'd like to know, too, what the expected behavior of an activity should be. I finally fixed the Etoys window title issue (should work in jhbuild now). It updates the _NET_WM_NAME hint whenever the project name (instance title) is changed. However, Sugar does not seem to pick up this name change (e.g. in the Frame menu or the "Invite to" label). Sugar apparently only reads the window title once.

comment:7 Changed 11 years ago by erikos

  • Milestone changed from 0.84 to 0.86
  • Severity changed from Minor to Critical

Right. When I change the title of the activity - the title in the journal is updated - but not the window title: activity frame, name of the activity that will be shared.

Let me bump the priority here as you need to first close an activity after naming it to have the title coming up in the mesh view.

comment:8 Changed 11 years ago by gregorio

Resolving this may help kids fin activities and task switch effectively. Multiple instances of an activity will be a challenge but it may help kids move stuff from one activity to another without always going to the journal, thereby saving time.

I will focus on GPA reported issues with saving and retrieving from the journal but this looks useful if you can layout a specific work flow that is addressed by multiple instances.

I hope that's not too fuzzy a comment. Looks useful but I didn't see the exact work flow when reviewing my GPA notes: http://wiki.sugarlabs.org/go/Gardner_Pilot_Academy#Class_notes

so I wont tag it for GPA right now.

Thanks,

Greg S

comment:9 Changed 11 years ago by tomeu

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:10 Changed 7 years ago by dnarvaez

  • Milestone 0.86 deleted

Milestone 0.86 deleted

Note: See TracTickets for help on using tickets.