The welcome screen would be useful in scenarios when gedit is started with any documents open, but in case there's a file open, to open another file the user would still have to "find" the open button. Maybe draw some inspiration from browsers: having a new tab button instead of an open button might help:
* clicking the new tab button would open the welcome screen
* the welcome screen with links to recent files + new file and open file buttons (just like in the mockup) would replace the open dropdown (while having the same functionality with the same number of clicks - except for open, which user testing revealed to be hard to find) and the search (as in the mockup) would further enhance its usefulness. The only drawback is the increased mouse travel distance, but that can also be improved.

I think the current button is good, since it saves you a click from the pop-over menu. However, I don't see why there also can be a "Select File..." option in the menu.

(In reply to comment #0)
> During recent user testing on gedit, a number of users had difficulty finding
> the open file action. They tried to find the open option within the recent
> items drop down and, having inspected this, did not try to use the linked open
> button.

Perhaps they thought the "Open" button was a label for the gear menu, like "Open Menu"?

Honestly, this is really disappointing/frustrating to learn. The Open button is really big.

I guess the lesson of this and Bug #732222 is that buttons in the header bar ought to have menu entries as well? But then that adds clutter to the menu.

(In reply to comment #3)
> Perhaps they thought the "Open" button was a label for the gear menu, like
> "Open Menu"?

You mean they might have thought it was a label for the arrow menu that lists recently used files? (The gear menu is on the opposite side of the header bar.) Evidently. Maybe linking text and image buttons is confusing if you haven't seen it before.

(In reply to comment #0)
> One potential solution would be to implement the kind of new tab screen that
> has been under discussion for a while, like the one in this mockup:

But that would make it even harder to find Open, since you would first have to click on New, which feels more like "New Document" than "New Tab." Even if it was clearly a New Tab button, as Robert suggests, it would be quite confusing that you need to press New Tab in order to get to Open.  (I really like that new tab page, just not as a replacement for a traditional Open action.)

> Another possible answer would be to combine the open button with the recent
> files dropdown, into a single popover:

This seems reasonable, though like Mattias noted, it adds one extra click.

(In reply to comment #0)
> During recent user testing on gedit.
> 

It's great to hear about this initiative!


> One potential solution would be to implement the kind of new tab screen that
> has been under discussion for a while, like the one in this mockup:
> 
> https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gedit/gedit-menus-v3.png
> 

As you know from past discussions, I am not so convinced about using the "new tab screen" thingie :)


> Another possible answer would be to combine the open button with the recent
> files dropdown, into a single popover:
> 
> [ Open V ]
> 
> File 1
> File 2
> File 3
> File 4
> File 5
> ---
> Select File...


Yes, this is much more like what I have in mind and I actually wanted to do it last cycle and run out of time.
To be more precise, I was thinking of a popover slightly more complex than just a menu: something along the line of

[ (doc symbolic icon v ]

_______________________
| New    |   Select... |
|----------------------|
|   [ entry to type ]  |
| recent 1             |
| recent 2             |
| recent 3             |
| recent 4             |
_______________________


Note: the above popover layout is just a quick ascii sketch and suggestions/changes/mockups are more than welcome. The notable differences with respect to your proposal are:
1) also have new in there
2) use a search entry + listbox for the recent files

>> Perhaps they thought the "Open" button was a label for the gear menu, like
>> "Open Menu"?
>
>You mean they might have thought it was a label for the arrow menu that lists
>recently used files? (The gear menu is on the opposite side of the header bar.)
>Evidently. Maybe linking text and image buttons is confusing if you haven't
>seen it before.

Hi. I'm the person who facilitated the usability tests. What I observed was users clicking on the "V" part of the "Open" button. These users were not clicking on the button per-se; they thought the "V" was the part of the button they should click on.

The "V" drop-down menu brings up a list of recently used files. But since each usability tester started with a fresh instance of GNOME, there were no recently-used files anyway.

Perhaps if the drop-down menu could include "open a new file" (similar to Paolo's ascii sketch) that would resolve things?

Created attachment 280630 [details] [review]
button and File-dialog popover to replace headerbar file controls

Created attachment 280631 [details]
screenshot

Thanks for prototyping this. Allan, Jim, what do you think?

Here are my doubts after seeing this live:

1) I fear one would expect to select a file in the list and then click on the "open" button expecting to open the file... can this be avoided by better wording on the button? Or maybe "select other..." should be a special item always present in the list?

2) should the button on the header bar have the down arrow or not? the gear menu does not have it

3) should the button on the header bar use doc-new icon or the new-tab icon

for 1) 

Using pointer, clicking an item immediately loads the corresponding file ( no double-click ) so no 'open button' confusion in this case.

Using keyboard, you must select an item and hit enter. So in this case you can be confused by going to the 'open button'. isn't an extreme case ?

I've tried the popover patch, and it's quite cool. There are a few UI issues there that I can see, but I think we can make it work - I'd be happy to look at the design.

Before we go down that road though, it's maybe worth reflecting on the relative merits of using a popover for this, versus a new tab screen [1].

Popover advantages:

 * It's a less severe visual transition when you want to open/start a document.
 * Probably works better on a large screen.

New tab view advantages:

 * Better first run experience when launching gedit directly. It is particularly convenient to see recent files in this scenario.
 * Including a new document action makes more sense here.

[1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gedit/gedit-menus-v3.png

(In reply to comment #11)
...
> Before we go down that road though, it's maybe worth reflecting on the relative
> merits of using a popover for this, versus a new tab screen [1].
...

Paolo and I discussed this on IRC earlier. He made some good points:

 - it is weird when you open many files, e.g. new tab -> file chooser -> select many
 - it gets in the way when I just want to ctrl+N and takes some notes
 - opening an already open file switches to that tab, which would be weird on the new tab

Here's a mockup for how the popover could be improved:

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gedit/png/document-popover.png

It would be good to give it a static height, so that searching doesn't make the popover change shape.

Created attachment 281039 [details] [review]
gedit file popover

Created attachment 281040 [details]
screenshot

Could extensions have an api to extend this popover somehow? For me the popover seems a bit too cluttered, I would like some more spacing and/or padding, and maybe the files should also show part of the path of the file in a second row for each result. My usecase is: I often do work with similarly-named files, or even files with the same name (e.g. multiple copies of the same project), and I always have to guess from the recent list which file I want to edit (the one on the correct path).

Hi Robert,

Don't pay too much attention to rows style, it's just a matter of css to change it, we just wait for green light from design team before refinement.

For the path part, this patch have tooltips, putting this in rows mean very long row, not sure it' the way to go.

Allan, paolo, any more changes ?

Created attachment 281042 [details]
horiz

I was thinking of this alternative. It wastes a bit of space but I do not think it is a big problem and I like that the buttons are near the button pressed on the headerbar and I think the position makes more clear that the "select" button is not the confirmation button for the the list selection.


The mockup is just a collage of Allan's, due to my limited gimp skills :)


Ideall I would make the list even wider.


I would also like to experiment with larger rows in the list that have

---------------------------
filename (in black)
/path/to/filename (in gray)
---------------------------

(In reply to comment #17)
> Created an attachment (id=281042) [details]
> horiz
> 
> I was thinking of this alternative. It wastes a bit of space but I do not think
> it is a big problem and I like that the buttons are near the button pressed on
> the headerbar and I think the position makes more clear that the "select"
> button is not the confirmation button for the the list selection.
> 
> 
> The mockup is just a collage of Allan's, due to my limited gimp skills :)
> 
> 
> Ideall I would make the list even wider.
> 
> 
> I would also like to experiment with larger rows in the list that have
> 
> ---------------------------
> filename (in black)
> /path/to/filename (in gray)
> ---------------------------
That's what I was thinking of, and with your layout it might really work. I agree with slaf that paths might get long, but I don't think we have to show the full path, the last three path segments should be enough for identifying the file.

Created attachment 281049 [details]
gedit file popover row style

(In reply to comment #19)
> Created an attachment (id=281049) [details]
> gedit file popover row style

I love that, that's fairly good. /home/USER is usually redundant, Maybe doing the same thing as nautilus in the locationbar (/home/USER replaced with a house icon or ~) would result in shorter urls.

(In reply to comment #20)
> /home/USER is usually redundant, Maybe doing
> the same thing as nautilus in the locationbar (/home/USER replaced with a house
> icon or ~) would result in shorter urls.


slaf: we already have an utility for that that's used for the title and tab tooltips

I need to extract the scheme part of the uri for non-local files, show it in another color i think, and also remove the file part from the path name.

(In reply to comment #17)
> Created an attachment (id=281042) [details]
> horiz
> 
> I was thinking of this alternative. It wastes a bit of space but I do not think
> it is a big problem and I like that the buttons are near the button pressed on
> the headerbar and I think the position makes more clear that the "select"
> button is not the confirmation button for the the list selection.
...

I'm not a fan of having a horizontal layout like this. Visually it's not great with all that space, but more than that, it's not as convenient having to do a horizontal movement to get to the list.

If you think that the open and new buttons are more important, or will be more commonly used, it's a simple matter to move them to the top of the popover.

(In reply to comment #16)
> Hi Robert,
> 
> Don't pay too much attention to rows style, it's just a matter of css to change
> it, we just wait for green light from design team before refinement.
> 
> For the path part, this patch have tooltips, putting this in rows mean very
> long row, not sure it' the way to go.
> 
> Allan, paolo, any more changes ?

I definitely wouldn't include the path in a tooltip - they're tricky and slow to access that way, and will be someone difficult to parse.

Adding each file's directory to the list is an option, although I am a little nervous about adding a lot of detail there - it could become quite noisy/information-dense, which would make it more work to use.

After quite a bit of back on forth on #gnome-design, we've agreed on the following design:

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/gedit/png/document-popover.png

Yes, that's perfect -- the separate New and Open buttons are important since without those, it'd be even more difficult to find how to open a file.

Created attachment 281154 [details]
final screenshot

For the code it's done but it need a little clean up so tomorrow.

Be sure to use the right ellipses character: … rather than ...

https://wiki.gnome.org/Design/HIG/Typography

Created attachment 281173 [details] [review]
file dialog popover

And thanks michael for showing me the way of proper ellipsis character.

Review of attachment 281173 [details] [review]:

::: gedit/Makefile.am
@@ -104,1 @@
 	gedit/gedit-file-chooser-dialog.h	\

I do not like the naming:

1) it is not a dialog
2) I prefer to talk about document instead of file
3) it does not say it is for *opening* stuff

(and this also applies to var names etc in the other parts of the patch)

gedit-open-document-popover?
gedit-open-document-selector?

other suggestions?

::: gedit/gedit-file-dialog.c
@@ +1,2 @@
+/*
+ * gedit-highlight-mode-selector.c

cut & paste error :-)

@@ +64,3 @@
+/* Properties */
+enum {
+	GTK_RECENT_CHOOSER_PROP_FIRST = 0x3000,

why this offset? if there is a valid reason it is surely worth a comment in the code

@@ +346,3 @@
+
+	/* these we own */
+	if (filter_info.applications) g_strfreev ((gchar **) filter_info.applications);

please no if in a single line

@@ +353,3 @@
+
+static GList *
+_gtk_recent_chooser_get_items (GtkRecentChooser  *chooser,

no need for _ prefix if it is static

@@ +390,3 @@
+		gboolean remove_item = FALSE;
+
+		if (filter && get_is_recent_filtered (filter, info)) remove_item = TRUE;

carriage returns are for free this summer

::: gedit/gedit-window.c
@@ +1822,3 @@
 	GeditWindow *window = GEDIT_WINDOW (data);
 
+	gboolean gear_menu_state =

let's split var declaration and assignment, especially since lines are so long

@@ +2437,3 @@
 		gtk_revealer_set_reveal_child (GTK_REVEALER (window->priv->fullscreen_controls), FALSE);
 	}
 }

missing empty line

@@ +2943,3 @@
 
+	/* We want the 'New' buttons to have the same height as other headerbar buttons
+	 * so we keep image-button class in .ui file and remove text-button */

I do not think this hack is necessary, if they do not have the same height, let's bug Lapo to fix adwaita

::: gedit/gedit-window.ui
@@ +35,3 @@
             </style>
             <child>
+              <object class="GtkButton" id="file_new_button">

simply new_button (I would not care, but since the name is used for the var in the template it matters)

@@ -41,1 +46,1 @@
                 <style>

In the mockups this was a text-button with "New"

@@ +50,3 @@
             </child>
             <child>
+              <object class="GtkMenuButton" id="file_open_button">

simply open_button

@@ -82,2 +57,2 @@
                 <style>
                   <class name="image-button"/>

text-button

Created attachment 281190 [details] [review]
gedit-open-document-selector

commited as d4e498b