Last Comment Bug 39113 - Show current profile name in preferences
: Show current profile name in preferences
Status: NEW
[2012 Fall Equinox]
:
Product: SeaMonkey
Classification: Client Software
Component: Preferences (show other bugs)
: Trunk
: All All
: -- enhancement (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 648086
Blocks:
  Show dependency treegraph
 
Reported: 2000-05-12 13:26 PDT by Ninoschka Baca
Modified: 2012-09-23 13:45 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Show current profile name in preferences. (v1) (3.47 KB, patch)
2011-03-14 00:50 PDT, Edmund Wong (:ewong)
iann_bugzilla: review-
Details | Diff | Review
Show current profile name in preferences. (v2) (3.48 KB, patch)
2011-03-14 21:35 PDT, Edmund Wong (:ewong)
iann_bugzilla: review+
Details | Diff | Review
Show current profile name in preferences. (v3) (3.62 KB, patch)
2011-03-16 07:26 PDT, Edmund Wong (:ewong)
iann_bugzilla: review+
Details | Diff | Review
Show current profile name in preferences. (v4) (3.59 KB, patch)
2011-03-19 19:11 PDT, Edmund Wong (:ewong)
ewong: review+
neil: ui‑review-
Details | Diff | Review
Show current profile name in preferences. (v5) (4.01 KB, patch)
2011-03-31 07:21 PDT, Edmund Wong (:ewong)
no flags Details | Diff | Review
Show current profile name in preferences. (v6) (3.97 KB, patch)
2011-03-31 07:27 PDT, Edmund Wong (:ewong)
no flags Details | Diff | Review
Show current profile name in preferences. (v7) (3.91 KB, patch)
2011-03-31 07:36 PDT, Edmund Wong (:ewong)
no flags Details | Diff | Review
Show current profile name in preferences. (v8) [Checkin: comment 44] (3.83 KB, patch)
2011-03-31 18:51 PDT, Edmund Wong (:ewong)
iann_bugzilla: review+
neil: ui‑review+
Details | Diff | Review
Show current profile name in preferences. (v9) (revisited) (5.63 KB, patch)
2011-05-10 22:07 PDT, Edmund Wong (:ewong)
iann_bugzilla: feedback-
Details | Diff | Review

Description Ninoschka Baca 2000-05-12 13:26:30 PDT
This is a feature request.

It would be nice look somewhere in the UI to determine what profile you are in. 

Adding it to the title bar would result in too much information and I don't know 
of any other logical area. If it was implemented wouldn't it apply to other 
components such as Browser, Composer...?
Comment 1 scottputterman 2000-05-15 13:12:07 PDT
I don't think we have plans to do this in this release.
Comment 2 Ninoschka Baca 2000-05-16 12:25:10 PDT
The implementation of this would also effect the Browser. Some ideas discussed 
in the Mail Issues meeting today include:

1. If only 1 profile exists then don't display a profile name at all
2. If multiple profiles exist then expose the profile name in:
   - the menu, Edit|Preferences for <Profile Name>
   - In the title region of the preferences window, it could display
     "Preferences for <Profile Name>"
Comment 3 Ben Goodger (use ben at mozilla dot org for email) 2001-10-03 01:23:15 PDT
This can be done. Just ask the profile manager back end for the profile name.
Over to Mail FE...
Comment 4 Robert Kaiser (not working on stability any more) 2009-06-14 07:11:03 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 5 Robert Kaiser (not working on stability any more) 2009-06-14 07:23:13 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 6 Robert Kaiser (not working on stability any more) 2009-06-14 07:32:59 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 7 Robert Kaiser (not working on stability any more) 2009-06-14 12:51:39 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 8 Robert Kaiser (not working on stability any more) 2009-06-14 16:58:56 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 9 Robert Kaiser (not working on stability any more) 2009-06-14 17:13:52 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 10 Robert Kaiser (not working on stability any more) 2009-06-14 17:16:54 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 11 Robert Kaiser (not working on stability any more) 2010-04-28 12:53:42 PDT
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Comment 12 Karsten Düsterloh 2010-12-21 13:29:28 PST
Still a valid enhancement request, especially see comment 3.
Comment 13 Jens Hatlak (:InvisibleSmiley) 2010-12-21 13:36:03 PST
FYI: We have Help / Troubleshooting Information on trunk now, so there's at least a way to determine which profile is currently in use for the active session. It's not displaying the profile name, though.
Comment 14 Karsten Düsterloh 2010-12-21 14:41:43 PST
Well, you could open "Tools->Switch Profile" to see the currently running profile - but displaying the name in the preferences would be a nice solution.
Comment 15 Philip Chee 2010-12-22 08:39:15 PST
Toolkit profiles don't necessarily have a name. What should you do then?
Comment 16 Karsten Düsterloh 2010-12-22 09:17:59 PST
You can only show what you have, of course.
Showing the path etc. of profiles unknown to the profile manager is not useful, imo. We should depend upon the profile manager's knowledge of things here.
Comment 17 Edmund Wong (:ewong) 2011-03-14 00:50:08 PDT
Created attachment 519095 [details] [diff] [review]
Show current profile name in preferences. (v1)
Comment 18 Jens Hatlak (:InvisibleSmiley) 2011-03-14 13:00:26 PDT
(In reply to comment #17)
> Created attachment 519095 [details] [diff] [review]
> Show current profile name in preferences. (v1)

Nice!

Nits:
1. I suggest adding double quotes around the profile name and/or putting a "profile " in front of it. Otherwise it might confuse users depending on how the named their profile. E.g. I always name my fresh profile "fresh" so the dialog title was "Preferences for fresh"...
2. the "g" prefix in gProfileSrvc suggests this is a global variable, but currently it's not.
Comment 19 Ian Neal 2011-03-14 16:17:46 PDT
Comment on attachment 519095 [details] [diff] [review]
Show current profile name in preferences. (v1)

>+++ b/suite/common/pref/preferences.js
>+function StartUp()
>+{
>+  gProfileSrvc = Components.classes["@mozilla.org/toolkit/profile-service;1"]
>+                           .getService(Components.interfaces.nsIToolkitProfileService);
Need to define the variable, not global so var profileSrvc perhaps? Not sure if Services.jsm offers this one as a service.

>+  var selectedProfile = null;
>+
>+  selectedProfile = gProfileSrvc.selectedProfile;
Why setting to null and then from the profile service? Should we be looking at having a try/catch? We only use selectedProfile the once so why not just get selectedProfile.name from the beginning, then only do the following if it is not null?

>+  var prefStrBundle = document.getElementById("bundle_prefutilities");
>+  var prefProfile = prefStrBundle.getFormattedString("preferencesAccount",
>+                                                        [selectedProfile.name]);
Nit: needs lining up.
>+
>+  var p = document.getElementById("prefDialog");
>+  p.setAttribute("title", prefProfile);
Nit: inline, setting the var p offers no additional readability.
>+}

>+++ b/suite/common/pref/preferences.xul
> <prefwindow id="prefDialog" 
>             xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
>-            title="&prefWindow.title;" 
If for some reason we cannot get the selectedProfile.name perhaps best leaving a default here.
>             style="&prefWindow.size;"
>             windowtype="mozilla:preferences"
>             buttons="accept,cancel,help"
>-            autopanes="true"> 
>+            autopanes="true"
>+            onload="StartUp()"> 
Nit: missing ;
Comment 20 Edmund Wong (:ewong) 2011-03-14 21:35:37 PDT
Created attachment 519331 [details] [diff] [review]
Show current profile name in preferences. (v2)
Comment 21 Ian Neal 2011-03-15 07:49:26 PDT
Comment on attachment 519331 [details] [diff] [review]
Show current profile name in preferences. (v2)

>+function StartUp()
>+{
>+  var profileSrvc = Components.classes["@mozilla.org/toolkit/profile-service;1"]
>+                             .getService(Components.interfaces.nsIToolkitProfileService);
Nit: needs lining up.
>+  var selectedProfile = profileSrvc.selectedProfile.name;
Here, if we are worried about not getting the information (as in profileSelection.js), I would do something like:

var selectedProfile = null;
try
{
  selectedProfile = profileSrvc.selectedProfile.name;
}
catch (e) {}

if (selectedProfile)
{
  var prefProfile = document.getElementById("bundle_prefutilities")
                            .getFormattedString("preferencesAccount",
                                                [selectedProfile]);
  document.getElementById("prefDialog").setAttribute("title", prefProfile);
}

(Could even use "let" instead of "var" within the if statement).

r=me with that fixed/addressed
Comment 22 Philip Chee 2011-03-15 09:37:16 PDT
> try
> {
>   selectedProfile = profileSrvc.selectedProfile.name;
> }
> catch (e) {}
Hmm. Does the nsIToolkitProfileService potentially throw here?
Comment 23 Ian Neal 2011-03-15 10:54:01 PDT
(In reply to comment #22)
> > try
> > {
> >   selectedProfile = profileSrvc.selectedProfile.name;
> > }
> > catch (e) {}
> Hmm. Does the nsIToolkitProfileService potentially throw here?

We protect against it in profileSelection.js, so I would say yes, seems to be some sort of similar protection in toolkit js files too.
Comment 24 Jens Hatlak (:InvisibleSmiley) 2011-03-15 11:32:46 PDT
(In reply to comment #18)
> 1. I suggest adding double quotes around the profile name and/or putting a
> "profile " in front of it. Otherwise it might confuse users depending on how
> the named their profile. E.g. I always name my fresh profile "fresh" so the
> dialog title was "Preferences for fresh"...

Ian, what's your opinion about this?
Comment 25 Ian Neal 2011-03-15 14:22:24 PDT
(In reply to comment #24)
> (In reply to comment #18)
> > 1. I suggest adding double quotes around the profile name and/or putting a
> > "profile " in front of it. Otherwise it might confuse users depending on how
> > the named their profile. E.g. I always name my fresh profile "fresh" so the
> > dialog title was "Preferences for fresh"...
> 
> Ian, what's your opinion about this?

I think Edmund addressed this with the change to "Preferences for profile %S" and I am happy with that.
Comment 26 Jens Hatlak (:InvisibleSmiley) 2011-03-15 14:24:16 PDT
(In reply to comment #25)
> I think Edmund addressed this with the change to "Preferences for profile %S"
> and I am happy with that.

Oops, missed that change, sorry. Alright then!
Comment 27 Edmund Wong (:ewong) 2011-03-16 07:26:55 PDT
Created attachment 519645 [details] [diff] [review]
Show current profile name in preferences. (v3)
Comment 28 Ian Neal 2011-03-16 17:47:30 PDT
Comment on attachment 519645 [details] [diff] [review]
Show current profile name in preferences. (v3)

r=me though you might find that the patch for prefutilities.properties
 has been bitrotted.
Comment 29 neil@parkwaycc.co.uk 2011-03-19 07:20:56 PDT
Comment on attachment 519645 [details] [diff] [review]
Show current profile name in preferences. (v3)

>+function StartUp()
Startup please.

>+  try
>+  {
>+    selectedProfile = profileSrvc.selectedProfile.name;
>+  }
>+  catch (e) {}
>+
>+  if (selectedProfile)
>+  {
>+    let prefProfile = document.getElementById("bundle_prefutilities")
>+                              .getFormattedString("preferencesAccount",
>+                                                  [selectedProfile]);
Can you not do this inside the try/catch instead of using a separate if?

>+    document.getElementById("prefDialog").setAttribute("title", prefProfile);
Use document.title
Comment 30 Edmund Wong (:ewong) 2011-03-19 19:11:49 PDT
Created attachment 520489 [details] [diff] [review]
Show current profile name in preferences. (v4)
Comment 31 neil@parkwaycc.co.uk 2011-03-20 04:38:52 PDT
Comment on attachment 520489 [details] [diff] [review]
Show current profile name in preferences. (v4)

I tried this out, and it doesn't actually work, because profileSrvc.selectedProfile is the last one you chose in the profile manager; if you use -P <name> to choose a profile, it bypasses that, and you get the wrong profile name. (And I don't know what you're supposed to do if you use -profile to choose a profile...)

>+  try
>+  {
>+    selectedProfile = profileSrvc.selectedProfile.name;
>+    if (selectedProfile)
[Do you need the if?]

>+    {
>+      let prefProfile = document.getElementById("bundle_prefutilities")
>+                                .getFormattedString("preferencesAccount",
>+                                                    [selectedProfile]);
>+      document.title = prefProfile;
[Hardly worth the variable!]
Comment 32 Jens Hatlak (:InvisibleSmiley) 2011-03-30 08:17:51 PDT
(In reply to comment #31)
> I tried this out, and it doesn't actually work, because
> profileSrvc.selectedProfile is the last one you chose in the profile manager

How about this:

1. Use profileSrvc.profiles (which is an nsISimpleEnumerator) to go through the nsIToolkitProfile objects
http://mxr.mozilla.org/mozilla-central/source/toolkit/profile/nsIToolkitProfileService.idl#51

2. Determine the current one by comparing the .rootDir property of the loop variable to the current profile's (from dirsvc "ProfD")
http://mxr.mozilla.org/mozilla-central/source/toolkit/profile/nsIToolkitProfile.idl#83
http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/content/aboutSupport.js#463

3. Get the name using .name
http://mxr.mozilla.org/mozilla-central/source/toolkit/profile/nsIToolkitProfile.idl#94
Comment 33 Edmund Wong (:ewong) 2011-03-31 07:21:39 PDT
Created attachment 523297 [details] [diff] [review]
Show current profile name in preferences. (v5)
Comment 34 Edmund Wong (:ewong) 2011-03-31 07:22:06 PDT
Comment on attachment 523297 [details] [diff] [review]
Show current profile name in preferences. (v5)

credit goes to InvisibleSmiley.
Comment 35 Edmund Wong (:ewong) 2011-03-31 07:27:24 PDT
Created attachment 523299 [details] [diff] [review]
Show current profile name in preferences. (v6)
Comment 36 Edmund Wong (:ewong) 2011-03-31 07:36:10 PDT
Created attachment 523301 [details] [diff] [review]
Show current profile name in preferences. (v7)

w/ changes mentioned on IRC by InvisibleSmiley
Comment 37 Jens Hatlak (:InvisibleSmiley) 2011-03-31 15:00:05 PDT
Comment on attachment 523301 [details] [diff] [review]
Show current profile name in preferences. (v7)

Who ever gets to review this first... Contains string changes, so either makes b3 (within 24h) or will miss 2.1.
Comment 38 neil@parkwaycc.co.uk 2011-03-31 15:42:16 PDT
Comment on attachment 523301 [details] [diff] [review]
Show current profile name in preferences. (v7)

If there is only one profile, should we still display it?

>+    if (profile.rootDir.path == compTarget) {
Don't compare paths, use nsIFile's equals method instead.

>+  try
Don't need this try/catch.
Comment 39 neil@parkwaycc.co.uk 2011-03-31 15:47:50 PDT
Comment on attachment 523301 [details] [diff] [review]
Show current profile name in preferences. (v7)

>+preferencesAccount=Preferences for Profile %S
This doesn't look quite right to me. I notice that comment 25 has the word "profile" in lower case, which should help. (Or there's always "%S".)
Comment 40 Jens Hatlak (:InvisibleSmiley) 2011-03-31 15:58:47 PDT
(In reply to comment #39)
> >+preferencesAccount=Preferences for Profile %S
> This doesn't look quite right to me. I notice that comment 25 has the word
> "profile" in lower case, which should help.

That was my fault, I gave ewong the advice on IRC because I assumed we'd like to go with title case for the dialog heading.

> (Or there's always "%S".)

Right, which is what I suggested in comment 24. Either way.
Comment 41 Edmund Wong (:ewong) 2011-03-31 18:48:57 PDT
(In reply to comment #38)
> Comment on attachment 523301 [details] [diff] [review]
> Show current profile name in preferences. (v7)
> 
> If there is only one profile, should we still display it?

I believe it'd be consistent if it was available.
Comment 42 Edmund Wong (:ewong) 2011-03-31 18:51:56 PDT
Created attachment 523493 [details] [diff] [review]
Show current profile name in preferences. (v8) [Checkin: comment 44]
Comment 43 neil@parkwaycc.co.uk 2011-04-02 09:07:15 PDT
Or maybe "Preferences for %s profile" ?
Comment 44 Jens Hatlak (:InvisibleSmiley) 2011-04-02 13:50:39 PDT
Comment on attachment 523493 [details] [diff] [review]
Show current profile name in preferences. (v8) [Checkin: comment 44]

http://hg.mozilla.org/comm-central/rev/9b1e4c3f6bcf

With comment 43 incorporated after r=IanN over IRC for the change.
Comment 46 Edmund Wong (:ewong) 2011-05-10 20:19:52 PDT
From https://bugzilla.mozilla.org/show_bug.cgi?id=648086#c5, 
should a flex'd (centered) label below the PrefWindow Title but above
both the left and right pane of the preferences window? 
ie.

PrefWindow Title--------------------------------------------------------------|
[ for profile 'profilename'                                                  ]|
|------------------------|  Browser                                           |
|Category                |                                                    |

Or will it push the category tree list and right pane down too much?
Comment 47 Edmund Wong (:ewong) 2011-05-10 22:07:45 PDT
Created attachment 531540 [details] [diff] [review]
Show current profile name in preferences. (v9) (revisited)
Comment 48 Ian Neal 2011-05-13 16:34:56 PDT
Comment on attachment 531540 [details] [diff] [review]
Show current profile name in preferences. (v9) (revisited)

Sorry, but just does not look right and pushes stuff too far down.
Comment 49 Edmund Wong (:ewong) 2012-09-08 07:07:12 PDT
completely stuck on this.  unassigning myself in hopes someone will have a better go at it.

Note You need to log in before you can comment on or make changes to this bug.