On 05/11/2012 22:45, Lex Trotman wrote:
I can't find the mail with the patch quickly so I havn't looked at it.
I've attached a trailing-space stripped version of it (I had to convert
the line-endings CRLF -> LF for git, and my project prefs stripped the
spaces).
On 6 November 2012 02:02, Colomban Wendling <lists....@herbesfolles.org>wrote:
Le 03/05/2012 13:41, Quentin Glidic a écrit :
Hello,
Hi,
Attached a little patch concerning the file saving dialog.
I may have missed some use cases, but it works on all cases mentioned in
the commit message.
The main point is about the “Rename†, the unsaved file one (last
commit message line) is a bonus.
I agree that "Open in new tab" shouldn't have precedence over "Rename".
The patch looks like it removes the disabling of Rename so it is always
enabled. I'm not sure that's a good idea, but then the 'Open in new tab'
checkbox should probably be a button itself - only it would make the
buttons too wide with that caption. 'Open in new tab' is not an action
that should typically be repeated.
However, I'm not completely sure about the change on "Open in new tab"
behavior, e.g. that it has no effect either when renaming or when the
file wasn't yet saved. Upon rename, I agree it doesn't seem to make
much sense, because the original tab would become "orphaned", and would
show a "hey, I'm not found on disk!". But I can imagine one would save
to file while keeping the unsaved buffer open (maybe to save it to
another file again later on) -- OK, I don't have such use-case myself.
It makes sense to me when used on the save-as dialog, ie keep the old file
open in another tab as well as saving this one under a new filename. But I
agree it doesn't make sense on rename, but how to know that the user is
going to rename to grey it out?
But neither open in new tab or rename makes sense on the save dialog, its
just that we are too lazy to define different save dialog versions IIUC :)
If save and save-as are to remain the same dialog then only save and cancel
should be sensitive on the save dialog.
Personally I would make Rename a separate command in the File menu.
'Open in new tab' could perhaps be superseded by File->'Save a Copy'.
The user could then open the saved copy from the recent files menu if
they want. This would be clearer and more intuitive than the current
'Open in new tab' behaviour.
So, on this subject, open question: what do other think? I'm OK with
the proposed behavior, but as said I could understand somebody wanting
to keep "open in new tab" with unsaved files; but if no one cares it
probably makes the thing more intuitive to remove it (e.g. no unsaved
file after save).
I would be in favour of removing 'Open in new tab'.
Anyway, the UI should reflect the behavior, e.g. the "Open in new tab"
checkbox should be sensitive only if it will be used (with your patch,
when doc->file_name != NULL).
+1
>From 8ccb3bffad52c7bd9053e945dbb888f944151be9 Mon Sep 17 00:00:00 2001
From: Quentin Glidic <sardemff7+...@sardemff7.net>
Date: Thu, 3 May 2012 13:22:49 +0200
Subject: [PATCH] More consistent behavior for open new tab / rename
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
“Rename� is a button, so a conscious user action while “Open file in a
new tab� is a checkbox, more like a setting.
When a user wants to rename a file, she/he has to uncheck the box, which
is annoying when the new tab behavior is wanted in all other cases
There was also a little bug: the “Rename� button was not deactivated if
the saved state of the box was checked, leading to a duplicated file
when the user expected a rename
Here, we consider the button as an action i.e. prevalent on the
checkbox, which is considered as a setting
Also, when a file is unsaved, we don’t create a new tab for it
---
src/dialogs.c | 40 ++++++++++++++--------------------------
1 file changed, 14 insertions(+), 26 deletions(-)
diff --git a/src/dialogs.c b/src/dialogs.c
index 58b32f9..d06a280 100644
--- a/src/dialogs.c
+++ b/src/dialogs.c
@@ -487,12 +487,6 @@ void dialogs_show_open_file(void)
}
-static void on_save_as_new_tab_toggled(GtkToggleButton *togglebutton, gpointer
user_data)
-{
- gtk_widget_set_sensitive(GTK_WIDGET(user_data), !
gtk_toggle_button_get_active(togglebutton));
-}
-
-
static gboolean handle_save_as(const gchar *utf8_filename, gboolean
open_new_tab, gboolean rename_file)
{
GeanyDocument *doc = document_get_current();
@@ -500,27 +494,24 @@ static gboolean handle_save_as(const gchar
*utf8_filename, gboolean open_new_tab
g_return_val_if_fail(NZV(utf8_filename), FALSE);
- if (open_new_tab)
- { /* "open" the saved file in a new tab and switch to it */
- doc = document_clone(doc, utf8_filename);
- success = document_save_file_as(doc, NULL);
- }
- else
+ if (doc->file_name != NULL)
{
- if (doc->file_name != NULL)
+ if (rename_file)
{
- if (rename_file)
- {
- document_rename_file(doc, utf8_filename);
- }
- /* create a new tm_source_file object otherwise
tagmanager won't work correctly */
- tm_workspace_remove_object(doc->tm_file, TRUE, TRUE);
- doc->tm_file = NULL;
+ document_rename_file(doc, utf8_filename);
}
- success = document_save_file_as(doc, utf8_filename);
-
- build_menu_update(doc);
+ else if (open_new_tab)
+ { /* "open" the saved file in a new tab and switch to it
*/
+ doc = document_clone(doc, utf8_filename);
+ success = document_save_file_as(doc, NULL);
+ }
+ /* create a new tm_source_file object otherwise tagmanager
won't work correctly */
+ tm_workspace_remove_object(doc->tm_file, TRUE, TRUE);
+ doc->tm_file = NULL;
}
+ success = document_save_file_as(doc, utf8_filename);
+
+ build_menu_update(doc);
return success;
}
@@ -616,9 +607,6 @@ static GtkWidget *create_save_file_dialog(void)
g_free(linitdir);
}
- g_signal_connect(check_open_new_tab, "toggled",
- G_CALLBACK(on_save_as_new_tab_toggled),
rename_btn);
-
ui_hookup_widget(dialog, check_open_new_tab, "check_open_new_tab");
return dialog;
--
1.7.10
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel