[Geany-devel] Question about GTK+ version used
Hi, Is there some specific distro or platform that sets the oldest GTK+ version Geany needs to support? I had a conversation with Enrico on IRC some time back and he explained that Geany supports older GTK+ versions so that enterprise and similar distros which have really old packages are able to still able to compile/run it. So I was just curious *specifically* what distro(s) and version(s) sets the oldest version of GTK+ that Geany should support? In case it's of any interest to anyone, I just did some searching around and here are some distro and GTK+ versions I could find: RHEL 5 - GTK+ 2.10 RHEL 6 - GTK+ 2.18 Fedora 8 - GTK+ 2.12 Fedora 10 - GTK+ 2.14 Fedora 11 - GTK+ 2.16 Fedora 12 - GTK+ 2.18 Fedora 13 - GTK+ 2.20 Debian Lenny - GTK+ 2.12 Debian Lenny (backports) - GTK+ 2.18 or GTK+ 2.20 Debian Squeeze - GTK+ 2.20 Ubuntu Hardy - 2.12 Ubuntu Lucid - 2.20 Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Question about GTK+ version used
On 26 September 2011 18:21, Matthew Brush mbr...@codebrainz.ca wrote: Hi, Is there some specific distro or platform that sets the oldest GTK+ version Geany needs to support? I had a conversation with Enrico on IRC some time back and he explained that Geany supports older GTK+ versions so that enterprise and similar distros which have really old packages are able to still able to compile/run it. So I was just curious *specifically* what distro(s) and version(s) sets the oldest version of GTK+ that Geany should support? In case it's of any interest to anyone, I just did some searching around and here are some distro and GTK+ versions I could find: RHEL 5 - GTK+ 2.10 RHEL 6 - GTK+ 2.18 Fedora 8 - GTK+ 2.12 Fedora 10 - GTK+ 2.14 Fedora 11 - GTK+ 2.16 Fedora 12 - GTK+ 2.18 Fedora 13 - GTK+ 2.20 Debian Lenny - GTK+ 2.12 Debian Lenny (backports) - GTK+ 2.18 or GTK+ 2.20 Debian Squeeze - GTK+ 2.20 Ubuntu Hardy - 2.12 Ubuntu Lucid - 2.20 Well, the question is when do we stop supporting an OS for new versions of Geany. Old versions can of course continue if someone wants to backport bugfixes. RHEL support is defined here https://access.redhat.com/support/policy/updates/errata/ This appears to be the longest support period I could find. They support new versions for the first four years for paid support and I don't see that it is reasonable to expect a community project to do better. That means that RHEL 5 runs out about now, so the allowed version of GTK jumps to 2.18. But... Windows GTK has been seriously broken since 2.18, something that is rumored to have been fixed at 2.24!! So the last good windows version was 2.16. We would need to support that until a working 2.24 can be packaged with Geany. Cheers Lex Cheers, Matthew Brush ___ 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] editing big files can be too slow with tag reparsing - HTML
On 24/09/2011 11:59, Colomban Wendling wrote: Le 22/09/2011 18:30, Nick Treleaven a écrit : Hi, Whilst opening doc/geany.html I found it takes5s on my machine to load. It's a big document though, still perhaps the HTML tag parser performance could be improved. I think 5s is weird in the first place. I know geany.html is 6.5k-lines file, and that it may have say, 150 tags, but 5s seems way too much IMHO. Maybe we should try to find out why this is so slow on your machine, there might show a Geany bug, performance problem or something else. I'm reduced to using Windows. I guess the reason is the regex code that is really old which is used for Windows builds. It might help to update it from CTags (we had a patch from Jiri Techet but it didn't look like it would build on Windows, i.e. wasn't from CTags). * What kind of machine did you run (basically, CPU's MHz) Pentium 4, 1.9 GHz, 512 MB ram. * Had you many HTML files open, with many tags each? * Had you many non-HTML files open? Just that one file. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] editing big files can be too slow with tag reparsing
Le 24/09/2011 12:39, Lex Trotman a écrit : On 24 September 2011 20:33, Colomban Wendling lists@herbesfolles.org wrote: Le 23/09/2011 03:09, Lex Trotman a écrit : On 23 September 2011 10:34, Matthew Brush mbr...@codebrainz.ca wrote: On 09/22/2011 09:30 AM, Nick Treleaven wrote: Hi, Whilst opening doc/geany.html I found it takes 5s on my machine to load. It's a big document though, still perhaps the HTML tag parser performance could be improved. Well under 1 second to load geany.html here, and editing it is quite smooth as well. Ditto, but of course it depends on the machine. Same here, I don't see any kind of lag with that file. But yeah, depends a lot on the machine's power. Myself, I've found the biggest slowdown is when having lots of tags files, say more than 10 maybe. If I have all my Vala tags (the ones on the Wiki) loaded, Geany basically becomes unusable. IIUC the tags files are not re-loaded so the problem here suggests symbol lookup problems rather than parsing problems. Actually, IIRC Tagmanager updates an array holding all workspace tags every time an update is done, so having many tags file or many open files of a same filetype *may* (?) reduce the performances. No guarantees on that though, there are too many dark corners in Tagmanager (:-') Are you saying that it re-reads all open tags files every time it re-parses a source file? That would certainly make it slow. And if it is just an array, unless the array is indexed or sorted then searching it would be slow for computing the auto-completions. 1) tm_workspace keeps a sorted array of all non-global tags, that is rebuilt on each reparse [1]. This needs to rebuild and sort an array holding all tags (I suspect that this may be slow with many tags), but don't need reparsing anything. 2) As Matthew said in another mail, tm_tags_find() uses bsearch() [2] so it's not that slow upon search. Note however that scope completion is a complete other topic -- BTW it's still broken... :/ Cheers, Colomban [1] tm_workspace.c:tm_workspace_update() [2] tm_tag.c:tm_tags_find() ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Use GtkBuilder
On Mon, Sep 26, 2011 at 13:08, Lex Trotman ele...@gmail.com wrote: [...] I'm really happy about this change. First we get rid of the horrible old glade editor and second it's the most important step towards making Geany compile under GTK 3. Thanks for your work! Hi Jiri, And I'm responding as a member of the Jiri category :-) How much do you (or anyone) know about supporting both GTK2 and 3, 1. with the same source, 2. with the same binary, 3. differing platforms The reason I ask is that my very preliminary evaluation is that 1. is possible but may need a bunch of #if sections :(, Right. For the most common ones it would be best to create some utility functions that encapsulate the ifdefs so the ifdefs aren't everywhere. 2. is basically impossible (, and Right, forget about it. 3. is unknown. ? No idea but I don't expect major issues once (1) is done. In general it would be best just to try to substitute GTK version in configure, see what happens and start fixing the errors. I'm really tempted to try it myself but I'm not sure if I'll have enough time for that in the following few months. Also for changes like that it would be better to have git in place for easier merges once the work is done. My personal feeling is that the sooner some support for GTK 3 is added, the better. Of course first, until it is stable and working as expected, it could be an experimental configure option which ordinary mortals would be discouraged to use. Meanwhile thanks to the ifdefs the old GTK 2 code should work as before. And maybe the conversion will be quite easy - it's just you never know unless you try it, so it's better to try it to know :-). Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] editing big files can be too slow with tag reparsing
Le 24/09/2011 13:32, Lex Trotman a écrit :
[...]
How about automagically disabling auto-reparsing per-file if it takes
too long (1s?) at runtime? Without needing to change the setting that is.
I like the idea.
Hi Colomban, Thomas,
Hey Lex, everyone,
I disagree, it is a bad idea to turn off a setting that changes the
behavior. The user is likely to be confused by the unexpected change
in behavior (new symbols no longer in autocompletes, new types not
being highlighted etc). Having it automagically turn off is bad. At
most, pop up a dialog suggesting turning it off and noting where, but
only ever once per session.
Hum, right, automagic might not be good, asking the user is always better.
I've got 2 WIP patches, though they might not be appropriate to commit
before release since they add strings... anyway, here they are:
0001-Per-document-real-time-symbols-setting.patch:
Adds a per-document setting for real-time updates and a menu item in the
Document menu. There is still a FIXME in it, feel free to give ideas :)
0002-Tell-the-user-if-real-time-reparsing-is-slow-and-let.patch:
This one adds the check for the updating duration and asks the user. It
is WIP, and I'm not really convinced by the dialog, as you can read in a
TODO. Apart that, it seems to work pretty OK.
Both misses docs, up to come when they are ready.
So, I'm soliciting your impressions, opinions, remarks, etc. Also, is
this whole thing important enough to break string freeze less than a
week before release? (read: to have some strings untranslated)
Cheers,
Colomban
PS:
Although I have a great idea for an animated paper clip in the bottom
right corner that can suggest it every couple of seconds ... :)
Hehe, I like the idea... :D
Colomban is right in trying to evaluate where Nicks problem is first,
thats far more likely to be productive, this sort of thing is the last
option not the first.
BTW, after Nick's answer, it looks very weird to me, like if regexes was
eeaalyyy slow on Windows (or
everywhere?)
From c080dec21d2bf18a525064922c9c88aeece9e1a9 Mon Sep 17 00:00:00 2001
From: Colomban Wendling b...@herbesfolles.org
Date: Mon, 26 Sep 2011 23:25:11 +0200
Subject: [PATCH 1/2] Per-document real-time symbols setting
---
geany.glade | 10 ++
src/callbacks.c | 11 +++
src/callbacks.h |4
src/document.c| 25 +++--
src/document.h|2 ++
src/documentprivate.h |7 +--
src/editor.c |4
src/interface.c |9 +
src/ui_utils.c|4
9 files changed, 68 insertions(+), 8 deletions(-)
diff --git a/geany.glade b/geany.glade
index ba18b6f..aed5723 100644
--- a/geany.glade
+++ b/geany.glade
@@ -1407,6 +1407,16 @@
/child
child
+ widget class=GtkCheckMenuItem id=menu_real_time_symbols
+ property name=visibleTrue/property
+ property name=label translatable=yesReal-time s_ymbols/property
+ property name=use_underlineTrue/property
+ property name=activeFalse/property
+ signal name=activate handler=on_menu_real_time_symbols_activate last_modification_time=Mon, 26 Sep 2011 20:06:02 GMT/
+ /widget
+ /child
+
+ child
widget class=GtkMenuItem id=indent_type1
property name=visibleTrue/property
property name=label translatable=yesIn_dent Type/property
diff --git a/src/callbacks.c b/src/callbacks.c
index 18b98be..65af4eb 100644
--- a/src/callbacks.c
+++ b/src/callbacks.c
@@ -2127,3 +2127,14 @@ void on_detect_width_from_file_activate(GtkMenuItem *menuitem, gpointer user_dat
ui_document_show_hide(doc);
}
}
+
+
+void on_menu_real_time_symbols_activate(GtkCheckMenuItem *menuitem, gpointer user_data)
+{
+ GeanyDocument *doc = document_get_current();
+
+ if (doc != NULL)
+ {
+ document_set_auto_update_symbols(doc, gtk_check_menu_item_get_active(menuitem));
+ }
+}
diff --git a/src/callbacks.h b/src/callbacks.h
index 108b80e..d719c6d 100644
--- a/src/callbacks.h
+++ b/src/callbacks.h
@@ -670,3 +670,7 @@ on_detect_type_from_file_activate (GtkMenuItem *menuitem,
void
on_detect_width_from_file_activate (GtkMenuItem *menuitem,
gpointer user_data);
+
+void
+on_menu_real_time_symbols_activate (GtkCheckMenuItem *menuitem,
+gpointer user_data);
diff --git a/src/document.c b/src/document.c
index d185c0f..e610112 100644
--- a/src/document.c
+++ b/src/document.c
@@ -389,7 +389,8 @@ static void init_doc_struct(GeanyDocument *new_doc)
priv-undo_actions = NULL;
priv-redo_actions = NULL;
priv-line_count = 0;
- priv-tag_list_update_source = 0;
+ priv-tag_list_update.enabled = editor_prefs.autocompletion_update_freq 0;
+ priv-tag_list_update.source = 0;
#ifndef USE_GIO_FILEMON
priv-last_check = time(NULL);
#endif
@@ -591,6 +592,17 @@ static GeanyDocument
Re: [Geany-devel] editing big files can be too slow with tag reparsing - HTML
Le 26/09/2011 13:48, Nick Treleaven a écrit : On 24/09/2011 11:59, Colomban Wendling wrote: Le 22/09/2011 18:30, Nick Treleaven a écrit : Hi, Whilst opening doc/geany.html I found it takes5s on my machine to load. It's a big document though, still perhaps the HTML tag parser performance could be improved. I think 5s is weird in the first place. I know geany.html is 6.5k-lines file, and that it may have say, 150 tags, but 5s seems way too much IMHO. Maybe we should try to find out why this is so slow on your machine, there might show a Geany bug, performance problem or something else. I'm reduced to using Windows. I guess the reason is the regex code that is really old which is used for Windows builds. Maybe yeah, but I find it a little weird you see *so much* slowness... For comparison, on my machine [1] parsing and updating the list takes less than 60ms for geany.html. It might help to update it from CTags (we had a patch from Jiri Techet but it didn't look like it would build on Windows, i.e. wasn't from CTags). Maybe we could use GRegex now we have a GLib recent enough? Anyway tagamanger/regex.c looks like a few glibc source file concatenated with a 0xff separator, I'd then guess any POSIX RE implementation (e.g. today's glibc's one) would do, wouldn't it? * What kind of machine did you run (basically, CPU's MHz) Pentium 4, 1.9 GHz, 512 MB ram. Not any kind of slow machine... Could anybody else try the same on another Windows machine, just to see if it is Windows-related or something? (Enrico, Matthew?) * Had you many HTML files open, with many tags each? * Had you many non-HTML files open? Just that one file. OK... with a fresh configdir? Regards, Colomban [1] OK, it is a little more powerful (i3 2.93GHz), but still ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Use GtkBuilder
On 09/26/2011 09:15 AM, Jiří Techet wrote: In general it would be best just to try to substitute GTK version in configure, see what happens and start fixing the errors. I'm really tempted to try it myself but I'm not sure if I'll have enough time for that in the following few months. Also for changes like that it would be better to have git in place for easier merges once the work is done. My personal feeling is that the sooner some support for GTK 3 is added, the better. Of course first, until it is stable and working as expected, it could be an experimental configure option which ordinary mortals would be discouraged to use. Meanwhile thanks to the ifdefs the old GTK 2 code should work as before. And maybe the conversion will be quite easy - it's just you never know unless you try it, so it's better to try it to know :-). I did start a little bit with this in my geany repository. Some observations: 1) Need to get rid of direct access of struct members[1]. 2) Geany should support at minimum GTK+ 2.18 so that we can use gtk_widget_get_allocation() if we want to (cleanly) pass GSEAL_ENABLE builds. This actually wouldn't be needed strictly for GTK+ 3 since I think the old size allocation stuff is entirely gone. 3) The GeanyWrapLabel, I'm fairly sure can be #if'd out entirely for GTK+ 3. 4) The gdkkeysyms.h thing is easily solved by adding a #if to include gdkkeysyms-compat.h when using GTK+ 3.0. 5) Need to upgrade to Scintilla 2.29[2] since it supports GTK+ 3.0 (IIRC it still supports down to GTK+ 2.8 as well). 6) As you said, the configure.ac would need and option to enable this, to switch the package checks for gtk+-3.0 as well as another place where it collects the version of gtk+-2.0 using pkg-config. 7) Probably lots of other stuff I haven't discovered yet, since I haven't actually got Geany to build with GTK+ 3 yet. In my opinion, I don't think it would *too* difficult to support GTK+ 2.1x all the way through 3.x at the same time. [1] https://github.com/codebrainz/geany/commit/d2ba07b5ae9153f937adcb00337a66a309b66d67 [2] https://github.com/codebrainz/geany/commit/35e21eb65d4559685461007e1f39a75ef2c32178 Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] editing big files can be too slow with tag reparsing - HTML
[...] Pentium 4, 1.9 GHz, 512 MB ram. I'm no windows expert, but isn't 512mb considered kinda marginal, 1gb better. Whats your general windows performance like? Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] editing big files can be too slow with tag reparsing
Hey Colomban, [...] 0001-Per-document-real-time-symbols-setting.patch: Adds a per-document setting for real-time updates and a menu item in the Document menu. There is still a FIXME in it, feel free to give ideas :) This looks like a good idea. For the fixme, It shouldn't apply per document settings here, they are not in the prefs so they won't have changed. Just leave it out. 0002-Tell-the-user-if-real-time-reparsing-is-slow-and-let.patch: This one adds the check for the updating duration and asks the user. It is WIP, and I'm not really convinced by the dialog, as you can read in a TODO. Apart that, it seems to work pretty OK. Havn't had time to look at this, but as I said its a last resort. Both misses docs, up to come when they are ready. So, I'm soliciting your impressions, opinions, remarks, etc. Also, is this whole thing important enough to break string freeze less than a week before release? (read: to have some strings untranslated) I'm not Nick, but I would suggest leaving it until after release, thats not far away, and then as soon as it is committed Nick will have built a new version :) Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] editing big files can be too slow with tag reparsing - HTML
Le 27/09/2011 01:44, Lex Trotman a écrit : [...] Pentium 4, 1.9 GHz, 512 MB ram. I'm no windows expert, but isn't 512mb considered kinda marginal, 1gb better. Whats your general windows performance like? I doubt that, even on Windows, it would so drastically reduce the performances. Was your RAM completely full so it needed to swap? Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] editing big files can be too slow with tag reparsing
Le 27/09/2011 02:03, Lex Trotman a écrit :
Hey Colomban,
[...]
0001-Per-document-real-time-symbols-setting.patch:
Adds a per-document setting for real-time updates and a menu item in the
Document menu. There is still a FIXME in it, feel free to give ideas :)
This looks like a good idea.
For the fixme, It shouldn't apply per document settings here, they are
not in the prefs so they won't have changed. Just leave it out.
There is no prefs, but if autocompletion_update_freq is changed to or
from 0 (e.g. disabled or enabled), then we need to update the setting
for all documents where the user haven't done a choice. Otherwise the
setting would only change for newly opened documents, which is no good IMHO.
BTW, I just see I actually add a user_choice flag in 0002, so the info
is here:
foreach_document(i)
{
if (! documents[i]-priv-tag_list_update.user_choice)
documents[i]-priv-tag_list_update.user_choice =
editor_prefs.autocompletion_update_freq 0;
}
0002-Tell-the-user-if-real-time-reparsing-is-slow-and-let.patch:
This one adds the check for the updating duration and asks the user. It
is WIP, and I'm not really convinced by the dialog, as you can read in a
TODO. Apart that, it seems to work pretty OK.
Havn't had time to look at this, but as I said its a last resort.
Yeah, but if the user don't make a choice by accident just because she
was typing something else, I think it's better :)
Both misses docs, up to come when they are ready.
So, I'm soliciting your impressions, opinions, remarks, etc. Also, is
this whole thing important enough to break string freeze less than a
week before release? (read: to have some strings untranslated)
I'm not Nick, but I would suggest leaving it until after release,
thats not far away, and then as soon as it is committed Nick will have
built a new version :)
Agreed, apart that if it is a real problem, Nick won't be the only one
suffering of it. But Matthew tried on a Windows XP and didn't see any
issue, so it at least doesn't affect everybody... /me still wonders
what's happening.
Cheers,
Colomban
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] editing big files can be too slow with tag reparsing
[...]
There is no prefs, but if autocompletion_update_freq is changed to or
from 0 (e.g. disabled or enabled), then we need to update the setting
for all documents where the user haven't done a choice. Otherwise the
setting would only change for newly opened documents, which is no good IMHO.
Oops forgot about the global setting. But it shouldn't override a per
document setting chosen by the user. I think your below ensures it
doesn't?
BTW, I just see I actually add a user_choice flag in 0002, so the info
is here:
foreach_document(i)
{
if (! documents[i]-priv-tag_list_update.user_choice)
documents[i]-priv-tag_list_update.user_choice =
editor_prefs.autocompletion_update_freq 0;
}
0002-Tell-the-user-if-real-time-reparsing-is-slow-and-let.patch:
This one adds the check for the updating duration and asks the user. It
is WIP, and I'm not really convinced by the dialog, as you can read in a
TODO. Apart that, it seems to work pretty OK.
Havn't had time to look at this, but as I said its a last resort.
[...]
I'm not Nick, but I would suggest leaving it until after release,
thats not far away, and then as soon as it is committed Nick will have
built a new version :)
Agreed, apart that if it is a real problem, Nick won't be the only one
suffering of it. But Matthew tried on a Windows XP and didn't see any
issue, so it at least doesn't affect everybody... /me still wonders
what's happening.
I suspect we would have heard if it was a common problem, thats why I
think its ok to wait till after release. (I'm trying to save you work
:)
Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
