Hi,
I'm struggling with an issue: GTK focus lost when last document closed.
To grab the focus by a plugin (eg. filebrowser) on such case would be an easy task, but not right, because the user can open documents from many widgets, the focus should return there.
I tried for a while with gtk_container_set_focus_chain() but no luck. Maybe my bad, I have no experience with GTK.
Other, simple solution if Geany provides a new API call. eg.: void ui_focus_history_push(GtkWidget *widget); and widgets/plugins can call it on focus-out-event, so Geany (or a plugin) can restore the focus if there is no better strategy.
Another solution to extend document_open_file(const gchar *locale_filename, gboolean readonly, GeanyFiletype *ft, const gchar *forced_enc) with "GtkWidget *widget" or introduce a new function like document_open_file_from_widget(const gchar *locale_filename, gboolean readonly, GeanyFiletype *ft, const gchar *forced_enc, GtkWidget *widget) to store opening widget with the document, but I think this can cause weird behavior if the last closed document were opened from a dialog window.
How should I fix it?
-- Roland Pallai
On 27 May 2013 07:51, Pallai Roland pallair@magex.hu wrote:
Hi,
I'm struggling with an issue: GTK focus lost when last document closed.
Can you describe more clearly what the problem you are trying to solve is? AFAICT Geany retains focus after the last document is closed.
Cheers Lex
To grab the focus by a plugin (eg. filebrowser) on such case would be an easy task, but not right, because the user can open documents from many widgets, the focus should return there.
I tried for a while with gtk_container_set_focus_chain() but no luck. Maybe my bad, I have no experience with GTK.
Other, simple solution if Geany provides a new API call. eg.: void ui_focus_history_push(GtkWidget *widget); and widgets/plugins can call it on focus-out-event, so Geany (or a plugin) can restore the focus if there is no better strategy.
Another solution to extend document_open_file(const gchar *locale_filename, gboolean readonly, GeanyFiletype *ft, const gchar *forced_enc) with "GtkWidget *widget" or introduce a new function like document_open_file_from_widget(const gchar *locale_filename, gboolean readonly, GeanyFiletype *ft, const gchar *forced_enc, GtkWidget *widget) to store opening widget with the document, but I think this can cause weird behavior if the last closed document were opened from a dialog window.
How should I fix it?
-- Roland Pallai
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Reproduction:
1. set new_document_after_close and auto focus widgets to off in preferences 2. open a file from file/tree browser or "find in files" search results 3. close the document with shortcut
I expect the focus will jump back where were before. Actual result is no widget with focus (the window still has the focus of course).
I used the the following snippet to debug:
void get_focused_widget(gpointer data) { GtkWidget *widget = gtk_window_get_focus(GTK_WINDOW(main_widgets.window)); printf("focused widget: %s\n", gtk_widget_get_name(widget)); } g_timeout_add(1000, (GSourceFunc)get_focused_widget, NULL);
Result of an open-close cycle from tree browser:
focused widget: GtkTreeView [...] focused widget: Scintilla [...] focused widget: (null)
2013/5/27 Lex Trotman elextr@gmail.com
On 27 May 2013 07:51, Pallai Roland pallair@magex.hu wrote:
Hi,
I'm struggling with an issue: GTK focus lost when last document closed.
Can you describe more clearly what the problem you are trying to solve is? AFAICT Geany retains focus after the last document is closed.
Cheers Lex
To grab the focus by a plugin (eg. filebrowser) on such case would be an easy task, but not right, because the user can open documents from many widgets, the focus should return there.
I tried for a while with gtk_container_set_focus_chain() but no luck. Maybe my bad, I have no experience with GTK.
Other, simple solution if Geany provides a new API call. eg.: void ui_focus_history_push(GtkWidget *widget); and widgets/plugins can call it on focus-out-event, so Geany (or a plugin) can restore the focus if there is no better strategy.
Another solution to extend document_open_file(const gchar *locale_filename, gboolean readonly, GeanyFiletype *ft, const gchar *forced_enc) with "GtkWidget *widget" or introduce a new function like document_open_file_from_widget(const gchar *locale_filename, gboolean readonly, GeanyFiletype *ft, const gchar *forced_enc, GtkWidget *widget) to store opening widget with the document, but I think this can cause weird behavior if the last closed document were opened from a dialog window.
How should I fix it?
-- Roland Pallai
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 27 May 2013 18:24, Pallai Roland pallair@magex.hu wrote:
Reproduction:
- set new_document_after_close and auto focus widgets to off in
preferences 2. open a file from file/tree browser or "find in files" search results 3. close the document with shortcut
I expect the focus will jump back where were before. Actual result is no widget with focus (the window still has the focus of course).
I used the the following snippet to debug:
void get_focused_widget(gpointer data) { GtkWidget *widget = gtk_window_get_focus(GTK_WINDOW(main_widgets.window)); printf("focused widget: %s\n", gtk_widget_get_name(widget)); } g_timeout_add(1000, (GSourceFunc)get_focused_widget, NULL);
Result of an open-close cycle from tree browser:
focused widget: GtkTreeView [...] focused widget: Scintilla [...] focused widget: (null)
Ok, now I see what you are on about.
I see several problems with the proposal:
1) What is the "correct" behaviour? As you say there are several open methods, do I return to the method used for the particular file that was closed last, even though I had opened many other files using a different widget since that file was opened. I would have said that the most recently used method might be more likely to be the one I want. And some I probably don't want to return to, eg if the file was opened from a compiler error message and as you say having a dialog open automatically is wrong too.
2) Methods of opening files are provided by plugins, filebrowser being the initial example, but treebrowser and the project plugins being other options. Geany does not know about what plugins can do for opening files, and passing a widget pointer to Geany is risky since the plugin may have been closed in the meantime and the widget deleted. Trying to use that is a likely crash.
In general this is a situation where Geany can't assume what the user wants to do, it is better to let the user focus something via the mouse or keybinding.
Cheers Lex
2013/5/27 Lex Trotman elextr@gmail.com
On 27 May 2013 07:51, Pallai Roland pallair@magex.hu wrote:
Hi,
I'm struggling with an issue: GTK focus lost when last document closed.
Can you describe more clearly what the problem you are trying to solve is? AFAICT Geany retains focus after the last document is closed.
Cheers Lex
To grab the focus by a plugin (eg. filebrowser) on such case would be an easy task, but not right, because the user can open documents from many widgets, the focus should return there.
I tried for a while with gtk_container_set_focus_chain() but no luck. Maybe my bad, I have no experience with GTK.
Other, simple solution if Geany provides a new API call. eg.: void ui_focus_history_push(GtkWidget *widget); and widgets/plugins can call it on focus-out-event, so Geany (or a plugin) can restore the focus if there is no better strategy.
Another solution to extend document_open_file(const gchar *locale_filename, gboolean readonly, GeanyFiletype *ft, const gchar *forced_enc) with "GtkWidget *widget" or introduce a new function like document_open_file_from_widget(const gchar *locale_filename, gboolean readonly, GeanyFiletype *ft, const gchar *forced_enc, GtkWidget *widget) to store opening widget with the document, but I think this can cause weird behavior if the last closed document were opened from a dialog window.
How should I fix it?
-- Roland Pallai
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
2013/5/27 Lex Trotman elextr@gmail.com
On 27 May 2013 18:24, Pallai Roland pallair@magex.hu wrote: I see several problems with the proposal:
- What is the "correct" behaviour? As you say there are several open methods, do I return to the method used for the particular file that was closed last, even though I had opened many other files using a different widget since that file was opened. I would have said that the most recently used method might be more likely to be the one I want. And some I probably don't want to return to, eg if the file was opened from a compiler error message and as you say having a dialog open automatically is wrong too.
No correct behaviour, just ordinary what you had described: return to the most recent activity if an activity finished. This is a common UI behaviour and expected by users, no one will complain about it.
Yes, there are cases when return of activity a., is not possible: skip this activity and see next. b., is not sane: the default widget behaviour would be "do not return the focus here" and we have to agree on the exceptions (eg. filesystem browsers, search results - widgets that contains file lists and typically used to open files - IMHO it's pretty trivial.)
- Methods of opening files are provided by plugins, filebrowser being the initial example, but treebrowser and the project plugins being other options. Geany does not know about what plugins can do for opening files, and passing a widget pointer to Geany is risky since the plugin may have been closed in the meantime and the widget deleted. Trying to use that is a likely crash.
Agreed, passing a widget pointer to Geany is risky, I have no good solution now. Now I thinking about a signal-based solution (based on Qt experiences) but I have to dig into GTK for the details.
In general this is a situation where Geany can't assume what the user wants to do, it is better to let the user focus something via the mouse or keybinding.
I do not agree on this: we can guess right based on common UI traditions. If we guess badly, the user have to focus manually just as before - worth to try.
Do you agree that the problem exists and should be solved? Will you commit my patch if I find a good solution?
Cheers Lex
2013/5/27 Lex Trotman elextr@gmail.com
On 27 May 2013 07:51, Pallai Roland pallair@magex.hu wrote:
Hi,
I'm struggling with an issue: GTK focus lost when last document closed.
Can you describe more clearly what the problem you are trying to solve is? AFAICT Geany retains focus after the last document is closed.
Cheers Lex
To grab the focus by a plugin (eg. filebrowser) on such case would be an easy task, but not right, because the user can open documents from many widgets, the focus should return there.
I tried for a while with gtk_container_set_focus_chain() but no luck. Maybe my bad, I have no experience with GTK.
Other, simple solution if Geany provides a new API call. eg.: void ui_focus_history_push(GtkWidget *widget); and widgets/plugins can call it on focus-out-event, so Geany (or a plugin) can restore the focus if there is no better strategy.
Another solution to extend document_open_file(const gchar *locale_filename, gboolean readonly, GeanyFiletype *ft, const gchar *forced_enc) with "GtkWidget *widget" or introduce a new function like document_open_file_from_widget(const gchar *locale_filename, gboolean readonly, GeanyFiletype *ft, const gchar *forced_enc, GtkWidget *widget) to store opening widget with the document, but I think this can cause weird behavior if the last closed document were opened from a dialog window.
How should I fix it?
-- Roland Pallai
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Hi,
Le 27/05/2013 13:22, Pallai Roland a écrit :
2013/5/27 Lex Trotman elextr@gmail.com
On 27 May 2013 18:24, Pallai Roland pallair@magex.hu wrote: I see several problems with the proposal:
- What is the "correct" behaviour? As you say there are several
open methods, do I return to the method used for the particular file that was closed last, even though I had opened many other files using a different widget since that file was opened. I would have said that the most recently used method might be more likely to be the one I want. And some I probably don't want to return to, eg if the file was opened from a compiler error message and as you say having a dialog open automatically is wrong too.
No correct behaviour, just ordinary what you had described: return to the most recent activity if an activity finished. This is a common UI behaviour and expected by users, no one will complain about it.
Hum, it's probably either so well done or not done at all I never saw it anywhere.
Generally what applications do is that e.g. when closing a document in a tabbed document view, it switches to another document (either left or right tab, or MRU one) -- and that's what we do, which I find consistent.
In my personal usage, I would find it *very* annoying to get the focus out of the documents when I close one: why would you expect me to return to opening a file and not edit another open one?
And if it's only when closing the very last open document, I'd think it's much ado about nothing. If it's a problem the focus is nowhere, I would think we could chose an arbitrary thing to focus that would maybe make you or 1% of people happier without messing up with an overcomplicated solution to a non-existent problem (IMHO).
Yes, there are cases when return of activity a., is not possible: skip this activity and see next. b., is not sane: the default widget behaviour would be "do not return the focus here" and we have to agree on the exceptions (eg. filesystem browsers, search results - widgets that contains file lists and typically used to open files - IMHO it's pretty trivial.)
- Methods of opening files are provided by plugins, filebrowser
being the initial example, but treebrowser and the project plugins being other options. Geany does not know about what plugins can do for opening files, and passing a widget pointer to Geany is risky since the plugin may have been closed in the meantime and the widget deleted. Trying to use that is a likely crash.
Agreed, passing a widget pointer to Geany is risky, I have no good solution now. Now I thinking about a signal-based solution (based on Qt experiences) but I have to dig into GTK for the details.
This is a false technical problem, we could very well listen to the :destroy signal of the widget and pop it out of a queue.
In general this is a situation where Geany can't assume what the user wants to do, it is better to let the user focus something via the mouse or keybinding.
I do not agree on this: we can guess right based on common UI traditions. If we guess badly, the user have to focus manually just as before - worth to try.
...so IIUC what you try to fix is the focus when the last document tab is closed? So I really think it's much ado about (almost) nothing, because
1) many (I would have said "most") users have many tabs open and even sometime don't ever close them all (so don't encounter the issue);
2) we have a setting to make sure there is always a document open (so users don't encounter the issue);
3) many users use mostly the mouse, so they don't even care about focus location in this case.
Do you agree that the problem exists
Somewhat, yes. I mean, the focus indeed gets nowhere when closing the last open document if the setting `new_document_after_close` is off.
and should be solved?
Honestly, I don't care.
Will you commit my patch if I find a good solution?
Maybe, if it's small and simple. But I probably won't accept a huge queue-based focus history for this, because the waste of resources and code complexity wouldn't be worth what they fix.
Regards, Colomban
2013/5/27 Colomban Wendling lists.ban@herbesfolles.org:
Le 27/05/2013 13:22, Pallai Roland a écrit :
No correct behaviour, just ordinary what you had described: return to the most recent activity if an activity finished. This is a common UI behaviour and expected by users, no one will complain about it.
Hum, it's probably either so well done or not done at all I never saw it anywhere.
Maybe I was very abstract here: I just want consistent widget focus when I close the very last document.
In my personal usage, I would find it *very* annoying to get the focus out of the documents when I close one: why would you expect me to return to opening a file and not edit another open one?
Me too. (The "edit documents" activity does not finish when a document closed of many -I did not talk about changing this behaviour-, finished when the _very last_ document closed. Anyway, forget this activity thing, I'll talk about "closing the very last document" from now.)
And if it's only when closing the very last open document, I'd think it's much ado about nothing. If it's a problem the focus is nowhere, I would think we could chose an arbitrary thing to focus that would maybe make you or 1% of people happier without messing up with an overcomplicated solution to a non-existent problem (IMHO).
Maybe enough in practice, this is what NetBeans does for example. I use Geany this way in practice currently (by patched plugins), but I see the shortcomings of this method, surfing over results of 'find in files' could be much convenient for example.
I'll propose this simple method if other solutions are coming down to an overcomplicated implementation.
Agreed, passing a widget pointer to Geany is risky, I have no good solution now. Now I thinking about a signal-based solution (based on Qt experiences) but I have to dig into GTK for the details.
This is a false technical problem, we could very well listen to the :destroy signal of the widget and pop it out of a queue.
Thanks for the hint!
...so IIUC what you try to fix is the focus when the last document tab is closed?
Yes.
So I really think it's much ado about (almost) nothing, because
- many (I would have said "most") users have many tabs open and even
sometime don't ever close them all (so don't encounter the issue);
- we have a setting to make sure there is always a document open (so
users don't encounter the issue);
- many users use mostly the mouse, so they don't even care about focus
location in this case.
Agreed, depends on habit and workflow, hard to tell how many (potential) users are affected. Anyway, great IDEs and text editors I have used has consistent focus strategy so the need is out there.
Will you commit my patch if I find a good solution?
Maybe, if it's small and simple. But I probably won't accept a huge queue-based focus history for this, because the waste of resources and code complexity wouldn't be worth what they fix.
OK
On Mon, 27 May 2013 13:22:02 +0200 Pallai Roland pallair@magex.hu wrote:
Do you agree that the problem exists and should be solved?
No. If Geany supported several main activities, such as browsing interface objects and clicking on their event handlers to edit the code behind, or browsing a database and clicking an object to edit it's definition as SQL text, it would have made sense, because the editor windows would have been specialized.
Maybe I was very abstract here: I just want consistent widget focus when I close the very last document.
But not any other document... Attempting to marry activities with Geany's general purpose text editors can't produce consistent results.
Aside from a plugin being unavailable, the widget from which a file was open may be in an unsuitable state: for example a set of Messages, which are not result of "Find in Files", or Scope Threads/Stack, after the program was terminated.
How should I fix it?
For Messages, including "Find in Files" matches, you can assign shortcuts for the "Next message" and "Previous message". Strangely enough, the keys do not work if the last file is closed, although the menu items work just file. Bug?..
2013/5/27 Dimitar Zhekov dimitar.zhekov@gmail.com:
On Mon, 27 May 2013 13:22:02 +0200 Pallai Roland pallair@magex.hu wrote:
Do you agree that the problem exists and should be solved?
No. If Geany supported several main activities, such as browsing interface objects and clicking on their event handlers to edit the code behind, or browsing a database and clicking an object to edit it's definition as SQL text, it would have made sense, because the editor windows would have been specialized.
Maybe I was very abstract here: I just want consistent widget focus when I close the very last document.
But not any other document... Attempting to marry activities with Geany's general purpose text editors can't produce consistent results.
Please forget word "activities", it has taken us too far from the point IMHO.
Aside from a plugin being unavailable, the widget from which a file was open may be in an unsuitable state: for example a set of Messages, which are not result of "Find in Files", or Scope Threads/Stack, after the program was terminated.
In worst case we give focus to the wrong widget. Not worse than lost focus, isn't it? If the implementation is simple and stable, why not..?
How should I fix it?
For Messages, including "Find in Files" matches, you can assign shortcuts for the "Next message" and "Previous message". Strangely enough, the keys do not work if the last file is closed, although the menu items work just file. Bug?..
It opens every file as I walk through results, definitely not what I want. Furthermore the shortcut really does not work if the last file is closed. :)
A very simple implementation based on your comments: https://github.com/geany/geany/pull/141
I will patch geany-plugins too (treebrowser/projects) if you like it.
2013/5/27 Pallai Roland pallair@magex.hu:
2013/5/27 Dimitar Zhekov dimitar.zhekov@gmail.com:
On Mon, 27 May 2013 13:22:02 +0200 Pallai Roland pallair@magex.hu wrote:
Do you agree that the problem exists and should be solved?
No. If Geany supported several main activities, such as browsing interface objects and clicking on their event handlers to edit the code behind, or browsing a database and clicking an object to edit it's definition as SQL text, it would have made sense, because the editor windows would have been specialized.
Maybe I was very abstract here: I just want consistent widget focus when I close the very last document.
But not any other document... Attempting to marry activities with Geany's general purpose text editors can't produce consistent results.
Please forget word "activities", it has taken us too far from the point IMHO.
Aside from a plugin being unavailable, the widget from which a file was open may be in an unsuitable state: for example a set of Messages, which are not result of "Find in Files", or Scope Threads/Stack, after the program was terminated.
In worst case we give focus to the wrong widget. Not worse than lost focus, isn't it? If the implementation is simple and stable, why not..?
How should I fix it?
For Messages, including "Find in Files" matches, you can assign shortcuts for the "Next message" and "Previous message". Strangely enough, the keys do not work if the last file is closed, although the menu items work just file. Bug?..
It opens every file as I walk through results, definitely not what I want. Furthermore the shortcut really does not work if the last file is closed. :)
On 28 May 2013 07:51, Pallai Roland pallair@magex.hu wrote:
A very simple implementation based on your comments: https://github.com/geany/geany/pull/141
I will patch geany-plugins too (treebrowser/projects) if you like it.
That means adding the new function to the plugin API, documenting it as such and bumping the API version, making the plugin no longer able to run with a Geany earlier than this new version.
Plugins are controlled by their maintainers, not the Geany project, you will have to communicate patches to them if they want to accept the patch, after the Geany changes of course.
Cheers Lex
2013/5/27 Pallai Roland pallair@magex.hu:
2013/5/27 Dimitar Zhekov dimitar.zhekov@gmail.com:
On Mon, 27 May 2013 13:22:02 +0200 Pallai Roland pallair@magex.hu wrote:
Do you agree that the problem exists and should be solved?
No. If Geany supported several main activities, such as browsing interface objects and clicking on their event handlers to edit the code behind, or browsing a database and clicking an object to edit it's definition as SQL text, it would have made sense, because the editor windows would have been specialized.
Maybe I was very abstract here: I just want consistent widget focus when I close the very last document.
But not any other document... Attempting to marry activities with Geany's general purpose text editors can't produce consistent results.
Please forget word "activities", it has taken us too far from the point
IMHO.
Aside from a plugin being unavailable, the widget from which a file was open may be in an unsuitable state: for example a set of Messages, which are not result of "Find in Files", or Scope Threads/Stack, after the program was terminated.
In worst case we give focus to the wrong widget. Not worse than lost focus, isn't it? If the implementation is simple and stable, why not..?
How should I fix it?
For Messages, including "Find in Files" matches, you can assign shortcuts for the "Next message" and "Previous message". Strangely enough, the keys do not work if the last file is closed, although the menu items work just file. Bug?..
It opens every file as I walk through results, definitely not what I want. Furthermore the shortcut really does not work if the last file is closed. :)
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Mon, 27 May 2013 22:12:35 +0200 Pallai Roland pallair@magex.hu wrote:
2013/5/27 Dimitar Zhekov dimitar.zhekov@gmail.com:
Do you agree that the problem exists and should be solved?
No. [...]
[...]
Long story short, why don't you write a plugin that connects to "document-close", and focuses your favorite widget when the last document is closed? That'll certainly be easier and faster than adding a function to the plugin API and convincing all plugin developers to call it, for a reason which may not sound entirely convincing to them.
Being a plugin, you can extend it as you see fit - for example by keeping history of the focused widgets and going back to the last one that still exists, going back on each document close etc.
Finally, a plugin that does something sensible, causes no crashes and avoids dirty hacks, may well be accepted in geany-plugins.
2013/5/28 Dimitar Zhekov dimitar.zhekov@gmail.com:
Long story short, why don't you write a plugin that connects to "document-close", and focuses your favorite widget when the last document is closed? That'll certainly be easier and faster than adding a function to the plugin API and convincing all plugin developers to call it, for a reason which may not sound entirely convincing to them.
Being a plugin, you can extend it as you see fit - for example by keeping history of the focused widgets and going back to the last one that still exists, going back on each document close etc.
I considered this but I have to connect to focus-event signals of plugin's widgets if I want to return to the most recent widget that is not possible or introduces dependencies between plugins and so leads to hell. Return to a fixed "favourite" widget is not enough as I wrote earlier.
Finally, a plugin that does something sensible, causes no crashes and avoids dirty hacks, may well be accepted in geany-plugins.
Unfortunately this plugin could not do any sensible without dirty hacks..
/* It's not about just me, I really believe it makes Geany a bit better. I presented use cases where it has advantages, no known drawbacks, code complexity is very low, using of this feature is optional in plugins, no fully working workaround. Don't get me wrong, but I don't understand this resistance: it changes a behaviour that nobody cared about. I do not want to break or change your workflow. If it helps only 1% of Geany users -as Colomban wrote-, why not..? */
[...]
/* It's not about just me, I really believe it makes Geany a bit better. I presented use cases where it has advantages, no known drawbacks, code complexity is very low, using of this feature is optional in plugins, no fully working workaround. Don't get me wrong, but I don't understand this resistance: it changes a behaviour that nobody cared about. I do not want to break or change your workflow. If it helps only 1% of Geany users -as Colomban wrote-, why not..? */
Ok, to spell it out:
1) when the last tab is closed the only sensible widget to have focus is a general one to open files. Not much of Geany works without a file open, its an editor :)
2) the message window widget does not fit this description, it can only open files that happen to be written there, its is not a general open widget.
3) in fact, even though there are lots of open methods, none of them are available for focus, for example because they are in dialogs (open file/project) or menus (files MRU or projects MRU).
4) as you say, the only one that might make sense is the filebrowser plugin tab in the sidebar, if the filebrowser is in use.
So the proposal is to add something which also needs to bump the plugin API, just to allow a plugin (albeit a core plugin) to do something for 0.001% of users to save one click.
Agree its not much code, but to misuse Colombans phrase, "not much code for nothing".
And it adds another global; value that will have to be disentangled before anyone can look at Geany having multiple windows and other re-entrant capabilities.
Cheers Lex
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Wed, 29 May 2013 00:04:31 +0200 Pallai Roland pallair@magex.hu wrote:
2013/5/28 Dimitar Zhekov dimitar.zhekov@gmail.com:
Long story short, why don't you write a plugin that connects to "document-close", and focuses your favorite widget when the last document is closed? [...]
I considered this but I have to connect to focus-event signals of plugin's widgets if I want to return to the most recent widget [...]
How about connecting to "set-focus-event" of the main Geany window? You will be able to select at least the top level widget to return to. Well, you won't have exact widget...
Or you can track the focus event for the side/down panels only, and attach a panel ID + it's current page to each sci object on "document-open". That'll work almost without exceptions, and you can even add a keybinding to jump back to the page possibly used to open the current document.
It's not about just me, I really believe it makes Geany a bit better. I presented use cases where it has advantages, ...
Does it? ui_add_recent_widget() can only tell us what widget was used to open the most recent document, not the one which was used to open the _last_ remaining document. Considering that the plugin may be removed, or the widget may be in a different state, that's still better than a random "grab-focus"... not much better though.
using of this feature is optional in plugins
How is that an advantage? It'll work even worse.
no known drawbacks,
Except making plugins incompatible with all previous versions of Geany.
code complexity is very low,
Usability too, in it's current form.
Don't get me wrong, but I don't understand this resistance: it changes a behaviour that nobody cared about. If it helps only 1% of Geany users -as Colomban wrote-, why not..?
If it only helps only 1% of Geany users, does not work well, and requires changes to the core and many plugins, why accept it?..
I don't understand this resistance I do not want to break or change your workflow.
Although I don't beleive this feature has a place in Geany, I am still honestly trying to find an implementation that'll will be more useful, and can be implemented without making changes left and right. :)