Hi all,
Currently, when closing the last tab, I get a geany window without any text area.
The attached patch fixes that, by creating a new untitled document when the last tab is closed. I've been running with this patch for over a week.
Cheers, Erik
On Tue, 14 Sep 2010 18:03:52 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Currently, when closing the last tab, I get a geany window without any text area.
The attached patch fixes that, by creating a new untitled document when the last tab is closed. I've been running with this patch for over a week.
Personally I'm not sure about this, see what others think.
Regards, Nick
On Tue, Sep 14, 2010 at 2:23 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
The attached patch fixes that, by creating a new untitled document when the last tab is closed. I've been running with this patch for over a week.
Personally I'm not sure about this, see what others think.
As far as I'm concerned I prefer the patched behaviour. It would be similar to tab handling in web browsers (Opera). Liviu
On 9/14/2010 6:23 AM, Nick Treleaven wrote:
On Tue, 14 Sep 2010 18:03:52 +1000 Erik de Castro Lopomle+tools@mega-nerd.com wrote:
Currently, when closing the last tab, I get a geany window without any text area.
The attached patch fixes that, by creating a new untitled document when the last tab is closed. I've been running with this patch for over a week.
Personally I'm not sure about this, see what others think.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
I also would like this behavior in Geany. Its not much harder to apply the correct syntaxt highlighting (if needed) or just save the file with the correct extension so the proper highlighting gets installed, then to have to create a new document.
Nick Treleaven wrote:
On Tue, 14 Sep 2010 18:03:52 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Currently, when closing the last tab, I get a geany window without any text area.
The attached patch fixes that, by creating a new untitled document when the last tab is closed. I've been running with this patch for over a week.
Personally I'm not sure about this, see what others think.
This is simply what every other app I can think of that uses tabs does when the last tab is closed. With this patch applied geany also has the same look after the last tab is closed as when geany is run without any files on the command line.
Erik
On Tue, 14 Sep 2010 18:03:52 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Currently, when closing the last tab, I get a geany window without any text area.
The attached patch fixes that, by creating a new untitled document when the last tab is closed. I've been running with this patch for over a week.
Well, the responses are all positive. But I don't think that keybindings.c is the best place for this code. What about writing it as an idle callback from document_remove_page?
Regards, Nick
Nick Treleaven wrote:
Well, the responses are all positive. But I don't think that keybindings.c is the best place for this code. What about writing it as an idle callback from document_remove_page?
Actually, doesn't even need a callback. Attached patch moves the code I initially had in keybindings.c to the end of the document_remove_page() function in document.c.
Cheers, Erik
Erik de Castro Lopo wrote:
Nick Treleaven wrote:
Well, the responses are all positive. But I don't think that keybindings.c is the best place for this code. What about writing it as an idle callback from document_remove_page?
Actually, doesn't even need a callback. Attached patch moves the code I initially had in keybindings.c to the end of the document_remove_page() function in document.c.
Actually attached the patch this time.
Erik
On Thu, 16 Sep 2010 08:32:05 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Well, the responses are all positive. But I don't think that keybindings.c is the best place for this code. What about writing it as an idle callback from document_remove_page?
Actually, doesn't even need a callback. Attached patch moves the code I initially had in keybindings.c to the end of the document_remove_page() function in document.c.
Actually attached the patch this time.
Haven't tested, but seems that this would leave a prepended new document when loading a project session. It probably does need the idle callback.
Regards, Nick
Nick Treleaven wrote:
On Thu, 16 Sep 2010 08:32:05 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Well, the responses are all positive. But I don't think that keybindings.c is the best place for this code. What about writing it as an idle callback from document_remove_page?
Actually, doesn't even need a callback. Attached patch moves the code I initially had in keybindings.c to the end of the document_remove_page() function in document.c.
Actually attached the patch this time.
Haven't tested, but seems that this would leave a prepended new document when loading a project session. It probably does need the idle callback.
Ok, I'll have a look. I actually don't use project sessions so I'll have to have a play around.
Erik
Erik de Castro Lopo wrote:
Nick Treleaven wrote:
On Thu, 16 Sep 2010 08:32:05 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Well, the responses are all positive. But I don't think that keybindings.c is the best place for this code. What about writing it as an idle callback from document_remove_page?
Actually, doesn't even need a callback. Attached patch moves the code I initially had in keybindings.c to the end of the document_remove_page() function in document.c.
Actually attached the patch this time.
Haven't tested, but seems that this would leave a prepended new document when loading a project session. It probably does need the idle callback.
Ok, I'll have a look. I actually don't use project sessions so I'll have to have a play around.
Can you give me a idea of how to recreate this problem? I've messed with project files but I'm not exactly sure what to look for,
Cheers, Erik
On Sun, 19 Sep 2010 18:46:47 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Well, the responses are all positive. But I don't think that keybindings.c is the best place for this code. What about writing it as an idle callback from document_remove_page?
Actually, doesn't even need a callback. Attached patch moves the code I initially had in keybindings.c to the end of the document_remove_page() function in document.c.
Haven't tested, but seems that this would leave a prepended new document when loading a project session. It probably does need the idle callback.
Can you give me a idea of how to recreate this problem? I've messed with project files but I'm not exactly sure what to look for,
When opening a project file with project sessions enabled, the first tab is always a new document, which shouldn't be there.
Now committed a change with the idle callback.
Regards, Nick
Nick Treleaven wrote:
When opening a project file with project sessions enabled, the first tab is always a new document, which shouldn't be there.
Now committed a change with the idle callback.
Unfortunately, this does work. With this version, closing the last document does not create a new untitled document, it just leaves me with the default gtk background colour. I'm not using project sessions BTW.
Erik
On Tue, 21 Sep 2010 08:51:30 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
When opening a project file with project sessions enabled, the first tab is always a new document, which shouldn't be there.
Now committed a change with the idle callback.
Unfortunately, this does work. With this version, closing the last document does not create a new untitled document, it just leaves me with the default gtk background colour. I'm not using project sessions BTW.
So closing the last new document doesn't create a new document straight away?
Are you sure you're running current SVN?
Anyway, Frank Lanitz has asked for a pref for this and personally I don't really like the behaviour. Earlier you said:
This is simply what every other app I can think of that uses tabs does when the last tab is closed.
Gedit (2.20) does not do this. Do you have examples of a text editing app with this behaviour?
With this patch applied geany also has the same look after the last tab is closed as when geany is run without any files on the command line.
I think the original behaviour is correct, so users can start an instance and paste or work on a new text file. Always forcing a new text file though might not be what users want, and it's not hard to press Ctrl-N.
Regards, Nick
On Tue, Sep 21, 2010 at 7:54 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
Gedit (2.20) does not do this. Do you have examples of a text editing app with this behaviour?
At least jEdit always keeps an untitled document open. Liviu
On Tue, 21 Sep 2010 17:54:36 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 21 Sep 2010 08:51:30 +1000 Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
With this patch applied geany also has the same look after the last tab is closed as when geany is run without any files on the command line.
I think the original behaviour is correct, so users can start an instance and paste or work on a new text file. Always forcing a new text file though might not be what users want, and it's not hard to press Ctrl-N.
I agree.
Cheers, Frank
Nick Treleaven wrote:
So closing the last new document doesn't create a new document straight away?
Correct.
Are you sure you're running current SVN?
Absolutely. I have checked. Twice.
Anyway, Frank Lanitz has asked for a pref for this and personally I don't really like the behaviour. Earlier you said:
This is simply what every other app I can think of that uses tabs does when the last tab is closed.
Gedit (2.20) does not do this. Do you have examples of a text editing app with this behaviour?
Correct, Gedit doesn't and has the same annoying behaviour that Geany has.
Nedit and jEdit have what I consider the behaviour.
Erik
Le 22/09/2010 02:20, Erik de Castro Lopo a écrit :
Nick Treleaven wrote:
So closing the last new document doesn't create a new document straight away?
Correct.
Are you sure you're running current SVN?
Absolutely. I have checked. Twice.
For me it works perfectly well (SVN r5250). I close the last tab, a new empty one opens right away.
Anyway, Frank Lanitz has asked for a pref for this and personally I don't really like the behaviour. Earlier you said:
This is simply what every other app I can think of that uses tabs does when the last tab is closed.
Gedit (2.20) does not do this. Do you have examples of a text editing app with this behaviour?
I personally see the behavior Erik want as natural (don't know why), but I really don't care about it. That said, I don't see why it is be a problem since a single, fresh, empty tab is closed when opening a file. So perhaps: why *don't* do this? But again, I personally don't care.
Regards, Colomban
Colomban Wendling wrote:
Le 22/09/2010 02:20, Erik de Castro Lopo a écrit :
Nick Treleaven wrote:
So closing the last new document doesn't create a new document straight away?
Correct.
Are you sure you're running current SVN?
Absolutely. I have checked. Twice.
For me it works perfectly well (SVN r5250). I close the last tab, a new empty one opens right away.
Deleted the SVN tree, grabbed a new version and now its working. Thanks.
Erik
On Wed, Sep 22, 2010 at 02:34, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 22/09/2010 02:20, Erik de Castro Lopo a écrit :
Nick Treleaven wrote:
So closing the last new document doesn't create a new document straight away?
Correct.
Are you sure you're running current SVN?
Absolutely. I have checked. Twice.
For me it works perfectly well (SVN r5250). I close the last tab, a new empty one opens right away.
Anyway, Frank Lanitz has asked for a pref for this and personally I don't really like the behaviour. Earlier you said:
This is simply what every other app I can think of that uses tabs does when the last tab is closed.
Gedit (2.20) does not do this. Do you have examples of a text editing app with this behaviour?
I personally see the behavior Erik want as natural (don't know why), but I really don't care about it. That said, I don't see why it is be a problem since a single, fresh, empty tab is closed when opening a file. So perhaps: why *don't* do this? But again, I personally don't care.
And just to keep the number of people who like/dislike this feature balanced, I must say I rather dislike it :-). I find it strange when I press the 'x' button on the tab and the tab reopens again. I had a look at other editors and it works this way:
* editors which have "x" button in the tab to close it do not automatically open empty document (gedit, codeblocks) * editors which don't use tabs or don't have close button in the tab open empty document
In my opinion the only correct way to implement the automatic empty document opening is also to hide tab bar completely when only a single document is open (SciTE does it this way). Actually this would be also nice to save some extra space in the editor for the editing area if people are editing just a single document. Alternatively the "x" button should disappear if a single tab is displayed (firefox works this way).
That said, this is actually not a feature I care much about so can stay the way it is if the majority of people prefer the current behaviour.
Jiri
Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, Sep 22, 2010 at 2:17 PM, Jiří Techet techet@gmail.com wrote:
And just to keep the number of people who like/dislike this feature balanced, I must say I rather dislike it :-). I find it strange when I press the 'x' button on the tab and the tab reopens again. I had a look at other editors and it works this way:
- editors which have "x" button in the tab to close it do not
automatically open empty document (gedit, codeblocks)
- editors which don't use tabs or don't have close button in the tab
open empty document
In my opinion the only correct way to implement the automatic empty document opening is also to hide tab bar completely when only a single document is open (SciTE does it this way).
Personally I tend to prefer having the tabbar displayed at all times, in most tabbed apps.
Actually this would be also nice to save some extra space in the editor for the editing area if people are editing just a single document. Alternatively the "x" button should disappear if a single tab is displayed (firefox works this way).
..if a single _untitled_ tab is displayed. This is the way Opera handles it, and that the behaviour that I find ergonomic in this case; it allows to close the last titled document tab without the need to close the app. As soon as the document gets modified or gets a title, the 'x' should be restored. Midori, Xfce's web browser with 'always show tabbar' enabled, behaves similarly to Opera, although it keeps a non-functional 'x' even on the last empty tab; clicking on the last empty tab doesn't close it/re-open another empty, so I guess the unnecessary 'x' can be reported as a bug.
I'm not sure that this is all worth the effort, but I'd surely love if Geany handled last, empty tabs this way. Regards Liviu
That said, this is actually not a feature I care much about so can stay the way it is if the majority of people prefer the current behaviour.
Jiri
Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Liviu Andronic wrote:
Personally I tend to prefer having the tabbar displayed at all times, in most tabbed apps.
+1
..if a single _untitled_ tab is displayed. This is the way Opera handles it, and that the behaviour that I find ergonomic in this case; it allows to close the last titled document tab without the need to close the app. As soon as the document gets modified or gets a title, the 'x' should be restored. Midori, Xfce's web browser with 'always show tabbar' enabled, behaves similarly to Opera, although it keeps a non-functional 'x' even on the last empty tab; clicking on the last empty tab doesn't close it/re-open another empty, so I guess the unnecessary 'x' can be reported as a bug.
I'm not sure that this is all worth the effort, but I'd surely love if Geany handled last, empty tabs this way.
I'd been fine with that. My problem is with an empty grey background.
Erik
On Wed, 22 Sep 2010 14:43:15 +0300 Liviu Andronic landronimirc@gmail.com wrote:
On Wed, Sep 22, 2010 at 2:17 PM, Jiří Techet techet@gmail.com wrote:
And just to keep the number of people who like/dislike this feature balanced, I must say I rather dislike it :-). I find it strange when I press the 'x' button on the tab and the tab reopens again. I had a look at other editors and it works this way:
I think it wouldn't be so bad if the redraw wasn't so obvious, but that was the safest & easiest way to implement it.
- editors which have "x" button in the tab to close it do not
automatically open empty document (gedit, codeblocks)
- editors which don't use tabs or don't have close button in the tab
open empty document
In my opinion the only correct way to implement the automatic empty document opening is also to hide tab bar completely when only a single document is open (SciTE does it this way).
Personally I tend to prefer having the tabbar displayed at all times, in most tabbed apps.
Actually this would be also nice to save some extra space in the editor for the editing area if people are editing just a single document.
We could have a (hidden?) pref for auto-hiding the tabbar.
Alternatively the "x"
button should disappear if a single tab is displayed (firefox works this way).
..if a single _untitled_ tab is displayed. This is the way Opera handles it, and that the behaviour that I find ergonomic in this case; it allows to close the last titled document tab without the need to close the app. As soon as the document gets modified or gets a title, the 'x' should be restored. Midori, Xfce's web browser with 'always show tabbar' enabled, behaves similarly to Opera, although it keeps a non-functional 'x' even on the last empty tab; clicking on the last empty tab doesn't close it/re-open another empty, so I guess the unnecessary 'x' can be reported as a bug.
The trouble is, it's difficult to tell if the document is 'modified', as that can include changing indent settings, encoding, etc, not necessarily a textual change.
I'm not sure that this is all worth the effort, but I'd surely love if Geany handled last, empty tabs this way. Regards Liviu
That said, this is actually not a feature I care much about so can stay the way it is if the majority of people prefer the current behaviour.
I've now made a hidden pref* for this behaviour, off by default. It could be made into a GUI pref though.
* new_document_after_close=true under [geany] in geany.conf.
Regards, Nick
Hello Nick
On Thu, Sep 23, 2010 at 7:37 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
..if a single _untitled_ tab is displayed. This is the way Opera handles it, and that the behaviour that I find ergonomic in this case; it allows to close the last titled document tab without the need to close the app. As soon as the document gets modified or gets a title, the 'x' should be restored. Midori, Xfce's web browser with 'always show tabbar' enabled, behaves similarly to Opera, although it keeps a non-functional 'x' even on the last empty tab; clicking on the last empty tab doesn't close it/re-open another empty, so I guess the unnecessary 'x' can be reported as a bug.
The trouble is, it's difficult to tell if the document is 'modified', as that can include changing indent settings, encoding, etc, not necessarily a textual change.
I was thinking that this could be done whenever Geany reports an 'untitled' document as modified, for example when the tab name becomes red and the 'save current file' is activated.
I've now made a hidden pref* for this behaviour, off by default. It could be made into a GUI pref though.
- new_document_after_close=true under [geany] in geany.conf.
Great! Thanks. I should check SVN now. Liviu
On Thu, 23 Sep 2010 21:18:11 +0300 Liviu Andronic landronimirc@gmail.com wrote:
..if a single _untitled_ tab is displayed. This is the way Opera handles it, and that the behaviour that I find ergonomic in this case; it allows to close the last titled document tab without the need to close the app. As soon as the document gets modified or gets a title, the 'x' should be restored. Midori, Xfce's web browser with 'always show tabbar' enabled, behaves similarly to Opera, although it keeps a non-functional 'x' even on the last empty tab; clicking on the last empty tab doesn't close it/re-open another empty, so I guess the unnecessary 'x' can be reported as a bug.
The trouble is, it's difficult to tell if the document is 'modified', as that can include changing indent settings, encoding, etc, not necessarily a textual change.
I was thinking that this could be done whenever Geany reports an 'untitled' document as modified, for example when the tab name becomes red and the 'save current file' is activated.
But the tab doesn't change when you just change the indent type. So there could be a good reason why the user wants to close the document and start again, to use default indent settings. So closing should not be disabled because it's not really practical to detect all the possible changes to document settings.
Regards, Nick
On Fri, Sep 24, 2010 at 2:47 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
But the tab doesn't change when you just change the indent type. So there could be a good reason why the user wants to close the document and start again, to use default indent settings. So closing should not be disabled because it's not really practical to detect all the possible changes to document settings.
I noticed it only now, and I think it's great, when a last 'untitled' tab is present, opening a new/existing file will simply replace the empty tab. This might be the answer for wanting to re-start with defaults, but I guess the behaviour could be not that obvious. Just an idea..
Regards Liviu
On Thu, Sep 23, 2010 at 7:37 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
- new_document_after_close=true under [geany] in geany.conf.
I'm really nitpicking now, but is there a reason that the following two actions are visually different, when a last empty tab is present: - close last empty tab, the grey screen briefly pops out and immediately a new 'untitled' document is created (a bit disturbing) - create new empty file, the last empty tab gets replaced and no grey screen and deactivated menus are visually noticed
In both cases Geany reports: 15:33:52: File untitled closed. 15:33:52: New file "untitled" opened.
It would be great if in both cases Geany had teh same behaviour. What do you think? Liviu
On Fri, 24 Sep 2010 15:35:59 +0300 Liviu Andronic landronimirc@gmail.com wrote:
On Thu, Sep 23, 2010 at 7:37 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
- new_document_after_close=true under [geany] in geany.conf.
I'm really nitpicking now, but is there a reason that the following two actions are visually different, when a last empty tab is present:
- close last empty tab, the grey screen briefly pops out and
immediately a new 'untitled' document is created (a bit disturbing)
- create new empty file, the last empty tab gets replaced and no grey
screen and deactivated menus are visually noticed
In both cases Geany reports: 15:33:52: File untitled closed. 15:33:52: New file "untitled" opened.
I've now implemented this, but it was harder because you have to avoid recursion - opening a document closes an empty doc, but that triggered a new doc before the document was opened. Please test.
Regards, Nick
On Thu, Sep 30, 2010 at 5:52 PM, Nick Treleaven nick.treleaven@btinternet.com wrote:
I've now implemented this, but it was harder because you have to avoid recursion - opening a document closes an empty doc, but that triggered a new doc before the document was opened. Please test.
r5271 seems to be working as expected here. Thanks a lot for looking into this. Regards Liviu