So, I'm always having multiple dozens of files open, some of which define even more symbols.
At that point I began to really miss the search you can do in the file open/save dialog (while typing search, the gtk docs say interactive or typeahead search).
I looked at it and got it sort of working (see http://www.alice-dsl.net/simonemartitz/geany.png), however I ran into some problems.
a) switching focus to the editor widget. When using the keyboard to do the search, the first match will be selected. As of now, selecting something in the list automagically switches the focus to the editor. That is of course unwanted while you're searching as it will stop and break the search basically upon entering the first character. In a work around, I disabled this switching if the selection happened by using the keyboard. This works well for the symbol list, but not at all for the open file list (which still changes the focus).
b) opening files doesn't bring it in front anymore. I removed the "changed" signal for the open file list as it's incompatible with searching. but that broke opening files as the mechanism to bring the open file up relies on the sidebar here. For this, I thought the "bringing the new doc up" code could be moved to the opening document code (document.c), and the sidebar handler just does a call document_open_file(). Would that work?
So, I basically want to discuss about a) if this feature is wanted and b) about the two problems that showed up.
I really love this feature already.
Attached is my diff.
Best regards.
Am Samstag, den 15.08.2009, 21:19 +0200 schrieb Thomas Martitz:
So, I'm always having multiple dozens of files open, some of which define even more symbols.
At that point I began to really miss the search you can do in the file open/save dialog (while typing search, the gtk docs say interactive or typeahead search).
I looked at it and got it sort of working (see http://www.alice-dsl.net/simonemartitz/geany.png), however I ran into some problems.
a) switching focus to the editor widget. When using the keyboard to do the search, the first match will be selected. As of now, selecting something in the list automagically switches the focus to the editor. That is of course unwanted while you're searching as it will stop and break the search basically upon entering the first character. In a work around, I disabled this switching if the selection happened by using the keyboard. This works well for the symbol list, but not at all for the open file list (which still changes the focus).
b) opening files doesn't bring it in front anymore. I removed the "changed" signal for the open file list as it's incompatible with searching. but that broke opening files as the mechanism to bring the open file up relies on the sidebar here. For this, I thought the "bringing the new doc up" code could be moved to the opening document code (document.c), and the sidebar handler just does a call document_open_file(). Would that work?
So, I basically want to discuss about a) if this feature is wanted and b) about the two problems that showed up.
For a): Yes! I think I would really love this feature too!
Regards, Dominic
Thomas Martitz wrote:
So, I basically want to discuss about a) if this feature is wanted and b) about the two problems that showed up.
I really love this feature already.
Attached is my diff.
Best regards.
I think I fixed the issues I mentioned, it works flawlessly so far at least.
for a) 1) steal the focus right away if using the mouse 2) steal the focus while typing only after the symbol/file has been "activated"(i.e. after return/enter, space)
for b) I reordered the code in document.c a bit. In fact, the code for bringing the opened document in front is already there, but only used if the file to be opened existed already. I moved it so, that it does that in any event. I copied to focus-stealing function into document.c also, since I think setting the focus into the editor widget is desirable for normal file opening too (ctrl + o, select, hit enter, start coding right away).
diff attached
Best regards
This should fix the remaining issues.
Best regards.
New patch, a little cleaner (less code duplication), but no functional change over the v3 one.
I have a hard time finding problems, it seems to work nicely for me.
Best regards.
On Sun, 23 Aug 2009 16:05:01 +0200 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
New patch, a little cleaner (less code duplication), but no functional change over the v3 one.
Thanks applied in SVN. It didn't compile at first (at least with warnings turned on), had to make a couple of edits. (Also some minor formatting changes).
Regards, Nick
Nick Treleaven schrieb:
On Sun, 23 Aug 2009 16:05:01 +0200 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
New patch, a little cleaner (less code duplication), but no functional change over the v3 one.
Thanks applied in SVN. It didn't compile at first (at least with warnings turned on), had to make a couple of edits. (Also some minor formatting changes).
Regards, Nick
Uhm, I had a quick talk with Enrico about it. He had quite a few remarks and complaints, so I planned on working on it further (I didn't have time yet and I'm waiting for the update of HACKING [some of his complains could've been avoided if HACKING was up-to-date]).
But thanks for committing. I'll take a look at the commit diff and provide a patch if needed.
Best regards.
Thomas Martitz schrieb:
Uhm, I had a quick talk with Enrico about it. He had quite a few remarks and complaints, so I planned on working on it further (I didn't have time yet and I'm waiting for the update of HACKING [some of his complains could've been avoided if HACKING was up-to-date]).
So, this should get away with the last of his remarks. It uses gtk_notebook_set_current_page() in treeviews.c again instead of document_open_full(), and replaces the goto in document.c by packing the following code into an equivalent if () block [although I personally think the goto wasn't *that* bad in this case, but I understand that people don't like them].
The other remarks (the shadow copy thing for example) are fixed or don't make sense to change now anymore.
If you still have remarks, I'm willing to fix them.
Take this one, it just changes a now inaccurate/incorrect comment.
Best regards.
On Fri, 04 Sep 2009 13:04:42 +0200 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
Take this one, it just changes a now inaccurate/incorrect comment.
Thanks, applied. Also removed now-unnecessary pos variable.
BTW, we don't (normally) use a big indent for overflowing lines, just one extra indent - except for functions where we (sometimes) use 2 indents to distinguish them.
Regards, Nick
Nick Treleaven schrieb:
On Fri, 04 Sep 2009 13:04:42 +0200 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
Take this one, it just changes a now inaccurate/incorrect comment.
Thanks, applied. Also removed now-unnecessary pos variable.
BTW, we don't (normally) use a big indent for overflowing lines, just one extra indent - except for functions where we (sometimes) use 2 indents to distinguish them.
Regards, Nick
I virtually copy&pasted that lines from before (pre-r4148). The big indentation was there before. But nice to know anyway.
Speaking indentation, I filed a bug report about per-project indentation: https://sourceforge.net/tracker/?func=detail&aid=2851038&group_id=15...
Best regards.
Thomas Martitz schrieb:
Nick Treleaven schrieb:
On Fri, 04 Sep 2009 13:04:42 +0200 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
Take this one, it just changes a now inaccurate/incorrect comment.
Thanks, applied. Also removed now-unnecessary pos variable.
BTW, we don't (normally) use a big indent for overflowing lines, just one extra indent - except for functions where we (sometimes) use 2 indents to distinguish them.
Regards, Nick
My patch was buggy. I don't know how I didn't notice it while testing. This should fix it http://pastie.org/606912
I'm sorry! :(
Best regards.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Thomas Martitz a écrit :
My patch was buggy. I don't know how I didn't notice it while testing. This should fix it http://pastie.org/606912
Nothing important, but I wonder why you test for (!reload) as you already check for (reload)? The check at the right of a || switch will be tested only if the left one is not true, then if the right check happens, then reload is necessarily false, isn't it? But it just seems strange and complicated to me, not a problem anyway.
Regards, Colomban
On Sat, 05 Sep 2009 18:30:13 +0200, Colomban wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Thomas Martitz a écrit :
My patch was buggy. I don't know how I didn't notice it while testing. This should fix it http://pastie.org/606912
Nothing important, but I wonder why you test for (!reload) as you already check for (reload)? The check at the right of a || switch will be tested only if the left one is not true, then if the right check happens, then reload is necessarily false, isn't it? But it just seems strange and complicated to me, not a problem anyway.
Same here.
Before the patch we only checked for "if (reload)". The function documentation already says: if reload is set, the doc argument has to be non-NULL, if reload is not set, doc is NULL. So, the new, additional check is somewhat unnecessary. It could be argumented as an additional sanity check but generally, document_open_file_full() is an internal function and so if the above conditions of the input argumens are not fullfilled, I would consider this as a bug in the calling code (still sanity checks are good, no doubt).
Regards, Enrico
Enrico Tröger schrieb:
On Sat, 05 Sep 2009 18:30:13 +0200, Colomban wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Thomas Martitz a écrit :
My patch was buggy. I don't know how I didn't notice it while testing. This should fix it http://pastie.org/606912
Nothing important, but I wonder why you test for (!reload) as you already check for (reload)? The check at the right of a || switch will be tested only if the left one is not true, then if the right check happens, then reload is necessarily false, isn't it? But it just seems strange and complicated to me, not a problem anyway.
Same here.
Before the patch we only checked for "if (reload)". The function documentation already says: if reload is set, the doc argument has to be non-NULL, if reload is not set, doc is NULL. So, the new, additional check is somewhat unnecessary. It could be argumented as an additional sanity check but generally, document_open_file_full() is an internal function and so if the above conditions of the input argumens are not fullfilled, I would consider this as a bug in the calling code (still sanity checks are good, no doubt).
Regards, Enrico
Well, before my patch document_open_file_full() *returned* st
raightly after finding the file in the internal open file list (in the !reload case). I added the goto to maintain that behavior without duplicating the "grab focus" code. Now that my latest fix removed the goto also, the original behavior should be still maintained, hence I added the if () (it went that road always if (reload == true), and only if (!reload) *and* it wasn't found in the internal document list (i.e. it's still NULL).
I'm not sure if it's really a bug of the calling code, and I'm also not sure why I got that if () wrong in the first place without noticing it at testing.
The culprit is probably that the function basically does a reload, even if (doc != NULL). But that was the original behavor which I never intended to change.
Btw, I'm thinking the goto saved a difficult to figure out/parse if () construct, but that may just be me :)
Best regards.
I've noticed that in current SVN, after hitting enter on an item in the doc/symbol list, the editor isn't focused anymore.
My patch aimed to have this, i.e.:
search->hit enter to exit search and mark the item->hit enter to actually jump to it. The last enter would also focus the editor so I can start coding right away. My patch worked like that and so did SVN right after it was committed, but current SVN leaves the focus on the list, forcing me to press F2 (which I mapped to focus the editor) additionally.
Can that be changed back again?
On Sun, 27 Sep 2009 13:13:36 +0200 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
I've noticed that in current SVN, after hitting enter on an item in the doc/symbol list, the editor isn't focused anymore.
My patch aimed to have this, i.e.:
search->hit enter to exit search and mark the item->hit enter to actually jump to it. The last enter would also focus the editor so I can start coding right away. My patch worked like that and so did SVN right after it was committed, but current SVN leaves the focus on the list, forcing me to press F2 (which I mapped to focus the editor) additionally.
Can that be changed back again?
Still works fine here. I committed a change to fix showing the editor before a reload, so the user can see whether the file should be reloaded.
http://geany.svn.sourceforge.net/viewvc/geany?view=rev&revision=4232
Regards, Nick
Nick Treleaven schrieb:
On Sun, 27 Sep 2009 13:13:36 +0200 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
I've noticed that in current SVN, after hitting enter on an item in the doc/symbol list, the editor isn't focused anymore.
My patch aimed to have this, i.e.:
search->hit enter to exit search and mark the item->hit enter to actually jump to it. The last enter would also focus the editor so I can start coding right away. My patch worked like that and so did SVN right after it was committed, but current SVN leaves the focus on the list, forcing me to press F2 (which I mapped to focus the editor) additionally.
Can that be changed back again?
Still works fine here. I committed a change to fix showing the editor before a reload, so the user can see whether the file should be reloaded.
http://geany.svn.sourceforge.net/viewvc/geany?view=rev&revision=4232
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
I tried r4240 again, and I can press enter as many times as I want, I'm always still in the symbol/doc list.
Best regards.
Thomas Martitz schrieb:
I tried r4240 again, and I can press enter as many times as I want, I'm always still in the symbol/doc list.
Alright, it seems the symbol list works with r4240 (it didn't with r4210 what I was running before), but the doc list still doesn't switch the focus.
Best regards.
On Sun, 27 Sep 2009 13:31:35 +0200 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
I tried r4240 again, and I can press enter as many times as I want, I'm always still in the symbol/doc list.
Alright, it seems the symbol list works with r4240 (it didn't with r4210 what I was running before), but the doc list still doesn't switch the focus.
Both work for me (current/recent SVN). Can you find the revision number(s) that introduced the problem?
Regards, Nick
On 27.09.2009 19:07, Nick Treleaven wrote:
On Sun, 27 Sep 2009 13:31:35 +0200 Thomas Martitzthomas.martitz@student.HTW-Berlin.de wrote:
I tried r4240 again, and I can press enter as many times as I want, I'm always still in the symbol/doc list.
Alright, it seems the symbol list works with r4240 (it didn't with r4210 what I was running before), but the doc list still doesn't switch the focus.
Both work for me (current/recent SVN). Can you find the revision number(s) that introduced the problem?
Regards, Nick
I'll see if I get time for a git bisect soon.
Strangely enough, it all works fine on my desktop (x86_64, debian squeeze), but not on my laptop (x86, karmic alpha 6). My previous reports where based on my laptop.
Best regards.