It is in the $USER environmental variable.

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

(In reply to Moo from comment #1)
> It is in the $USER environmental variable.

Not necessarily, it may also be the username that corresponds to $UID - that's what g_get_user_name() does, and what we should use instead of poking at env variables ourselves.

You could also get a list of suggestions from the directory names in /home/

Or possibly from /etc/passwd

There is also the $LOGNAME environment variable.

(In reply to Jonh Wendell from comment #0)
> perhaps we should fill the nickname and real name with system's username and
> real name by default in the new connection dialog?

FWIW, I'm against setting a default real name: the field is completely optional, and there are valid reasons for people not to set it (may reveal possibly sensitive information like gender, ethnicity, religion etc. that in the worst case can subject the user to abuse). So I think it is better to let people add it if they want to, than require them to remove it if they don't.

Suggesting a nickname OTOH makes sense to me.

Neither username or realname needs to be set.

But it could be proposed using a placeholder (grayed out text). It could also be available as a suggestion like autocomplete.

In HTML the placeholder would be:
<input type="text" name="nickname" placeholder="alice" />

In HTML the suggestion would be:
<input type="text name="realname" placeholder="Alice Awesome" list="suggestions" />
<datalist id="suggestions">
  <option>Alice Awesome</<option>
  <option>Alice A</<option>
  <option>A. Awesome</<option>
</datalist>

Mockup illustration demo:
http://jsfiddle.net/k72rsz5z/

I think setting by default nickname as username makes sense, as nickname is not optional, user has to modify if he doesnt want it to be nickname.

But in case of realname, just suggesting it as a placeholder text makes sense to me.

Created attachment 312176 [details] [review]
Display default nickname text and realname  placeholder text

Review of attachment 312176 [details] [review]:

::: src/connections.js
@@ +206,3 @@
                                 Lang.bind(this, this._onCanConfirmChanged));
 
+        this._realnameEntry.placeholder_text = GLib.get_real_name();

We currently use the placeholder to indicate to the user which fields are optional, so if we want to change it, we need another way to convey that information.
However I don't really see how this is useful - I don't think there's any confusion about what the field is about, and the placeholder doesn't help at all with setting the real name. IMHO it would be more useful to leave the placeholder alone, but set up EntryCompletion so that the real name is suggested if the user starts entering a matching string.

@@ +259,3 @@
         this._serverEntry.text = '';
         this._descEntry.text = '';
+        this._nickEntry.text = GLib.get_user_name();

This part is fine though.

What does the GNOME HIG say about using placeholders as means to indicate a field is optional?

Is Polari using placeholders as intended or is it misusing placeholders?

(In reply to Moo from comment #12)
> What does the GNOME HIG say about using placeholders as means to indicate a
> field is optional?

Not much:
"When a user would benefit from additional information in order to use a text entry field, it can be prefilled with a hint text. As with any decision to display additional information, this should only be done when it is necessary."


IMHO the information that a field can be left blank is beneficial to users, though of course not strictly necessary. But then you are not arguing for removing the placeholder, but to replace it with a different string - and I frankly don't see how the user's *own* name would qualify as additional information that benefits the user ;-)

(In reply to Florian Müllner from comment #13)
> (In reply to Moo from comment #12)
> > What does the GNOME HIG say about using placeholders as means to indicate a
> > field is optional?
> 
> Not much:
> "When a user would benefit from additional information in order to use a
> text entry field, it can be prefilled with a hint text. As with any decision
> to display additional information, this should only be done when it is
> necessary."
> 
> 
> IMHO the information that a field can be left blank is beneficial to users,
> though of course not strictly necessary. But then you are not arguing for
> removing the placeholder, but to replace it with a different string - and I
> frankly don't see how the user's *own* name would qualify as additional
> information that benefits the user ;-)

haha, Right Florian, indeed what I did was kind of stupid. Displaying real name as placeholder is nothing but a waste. We need something between that, which I think entrycompletion would do. I'd upload the patch soon when I get time. :)

(In reply to Kunaal Jain from comment #14)
> I'd upload the patch soon when I get time. :)

Great! In case you need some pointers (don't know your level of GTK+ experience), here[0]'s an example of setting up entry completion in a GtkBuilder ui description and how to add the actual completions[1].

[0] https://git.gnome.org/browse/polari/tree/data/resources/message-user-dialog.ui
[1] https://git.gnome.org/browse/polari/tree/src/messageDialog.js#n100

Created attachment 312213 [details] [review]
Display default nickname text and realname eventcompletion

Without using gtkbuilder UI, since just one element, that also gets set during runtime. Let me know if this doesnt go with design goals.

(In reply to Florian Müllner from comment #15)
> (In reply to Kunaal Jain from comment #14)
> > I'd upload the patch soon when I get time. :)
> 
> Great! In case you need some pointers (don't know your level of GTK+
> experience), here[0]'s an example of setting up entry completion in a
> GtkBuilder ui description and how to add the actual completions[1].
> 
> [0]
> https://git.gnome.org/browse/polari/tree/data/resources/message-user-dialog.
> ui
> [1] https://git.gnome.org/browse/polari/tree/src/messageDialog.js#n100

Thanks! I do have some prior knowledge and contribution in GNOME, but whenever I start, I feel like beginner, struggling, Googling :D

Review of attachment 312213 [details] [review]:

::: src/connections.js
@@ +215,3 @@
+        realnameEntryCompletion.set_model(realnameStore);
+        realnameEntryCompletion.set_text_column(0);
+        realnameEntryCompletion.set_inline_completion(true);

I don't think popping up a menu with completions is right here, so you should also set either GtkEntryCompletion:popup-single-match or GtkEntryCompletion:popup-completion to false (we only have one possible completion, so there's no difference between the two).

Stylistically I'd reorder this a bit to write this more concise using constructor properties:

let model = new Gtk.ListStore();
model.set_column_types(...);
model.insert_with_valuesv(...);

let completion = new GtkEntryCompletion({ model: model,
                                          text_column: 0,
                                          inline_completion: true,
                                          popup_completion: false });
this._realnameEntry.set_completion(completion);

@@ +268,3 @@
         this._serverEntry.text = '';
         this._descEntry.text = '';
+        this._nickEntry.text = GLib.get_user_name();

So I lied earlier when I said that this looked good to me - it turns out that reset() is only called from the connection settings in the join dialog, but not from the stand-alone dialog, so this doesn't quite work yet.

(In reply to Florian Müllner from comment #18)
> Review of attachment 312213 [details] [review] [review]:
> 
> ::: src/connections.js
> @@ +215,3 @@
> +        realnameEntryCompletion.set_model(realnameStore);
> +        realnameEntryCompletion.set_text_column(0);
> +        realnameEntryCompletion.set_inline_completion(true);
> 
> I don't think popping up a menu with completions is right here, so you
> should also set either GtkEntryCompletion:popup-single-match or
> GtkEntryCompletion:popup-completion to false (we only have one possible
> completion, so there's no difference between the two).
> 
> Stylistically I'd reorder this a bit to write this more concise using
> constructor properties:
> 
> let model = new Gtk.ListStore();
> model.set_column_types(...);
> model.insert_with_valuesv(...);
> 
> let completion = new GtkEntryCompletion({ model: model,
>                                           text_column: 0,
>                                           inline_completion: true,
>                                           popup_completion: false });
> this._realnameEntry.set_completion(completion);

right right.
> 
> @@ +268,3 @@
>          this._serverEntry.text = '';
>          this._descEntry.text = '';
> +        this._nickEntry.text = GLib.get_user_name();
> 
> So I lied earlier when I said that this looked good to me - it turns out
> that reset() is only called from the connection settings in the join dialog,
> but not from the stand-alone dialog, so this doesn't quite work yet.

I dont follow what you are saying about stand-alone dialog. This gets called only through connection settings in the join dialog. For future references, we can also set in _init function. Is that what you have in mind?

(In reply to Kunaal Jain from comment #19)
> I dont follow what you are saying about stand-alone dialog. This gets called
> only through connection settings in the join dialog.

No, there's a "Connections" item in the app menu (or run "gapplication action org.gnome.Polari connections").


(In reply to Kunaal Jain from comment #19)
> we can also set in _init function. Is that what you have in mind?

That would fix it, yes.

Created attachment 312236 [details] [review]
Display default nickname text and realname entrycompletion

Looks good to me, thanks! Pushed with a slightly extended commit message.

Attachment 312236 [details] pushed as a4e2b5dc79 - connections: Suggest default values for new connections