Can you provide the complete gsettings command so we can test this bug more quickly?

I'm not the original reporter, but I have the same problem. I set with dconf-editor:

    org.gnome.desktop.wm.button-layout

to:

    close:appmenu

When doing that, the close button is shown left aligned (but warning: if you change it, you must restart your session in order to some GTK3 apps to apply the change). In Gedit, by default, it is also shown at left, but when enabling the left panel, the close button is hidden.

I can also confirm the same behavior.

output of gsettings get org.gnome.desktop.wm.preferences button-layout
'close:appmenu'

Created attachment 312983 [details] [review]
Enables GEdit's left panel to show, if needed, the close button

Review of attachment 312983 [details] [review]:

See the comment inline. Also I have some questions about this patch since I did not look at the code. Why is the close button set to true by default on the side bar? I would expect it to be true just when using the left buttons...

::: gedit/gedit-window.c
@@ +2374,2 @@
 			layout_headerbar = g_strdup_printf ("%c%s", ':', tokens[1]);
+			layout_headerbar2 = g_strdup_printf ("%s%c",  tokens[0], ':');

let's call it layout_side_headerbar to be consistent with the other variable

Hi:

Here is the new patch with the variable name changed.

About your question: the "show-close-button" property only determines whether the window decorations are shown or not, but not which ones. That is determined by the decoration layout. Here are more details:

https://developer.gnome.org/gtk3/stable/GtkHeaderBar.html#GtkHeaderBar--show-close-button

Gedit creates two header bars, and put one (headerbar) in the main part of the main window, and the other one (side_headerbar) in the left panel. The current code in Gedit knows when the left panel is hiden (in which case it will set the full layout in headerbar) or visible (in which case it will cut the layout in two halves, one with the left decorations, which will be assigned to side_headerbar, and another with the right decorations, assigned to headerbar).

Unfortunately this doesn't work fine because the UI file forgets to enable show-close-button in side_headerbar, and that's why the close button isn't show at the left, but is shown at the right (headerbar has show-close-button enabled).

The code modifications in gedit-window.c aren't really needed (the patch works without them) but they make this trick more strict, by ensuring that both layouts contains the colon used as separator.

Created attachment 313025 [details] [review]
Enables GEdit's left panel to show, if needed, the close button. Fixed variable name.

If you prefer, I can remove the changes in gedit-window.c and keep only the ones in gedit-window.ui, which are the only really needed to fix the bug.

I closed the pull request in the github account. I think it's better to stay with this one only.

BTW: maybe the right way to go, for future cases, is to add to GtkHeaderBar two boolean properties (by default set to TRUE), that specifies whether that header bar should show the left layout, the right layout, both, or none.

Created attachment 313182 [details] [review]
Enables GEdit's left panel to show, if needed, the close button. Only UI changes.

Enables GEdit's left panel to show, if needed, the close button. This patch contains only the minimal changes needed to make it work, which is to enable "show_close_button" property in the side_headerbar, and doesn't contain the changes in the code to make it more strict.

Use this patch instead of the old one if you consider that the code changes should not be added.

Review of attachment 313025 [details] [review]:

See the comment.

::: gedit/resources/ui/gedit-window.ui
@@ +17,3 @@
             <property name="visible" bind-source="side_panel" bind-property="visible" bind-flags="sync-create"/>
             <property name="title" translatable="yes">Documents</property>
+            <property name="show_close_button">True</property>

why is this set to true here?

Review of attachment 313182 [details] [review]:

I do not like this patch. That property I guess should be set programmatically? Also you are modifying the submodule by mistake

That property is also set in the .ui file for the other panel, that's why I put that there.

Here is the code for the other side bar, the main one:

          <object class="GtkHeaderBar" id="headerbar">
            <property name="visible">True</property>
            <property name="show_close_button">True</property>
            <style>
              <class name="titlebar"/>
            </style>
            <child>


What do you mean with "modifying the submodule by mistake"?

> What do you mean with "modifying the submodule by mistake"?

the patch has this change

"--- a/libgd	
+++ a/libgd	
@@ -1, +0,0 @@ 
-Subproject commit 5ee5a6e576626ff76f1204392faf78751496ff84
"

that's wrong

Yes, that's wrong... I don't know why it has that...

Created attachment 316184 [details] [review]
Enables GEdit's left panel to show, if needed, the close button. Only UI changes, patch fixed

Removed the part about libgd, which should not be there.

Fixed the patch.

Could you fix it and maybe use git format-patch to attach the updated one (https://wiki.gnome.org/Git/Developers#Contributing_patches)?

note also that the "documents" button is not properly centered when decorations are displayed on the left, but that's probably a different issue

Created attachment 316187 [details] [review]
Enables GEdit's left panel to show, if needed, the close button. Only UI changes, patch adapted to git format.

The commit 2e799694043c232bafda0fb1e2272458a66e6995 (16 oct. 2015) added the "show_close_button" and set it to false. That's why this patch now replaces the line, instead of just adding it like in old patches.

The "documents" button is centered between the close button and the container border. To fix that I suspect a change in GTK must be done...

Created attachment 316188 [details] [review]
Enables GEdit's left panel to show, if needed, the close button. Only UI changes, patch now REALLY in git format.

Used "format-patch" instead of "diff".

Review of attachment 316188 [details] [review]:

LGTM, maintainers?

Tweak Tool likely has this problem as well, did you check?

Review of attachment 316188 [details] [review]:

I did not test this, but it does not look correct to me: I expect that changing from False to True will fix one case and break the other.
My guess is that we need to add code that detects the current setup and sets that property accordingly.

Or am I missing something?

Also, please make sure to follow the git conventions for the commit message (one short subject line of max 72 chars, one empty line, and then the full description)

Paolo Borelli: the code is already in GEdit, but, due to some mistake, the programmer forgot to add this "True". It doesn't break anything, it just makes it work.

Michale Catanzaro: if you are talking about "Gnome Tweak Tool", it works fine with close button at the left...

So... will this patch be added in Gedit 3.20.2? Maybe in Gedit 3.22.0?

Created attachment 327906 [details] [review]
Patch that follows the git conventions

Ok, I think now the patch follows the git conventions. Please, try it. You will see that it works fine.

It's been a year since the last version of the patch. Has everyone forgotten about it?

It seems that this has been forgotten. But until they remember, you can try an extension I wrote to fix this. You can download it from my homepage:

http://www.rastersoft.com/programas/gedit_closebutton.html

I have close button on the right, so I don't really need it. Maybe it would be a good idea to ask gedit maintainer directly?

Sorry, I originally reported this but somehow lost track. This bug still makes it difficult to close gedit windows on left-aligned systems.

Sergio, thank you for submitting this patch. I have gone ahead and pushed this to gedit master now. Ubuntu has included this patch for the past year and a half without a problem. I apologize that it did not get applied sooner. gedit is undermaintained right now so it's more likely that patches will not be seen promptly.

https://git.gnome.org/browse/gedit/commit/?id=2d7369a01

Review of attachment 327906 [details] [review]:

.