Re: [Geany-devel] Split Window Patches
On 03/27/11 09:11, Colomban Wendling wrote:
We need a better fix then. Maybe you can try to find out why the X
clipboard get broken on Scintilla (and fix it :D). If it get fixed, we
will probably can re-apply the patch.
When the ScintillaObject gets reparented (unrealized/re-realized), it
doesn't re-setup the selection targets again (this is only done in
ScintillaGTK::Initialize()).
The first patch #0001 is the same as the previous #0003 patch, which
removes the reparenting stuff, to make Split Window work on Windows.
The second patch #0002 fixes the primary selection issue by moving
gtk_selection_add_targets() and friends into the
ScintillaGTK::RealizeThis() function, and also adds its counter-parts to
the ScintillaGTK::UnRealizeThis() function.
The third patch #0003 fixes the issue where the I-Beam cursor is
displayed even for the scrollbars when the widget is
unrealized/re-realized. I tried a few different ways to do this,
including trying to use Scintilla's SetCursor() function, but nothing
seemed to work.
Everything *seems* to work now, and it's not hacky, IMO - except maybe
#0003 a little bit ;).
Cheers,
Matthew Brush
From 1eb6bc349514ef4446e03b61d9661e33c7cf9499 Mon Sep 17 00:00:00 2001
From: Matthew Brush matthewbr...@gmail.com
Date: Wed, 16 Mar 2011 14:33:40 -0700
Subject: [PATCH 3/5] Remove widget reparenting in Split Window plugin.
Instead of reparenting the documents notebook full of
ScintillaObjects, just ref it, remove it from the old parent, add
it to the new parent, and then unref it. This might fix issues
with Split Window plugin on Windows and seems to have no issues
on in Linux.
---
plugins/splitwindow.c | 21 ++---
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/plugins/splitwindow.c b/plugins/splitwindow.c
index e357198..9117bf4 100644
--- a/plugins/splitwindow.c
+++ b/plugins/splitwindow.c
@@ -298,7 +298,6 @@ static GtkWidget *create_toolbar(void)
return toolbar;
}
-
static void split_view(gboolean horizontal)
{
GtkWidget *notebook = geany_data-main_widgets-notebook;
@@ -313,14 +312,14 @@ static void split_view(gboolean horizontal)
set_state(horizontal ? STATE_SPLIT_HORIZONTAL : STATE_SPLIT_VERTICAL);
- /* temporarily put document notebook in main vbox (scintilla widgets must stay
- * in a visible parent window, otherwise there are X selection and scrollbar issues) */
- gtk_widget_reparent(notebook,
- ui_lookup_widget(geany-main_widgets-window, vbox1));
+ gtk_widget_ref(notebook);
+ gtk_container_remove(GTK_CONTAINER(parent), notebook);
pane = horizontal ? gtk_hpaned_new() : gtk_vpaned_new();
gtk_container_add(GTK_CONTAINER(parent), pane);
- gtk_widget_reparent(notebook, pane);
+
+ gtk_container_add(GTK_CONTAINER(pane), notebook);
+ gtk_widget_unref(notebook);
box = gtk_vbox_new(FALSE, 0);
toolbar = create_toolbar();
@@ -364,10 +363,8 @@ static void on_unsplit(GtkMenuItem *menuitem, gpointer user_data)
g_return_if_fail(edit_window.editor);
- /* temporarily put document notebook in main vbox (scintilla widgets must stay
- * in a visible parent window, otherwise there are X selection and scrollbar issues) */
- gtk_widget_reparent(notebook,
- ui_lookup_widget(geany-main_widgets-window, vbox1));
+ gtk_widget_ref(notebook);
+ gtk_container_remove(GTK_CONTAINER(pane), notebook);
if (edit_window.sci != NULL edit_window.handler_id 0)
{
@@ -378,7 +375,9 @@ static void on_unsplit(GtkMenuItem *menuitem, gpointer user_data)
gtk_widget_destroy(pane);
edit_window.editor = NULL;
edit_window.sci = NULL;
- gtk_widget_reparent(notebook, parent);
+
+ gtk_container_add(GTK_CONTAINER(parent), notebook);
+ gtk_widget_unref(notebook);
}
--
1.7.1
diff --git a/scintilla/gtk/ScintillaGTK.cxx b/scintilla/gtk/ScintillaGTK.cxx
index c288488..1773e61 100644
--- a/scintilla/gtk/ScintillaGTK.cxx
+++ b/scintilla/gtk/ScintillaGTK.cxx
@@ -416,6 +416,18 @@ void ScintillaGTK::RealizeThis(GtkWidget *widget) {
gtk_widget_realize(widtxt);
gtk_widget_realize(PWidget(scrollbarv));
gtk_widget_realize(PWidget(scrollbarh));
+
+ gtk_selection_add_targets(widget, GDK_SELECTION_PRIMARY,
+ clipboardCopyTargets, nClipboardCopyTargets);
+
+#ifndef USE_GTK_CLIPBOARD
+ gtk_selection_add_targets(widget, atomClipboard,
+ clipboardPasteTargets, nClipboardPasteTargets);
+#endif
+
+ gtk_drag_dest_set(widget,
+ GTK_DEST_DEFAULT_ALL, clipboardPasteTargets, nClipboardPasteTargets,
+ static_castGdkDragAction(GDK_ACTION_COPY | GDK_ACTION_MOVE));
}
void ScintillaGTK::Realize(GtkWidget *widget) {
@@ -425,6 +437,15 @@ void ScintillaGTK::Realize(GtkWidget *widget) {
void ScintillaGTK::UnRealizeThis(GtkWidget *widget) {
try {
+
+ gtk_selection_clear_targets(widget, GDK_SELECTION_PRIMARY);
+
+#ifndef USE_GTK_CLIPBOARD
+ gtk_selection_clear_targets(widget, atomClipboard);
+#endif
+
+ gtk_drag_dest_unset(widget);
+
if
Re: [Geany-devel] Split Window Patches
On Mon, 28 Mar 2011 21:38:22 +1100, Lex wrote: On 28 March 2011 17:39, Matthew Brush mbr...@codebrainz.ca wrote: On 03/27/11 09:11, Colomban Wendling wrote: We need a better fix then. Maybe you can try to find out why the X clipboard get broken on Scintilla (and fix it :D). If it get fixed, we will probably can re-apply the patch. When the ScintillaObject gets reparented (unrealized/re-realized), it doesn't re-setup the selection targets again (this is only done in ScintillaGTK::Initialize()). The first patch #0001 is the same as the previous #0003 patch, which removes the reparenting stuff, to make Split Window work on Windows. The second patch #0002 fixes the primary selection issue by moving gtk_selection_add_targets() and friends into the ScintillaGTK::RealizeThis() function, and also adds its counter-parts to the ScintillaGTK::UnRealizeThis() function. The third patch #0003 fixes the issue where the I-Beam cursor is displayed even for the scrollbars when the widget is unrealized/re-realized. I tried a few different ways to do this, including trying to use Scintilla's SetCursor() function, but nothing seemed to work. Everything *seems* to work now, and it's not hacky, IMO - except maybe #0003 a little bit ;). Cheers, Matthew Brush Hi Matthew, I havn't had a chance to try it, but perhaps you should report the problem to Scintilla and submit the two patches to Neil. In general Geany tries to use an unmodified version of Scintilla so that changes don't have to be made each time its updated. Since this is to fix a plugin problem not a core problem (albeit a core plugin) I would suggest waiting for the response from Scintilla rather than including patches in the Geany Scintilla. What do others think? The same. First, the Scintilla patches should be shared with upstream, ideally they apply them. Then we can patch Geany. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpY7UlUYKHtc.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Performance issues?
Hi, Le 28/03/2011 05:10, Lex Trotman a écrit : On 28 March 2011 12:35, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: On 27.03.2011 05:15, Lex Trotman wrote: The question is can problems be introduced by not reparsing things, eg if we are editing a .h file, can that affect the symbols of the .c files that include it ... probably possible AFAICT. AFAICT it is possible but unlikely since the only thing that would have this kind of side effects is the C/C++ (and probably D) preprocessor (e.g. if a constant changing conditional code changes). Not 100% sure though. Is there some easy way of triggering re-parsing of dependencies when the sidebar is about to swap to a different file? That way real-time update only needs to do the one file being edited, but no artifacts are introduced due to inconsistencies between when tags were parsed. I don't know (without further search), but I'm not sure it'd resolve the issue, since while editing file 1 you wouldn't get the changes from file 2. But again, not sure it's a real issue. Well its not really dependency aware, in the non-real-time version it does it by reparseing *all* files in the workspace when any one of them is saved, so there can be no inconsistency. It is the fact that its doing all of them on real-time update that is the performance problem, so we want to real-time parse only the file we are editing. True. Moreover -- as far as I can understand the TagManager code (so, only more or less :D) -- the parent updates will not be done in-memory, so it's definitely a problem we should solve. Not being certain what inconsistencies there might be, I'd suggest trying it, only parse the one file real-time and all the others at save time, ie apply Yura's patch (below) and see. Agreed. However the patch would *always* disable updating parent, what we probably don't want (though, not really sure what it'd change). So I have modified it and committed it to SVN (r5642). Hope this fixes the issue, feedback welcome. And guys, thanks a lot for tracking this down! Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Performance issues? [PATCH]
Le 27/03/2011 13:23, Yura Siamashka a écrit : On Sun, 27 Mar 2011 14:15:45 +1100 Lex Trotman ele...@gmail.com wrote: 1) geanyprj act only on document-open, document-save, document-activate callbacks 2) geanyprj add a lot of TMWorkObject objects using tm_workspace_add_object() to Geany And tm_workspace_add_object sets the parent to be the whole workspace! Can something be done for this? No idea -- I only barely know this part if the TagManager, sorry. Because of item 2) above I think this will reparse all open files. I don't think it is true. I used mantisbt project to test. Initially it takes few seconds to load the project (parse all files). Delay during typing is much less then second. You are right, because updating the root workspace don't really update the child SourceFiles (because the force param is set to FALSE). Projects are maybe affected though (however, not sure where/when they are used). Anyway here is patch that make Geany don't parse tags when user is actively typing. I'm not sure about this patch, because it is then really easy to make the tag list never update automatically. E.g. if update timeout is set to 1s, just type something every 999ms and then update will never happen, even if there is actually 1s free to do it. Are really the update making something unresponsive for you? But maybe I'm worrying too much and this only need the timeout to be configured otherwise, I may try to tune this if you really think it's important. I also plan to try to move the TagManager parsing in a separate thread at some point, maybe it'll help (though maybe it's the UI update that takes most of the time...). However, don't expect this to happen very soon, I'm a thread newbie so it's likely to take me time to get it working properly. Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] A guide to patches?
Hi, Le 28/03/2011 22:50, Росен Стоянов a écrit : Hey guys, i see that there's an active development going on here with all the patches and stuff, but i guess not everyone knows how to apply them or is it's just me... Either way, can someone give a hint on using them? I guess it's somewhat trivial to you, but it's not the same here :D If you use the Geany's Git mirror, you can use Git's patching facility: $ git apply patch-file Otherwise, you can simply use the `patch` tool: $ patch -p1 patch-file See the manual of each for more details, or ask if you have a particular issue. I'm particularly interested in the new tag parser and the split window patches :) Most of them are already applied to SVN version of Geany (especially the tag paring stuff, if you refer to my in-memory tag parsing patches), so maybe just try the SVN version -- or update it if you already use one ;) Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Performance issues? [PATCH]
On 29 March 2011 08:29, Yura Siamashka yura...@gmail.com wrote: On Mon, 28 Mar 2011 23:00:54 +0200 Colomban Wendling lists@herbesfolles.org wrote: Anyway here is patch that make Geany don't parse tags when user is actively typing. I'm not sure about this patch, because it is then really easy to make the tag list never update automatically. E.g. if update timeout is set to 1s, just type something every 999ms and then update will never happen, even if there is actually 1s free to do it. Please show me that energeezer that type something every second and even have time to inspect tags while doing it. :) It is quite unrealistic to me. On other hand if someone is just typing parse delay can be annoying if his file is HUGE. Are really the update making something unresponsive for you? Actually I was happy with Geany performance even before any related changes, so it is not very important to me, but I think it can be usefull to topic starter. But maybe I'm worrying too much and this only need the timeout to be configured otherwise, I may try to tune this if you really think it's important. I also plan to try to move the TagManager parsing in a separate thread at some point, maybe it'll help (though maybe it's the UI update that takes most of the time...). No, I suspected this first and disabled UI update during research (delay seemed the same), but maybe it is worth to make smart update. Parser report that some tags were actually changed and you call UI update only then (if it is not done already) Seems to me that none of this answers the original question of why is the lag much greater when both Geanyprj and real-time update are in use, compared to the lag when only one of them is in use? If we could answer that then adding delays etc would be immaterial :-) Cheers Lex -- Yura Siamashka yura...@gmail.com ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Performance issues?
On 29 March 2011 07:37, Colomban Wendling lists@herbesfolles.org wrote: Hi, Le 28/03/2011 05:10, Lex Trotman a écrit : On 28 March 2011 12:35, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: On 27.03.2011 05:15, Lex Trotman wrote: The question is can problems be introduced by not reparsing things, eg if we are editing a .h file, can that affect the symbols of the .c files that include it ... probably possible AFAICT. AFAICT it is possible but unlikely since the only thing that would have this kind of side effects is the C/C++ (and probably D) preprocessor (e.g. if a constant changing conditional code changes). Not 100% sure though. Actually the tag manager parses all options since it doesn't know how to evaluate the conditions and then gets confused when something gets defined twice :-) But on further thought I don't think real-time parsing of only one file makes the problem in any way worse than non-real-time parsing so its ok. Is there some easy way of triggering re-parsing of dependencies when the sidebar is about to swap to a different file? That way real-time update only needs to do the one file being edited, but no artifacts are introduced due to inconsistencies between when tags were parsed. I don't know (without further search), but I'm not sure it'd resolve the issue, since while editing file 1 you wouldn't get the changes from file 2. But again, not sure it's a real issue. As above I don't think its a problem any more. Well its not really dependency aware, in the non-real-time version it does it by reparseing *all* files in the workspace when any one of them is saved, so there can be no inconsistency. It is the fact that its doing all of them on real-time update that is the performance problem, so we want to real-time parse only the file we are editing. True. Moreover -- as far as I can understand the TagManager code (so, only more or less :D) -- the parent updates will not be done in-memory, so it's definitely a problem we should solve. Probably better to leave it as is rather than potentially use up memory, if its only done at save time. Not being certain what inconsistencies there might be, I'd suggest trying it, only parse the one file real-time and all the others at save time, ie apply Yura's patch (below) and see. Agreed. However the patch would *always* disable updating parent, what we probably don't want (though, not really sure what it'd change). So I have modified it and committed it to SVN (r5642). Ok, oh well, as above, I'm not sure it has any consequences, lets test it and see. Cheers Lex Hope this fixes the issue, feedback welcome. And guys, thanks a lot for tracking this down! Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Performance issues?
On Tue, Mar 29, 2011 at 00:04, Lex Trotman ele...@gmail.com wrote: Agreed. However the patch would *always* disable updating parent, what we probably don't want (though, not really sure what it'd change). So I have modified it and committed it to SVN (r5642). Ok, oh well, as above, I'm not sure it has any consequences, lets test it and see. Ah, that is something I can help with! I'll update to the latest rev first thing tomorrow morning... -tnx!- Harold ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
