25196 - Profile properties dialog (with path, name, etc)

Status: RESOLVED DUPLICATE of bug 670561

(SeaMonkey :: Startup & Profiles, enhancement)

Description

[Henrik Gemal]

When you're in the Profile Manager it could be nice to be able to right-click on 
a profile and select Properties.

This would show the path of where the profile resides like:
C:\mozilla\users\gemal

plus other stuff perhaps..?

Comment 1

[Ben Goodger (use ben at mozilla dot org for email)]

okay. let's make this one a request for a small properties dialog showing the 
profile path, name, etc. then I can hang my similar bugs off this. 

Comment 2

[Ben Goodger (use ben at mozilla dot org for email)]

resummarise

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

resummarise (again)

Comment 4

[Ben Goodger (use ben at mozilla dot org for email)]

*** Bug 23231 has been marked as a duplicate of this bug. ***

Comment 5

[Matthew T (active 1999-2002)]

Need a design for this, Ben?

Comment 6

[Ben Goodger (use ben at mozilla dot org for email)]

sure, if you feel like knocking one together ;)

Comment 7

[Matthew T (active 1999-2002)]

Ok, before we design it, exactly what stuff should we show in the dialog?
* profile name
* profile location
* date profile created
They're pretty much a given.

But what about ...
* date profile last used?
* name of person, as in the Identity field for their default mail account?
* Organization, likewise?
* other stuff? (home page? number of mail accounts? how much time they've spent
  using Mozilla in the past week???)

What sort of privacy/security considerations are there for showing info about 
someone else's profile? In what respects will the amount of data we can access be 
restricted in the future, when profiles are encrypted?

CCing norris for some guidance.

Comment 8

[Norris Boyd]

I think the only information in a profile that we consider truly private will be
encrypted. The other information from a profile could be obtained with
relatively little effort if someone has access to your machine.

Comment 9

[Matthew T (active 1999-2002)]

Ok. I've been thinking. <groan/> Rather than appearing in a separate dialog, 
which would be annoying if you wanted info on several profiles consecutively 
(with all the windowing involved), profile info should appear in the profile 
manager when the profile is selected in the list.

It should not appear in the profile *selector*, because there it would be just 
clutter.

So:

+---------------------------------------------------+
|[] Select profile :::::::::::::::::::::::::::::::::|
+---------------------------------------------------+
|                             +-----------------+-+ |
| Please select your profile  |8 ben            |A| |
| from the list, to access    |8 mozProfile     | | |
| your bookmarks, e-mail      |8 mpt            | | |
| accounts, and other         |                 | | |
| personal settings.          |                 | | |
|                             |                 | | |
| If this is the first time   |                 | | |
| you have used Mozilla on    |                 | | |
| this computer, select `New  |                 | | |
| profile'.                   |                 | | |
|                             |                 |V| |
| (   New profile ...   )     +-----------------+-+ |
| ( Manage profiles ... )     [*] Work off-line     |
|                                                   |
|---------------------------------------------------|
| ( Help )             ( Exit ) (( Start Mozilla )) |
+---------------------------------------------------+

(I assume that the `Work off-line' checkbox has been commented out in the current 
UI, Ben. Better to leave it in, but disable it, so that people realize the 
feature will be there eventually.)

+--------------------------------------------------------------+
|[] Manage Profiles :::::::::::::::::::::::::::::::::::::::::::|
+--------------------------------------------------------------+
| +-----------------+-+ +-Profile info-----------------------+ |
| |8:ben::::::::::::|A| |                    ______________  | |
| |8 mozProfile     | | | Profile name:     [ben___________] | |
| |8 mpt            | | | Real name:        Ben Goodger      | |
| |                 | | | E-mail address:   [e-mail] | |
| |                 | | |                                    | |
| |                 | | | Mozilla version:  Netscape 5.0     | |
| |                 | | | Profile created:  24 August 1999   | |
| |                 | | | Last used:        1 March 2000,    | |
| |                 | | |                   4:42 PM          | |
| |                 | | +------------------------------------+ |
| +-----------------+-+ ( New profile ... ) ( Delete profile ) |
|                                                              |
|--------------------------------------------------------------|
| ( Help )                               ( Cancel ) ((  Ok  )) |
+--------------------------------------------------------------+

Using a text box for the profile name saves having a separate dialog for renaming 
the profile (which is yukky).

I've removed the `Start Mozilla' button from the profile manager. We need to 
clearly distinguish between starting Mozilla with a profile, and the different 
task of managing profiles. (That's also why I've put the profile list on opposite 
sides of the dialogs, to emphasize the difference between the dialogs.) The 
current design, where you can get there from here but you can't get here from 
there (`here' being the profile selector, and `there' being the profile manager), 
is a recipe for confusion.

Have fun ... :-)

Comment 10

[Henrik Gemal]

Please remember the pathname of the profile. Something like:
C:\program files\mozilla\users\ben

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

heh. interesting dialogs. Given 
http://lxr.mozilla.org/seamonkey/source/profile/public/nsIProfile.idl however 
the final implementation may be somewhat more limited ;) 

Comment 12

[Matthew T (active 1999-2002)]

Yes, I woke up in the middle of the night last night and thought, `oh crap -- I 
forgot to include the path of the profile, which was half the point in the first 
place'.

I'm sorry, I can't make head nor tail of
<http://lxr.mozilla.org/seamonkey/source/profile/public/nsIProfile.idl> -- I 
assume it means that we can't show as much info about the profile as I presented.

Take two:

+----------------------------------------------------------------+
|[] Manage Profiles :::::::::::::::::::::::::::::::::::::::::::::|
+----------------------------------------------------------------+
| +-----------------+-+ +-Profile info-------------------------+ |
| |8:ben::::::::::::|A| |                       _____________  | |
| |8 mozProfile     | | | Profile name:        [ben__________] | |
| |8 mpt            | | | Location: [les\Mozilla\Users50\ben\] | |
| |                 | | |                                      | |
| |                 | | | User name:           Ben Goodger     | |
| |                 | | | Profile created by:  Netscape 4.5    | |
| |                 | | | Date created:        3 July 1998     | |
| |                 | | | Date last used:      1 March 2000,   | |
| |                 | | |                      4:42 PM         | |
| |                 | | +--------------------------------------+ |
| +-----------------+-+ (  New ...  ) ( Duplicate ) (  Delete  ) |
|                                                                |
|----------------------------------------------------------------|
| ( Help )                                 ( Cancel ) ((  Ok  )) |
+----------------------------------------------------------------+

Any bits of this design which are currently unimplementable can be dropped 
without too much damage, but ideally they should all be implemented eventually.

Details:
* When first drawn, the contents of the `Location' field (which is a non-editable
  text field, so I can scroll to see all of the path) is right-aligned.
* We *do* need to know which user agent created the profile. This info must be
  stored in a standard place in the profile somewhere, because in a couple of
  years when there are dozens of different flavors of Mozilla, such info will be
  useful in giving the user a clue as to how much of a good idea it is to use
  profile X with browser Y. (As for Communicator 4.x profiles, they can be
  identified using other clues such as specific 4.x-only prefs in the prefs.js or
  whatever.)
* Pressing the `Duplicate' button:
  - opens a progress dialog with the title `Duplicating profile', the words
    `Checking disk space ...', an indeterminate progress indicator, and
    (perhaps not until a later version) a `Cancel' button;
  - calculates whether there is enough space on the disk to clone the selected
    profile (counting the number of files involved, along the way), and if there
    isn't enough space, exits with an error dialog;
  - changes the `Checking disk space ...' text to `Copying files ...', and
    changes the indeterminate progress indicator to a 0% progress indicator,
    which then tracks the progress of the file copying.

Don't you just love all this extra work?

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

not a priority, pushing out as far as possible.

Comment 14

[don]

Move to "Future" milestone.

Comment 15

[Blake Ross]

Profile Manager FE bugs --> me

Comment 16

[Blake Ross]

--> Ben

Comment 17

[Henrik Gemal]

RFE cleanup. RFE is already indicated by the Severity field...Sorry for the 
spam!

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

->Future

Comment 19

[Henrik Gemal]

Attachment: screenshot of Properties dialog

Comment 20

[Henrik Gemal]

Attachment: updated screenshot

Need feedback. Is this dialog ok? UI, locale,...?

Comment 21

[Henrik Gemal]

Attachment: zip file with modified files and new files.

Comment 22

[timeless]

Comment on attachment 126614 [details]
updated screenshot

1. i don't like the comment at the top, imo it's useless. remove it.

2. a 'move' button would be nice

3. can i edit the last modified field? i don't think i should be able to. (this
sort of applies to the path if you can't actually move it)

4. There should be a cancel button in addition to the ok button.

Comment 23

[Henrik Gemal]

1) I'll remove it

2) Later. No part of this bug

3) They are not editiable. There are disabled textfields but the user can 
select the text in them.

4) Why a cancel button? There's nothing to cancel...

Will attach new patch with issue 1 fixed. Ok?

Comment 24

[Henrik Gemal]

taken bug

Comment 25

[timeless]

re 3. i'm fairly certain we have a selectable readonly field which is what you should use. it's probably a class.

re 4. use 'close' instead of 'ok' for the time being.

Comment 26

[Henrik Gemal]

Attachment: patch to existing files

timeless: I've used the same textfield that's used in the Folder Properties
dialog

Comment 27

[Henrik Gemal]

Attachment: new profile files. I cant diff those since they are new

Comment 28

[Henrik Gemal]

Comment on attachment 128809 [details] [diff] [review]
patch to existing files

the patch also have a zip file with the new profile files

Comment 29

[timeless]

Comment on attachment 128809 [details] [diff] [review]
patch to existing files

could you add alt-enter to the keypress handling? :)

Comment 30

[timeless]

Comment on attachment 128810 [details]
new profile files. I cant diff those since they are new

MPL-tri, not NPL
use a boilerplate, so don't (c) 1998 - we're in 2003.

var profile =
Components.classes["@mozilla.org/profile/manager;1"].getService();
if (profile)
  profile = profile.QueryInterface(Components.interfaces.nsIProfileInternal);

1. getService/createInstance throw they don't fail w/ null.
2. combine the QI w/ the getService:

try {
var profile =
Components.classes["@mozilla.org/profile/manager;1"].getService(Components.inte
rfaces.nsIProfileInternal);
catch (e) {}

<dialog
i don't think you need this:
  class="dialog"
i still would prefer close, but i won't fight it:
  buttons="accept"

Comment 31

[Henrik Gemal]

Attachment: patch v2

Comment 32

[Henrik Gemal]

Attachment: new profile files

Comment 33

[Henrik Gemal]

Comment on attachment 128816 [details] [diff] [review]
patch v2

how do I detect ALT+ENTER?

Comment 34

[Henrik Gemal]

Attachment: Patch to existing files

Comment 35

[Henrik Gemal]

Attachment: new profile files v3

Comment 36

[Henrik Gemal]

Attachment: both new and existing files

Comment 37

[Henrik Gemal]

Comment on attachment 131239 [details]
both new and existing files

unzip the .js .xul into content and .dtd and .profperties into locale

I addressed your comment but:
- No way to add alt+enter stuff
- decided on the Ok button.

Comment 38

[timeless]

Comment on attachment 131239 [details]
both new and existing files

> var gprofilePropertiesBundle;
the variable should be:
gProfilePropertiesBundle;

>    profileDir = profileDir.QueryInterface( Components.interfaces.nsIFile );
QI will throw instead of returning null:
>    if (profileDir) {
so wrap the call and this block in a try {}
>      var profilePath = document.getElementById( "profilePath" );
>      profilePath.value = profileDir.path;
>    }
>    var profileLMT = document.getElementById( "profileLMT" );
>    try {
>      var profileTime = profile.getProfileLastModTime(profilename);
>    } catch(e) {
>      var profilePropertiesMissingLMT = gprofilePropertiesBundle.getString("profilelmtUnknown");
>      profileLMT.value = profilePropertiesMissingLMT;
>    }
>    if (profileTime) {
...
block ends about here.

I think everything else looks ok.

Comment 39

[Andreas Kunz]

Henrik, this has almost review... do you want to resume your work on it? Or
should somebody else resurrect this?

Comment 40

[Henrik Gemal]

I'll try to finish it soon.

Comment 41

[[e-mail]]

Comment on attachment 131239 [details]
both new and existing files

>profileDir = profileDir.QueryInterface( Components.interfaces.nsIFile );
You don't want to do this for two reasons.
Firstly, profileDir is already an nsIFile. At least, I assume you're using
nsIFile getProfileDir(in wstring profileName) from nsIProfileInternal.idl
Secondly, shouldn't you be using wstring getProfilePath(in wstring profileName)?

Comment 42

[Philip Chee]

This is a front end bug really. Moving back to SeaMonkey. Sorry for the bugspam

Comment 43

[Philip Chee]

DUPing to Bug 670561. For any other enhancements, please file a new bug. Thankyouverymuch.

Comment 44

[Philip Chee]

Comment on attachment 131239 [details]
both new and existing files

Cancelling obsolete review request.