Hi ...
I am a very happy Geany and Xfce user, and this is in fact my main dev. platform both at work and at home.
But as always, there are some minor details that annoy me, a bit.
* When using virtual windows in xfwm4, Geany seems to take some time (also processor wise) to rebuild the UI whenever i select the window Geany are in. This destroy the felling of a snappy IDE, and I like to know if anyone have looked into this problem. (yes I have a lot of files open :-))
* Sessions in xfce (and others desctops) are a very nice thing, and geany remembers a lot of good stuff, like saving open files, and what virtual window I was in last time (and the size and pos) at the project I was working on. But it does not save my last project layout. The only way of doing that (afaic) is to close geany via the menu, and reopen it again, then the project status is stored as expected. It would be nice if project status always got saved, or am I missing something ?
* when working with tags, it would be nice to be able to append info to a tag file, and not just make it in one big run. That way I could use it in a nested make structure.
* I'm I the only one having problems with error file location in complex file structures ?
I hope it don't seem like too much criticism, but I just like to know if anyone else have notices these things and if someone have plans to do something about it :-)
Regards ...
/BL
On Thu, 02 Jul 2009 18:59:39 +0200, Bo wrote:
Hey,
- When using virtual windows in xfwm4, Geany seems to take some time
(also processor wise) to rebuild the UI whenever i select the window
please be more descriptive. What parts of the UI are you referring to? What are virtual windows? I'm also using xfwm4 but never heard of such a thing.
- Sessions in xfce (and others desctops) are a very nice thing, and
geany remembers a lot of good stuff, like saving open files, and what virtual window I was in last time (and the size and pos) at the project I was working on. But it does not save my last project layout. The only way of doing that (afaic) is to close geany via the menu, and reopen it again, then the project status is stored as expected. It would be nice if project status always got saved, or am I missing something ?
I guess you mean that you want Geany to save its state (window position & size, last open project, ...) when you quit your Xfce session while Geany is still open? If so, I would also like to have this feature. But as far as I know to get this working we need to use libsm (part of Xorg AFAIK) to handle session management properly. This would cause another new dependency which isn't really nice. So, if this would be added, it needs to be fully optional, also because we don't have this on Windows. Maybe it could be even done as a plugin, that would be cool.
- when working with tags, it would be nice to be able to append info
to a tag file, and not just make it in one big run. That way I could use it in a nested make structure.
No idea what you mean, sorry.
- I'm I the only one having problems with error file location in
complex file structures ?
Again, be more descriptive please. What does "error file location in complex file structures" mean?
Regards, Enrico
Enrico Tröger wrote:
please be more descriptive. What parts of the UI are you referring to?
Now I remember why I am no language expert :-)
The entire Geany app. just frezz for a short while (and consumes a lot of CPU), I assume it is re-render some (editor ?) elements, but I can't see anything, other than CPU usage. The more files I have open, the longer the frezz gets.
What are virtual windows? I'm also using xfwm4 but never heard of such a thing.
Sorry my fault, workspace's it is called :)
I guess you mean that you want Geany to save its state (window position & size, last open project, ...) when you quit your Xfce session while Geany is still open?
Yes, I quess this is what I like it to do :-)
But I don't understand why Geany acts different on a manual shutdown and a session controlled shutdown. Why don't it just save the internal geany states, anyway ?
If so, I would also like to have this feature. But as far as I know to get this working we need to use libsm (part of Xorg AFAIK) to handle session management properly. This would cause another new dependency which isn't really nice. So, if this would be added, it needs to be fully optional, also because we don't have this on Windows.
I appreciate that priority !, and I too would like this option to work without being aware of a session manager.
Could geany save its states on a more regular basis (only when needed of cause), like on the save-all function, this would eliminate the "need of restart" problem ?
Maybe it could be even done as a plugin, that would be cool.
That all depend on the plugin interface, I quess :-)
No idea what you mean, sorry.
Hmm, when I like to make a custom tag file (for the XFC project) for Geany, I can ask geany to make this kind of file using the "--generate-tags" option.
But this make a brand new tag file each time.
I like to be able to call "geany --generate-tags" several times, while tag are inserted into an existing tag file, and not just creating a new file each time. Is this possible ?
Again, be more descriptive please. What does "error file location in complex file structures" mean?
Ok ...
I have a large project (again, XFC actually), that uses automake, and a lot or directories.
I have made a project where the base path, is the main project path (lets say ~/svn/XFC).
When I build this project, and get an error down in, lets say ~/svn/XFC/example/ui/printing/printing.cc, it will not position the editor and find the error. It is to be found in the compiler output, but Geany simply ignore the error.
When I do this in a project with not that deep dir structure, it works as expected.
Hope these explanations are more clear.
Regards
/BL
Bo Lorentsen schrieb:
The entire Geany app. just frezz for a short while (and consumes a lot of CPU), I assume it is re-render some (editor ?) elements, but I can't see anything, other than CPU usage. The more files I have open, the longer the frezz gets.
If you're using the projects plugins (that what replaces the build-in project), then it Geany will build a tag database for auto-completition)upon startup. That needs much CPU and takes some time. I thought too Geany was on fault until I noticed this.
Best regards.
On Sun, 05 Jul 2009 12:50:45 +0200, Bo wrote:
The entire Geany app. just frezz for a short while (and consumes a lot of CPU), I assume it is re-render some (editor ?) elements, but I can't see anything, other than CPU usage. The more files I have open, the longer the frezz gets.
No idea, sorry. First, I can't reproduce this assuming we are talking about switching from a workspace A to workspace B where Geany is running on B. And I'm not sure whether this is Geany's fault. At least Geany shouldn't do anything special when it gets the focus. Or maybe, it's related to the delayed colouring. Nick any idea?
I guess you mean that you want Geany to save its state (window position & size, last open project, ...) when you quit your Xfce session while Geany is still open?
Yes, I quess this is what I like it to do :-)
But I don't understand why Geany acts different on a manual shutdown and a session controlled shutdown. Why don't it just save the internal
Because this is not the same. On a manual shutdown, say by clicking the cross in the window title bar, we receive a "delete-event" signal from GTK and then we cleanup, save the state and quit. When using File->Quit or the toolbar button, it's the same, there we know directly that we want to quit. No problem. Same goes for kill geany, then we receive the signal 15 (SIGTERM) and we cleanup, save the state and quit.
BUT when the desktop session is shutdown, we don't receive any signal nor any other indication that we should quit ourselves cleanly. AFAIK the only way to get notice of a desktop session shutdown is to use libSM as I said earlier. I'd be happy if anyone proves me wrong and points out an easier way to handle this. Otherwise I might have a look at this issue and how much work it would be to make use of libSM.
Could geany save its states on a more regular basis (only when needed of cause), like on the save-all function, this would eliminate the "need of restart" problem ?
Not sure what you mean here. I don't like something like 'regularly saving the config' as it Pidgin does. This is weird, to me. Why should we save our state on 'save all', this seems totally unrelated.
Maybe it could be even done as a plugin, that would be cool.
That all depend on the plugin interface, I quess :-)
Only partly. The plugin basically only needs to say Geany that it should quit. This is indeed not completely trivial because simply running the main quit function wouldn't work as this function would unload the plugin which called the function...but this can be fixed.
No idea what you mean, sorry.
Hmm, when I like to make a custom tag file (for the XFC project) for Geany, I can ask geany to make this kind of file using the "--generate-tags" option.
But this make a brand new tag file each time.
I like to be able to call "geany --generate-tags" several times, while tag are inserted into an existing tag file, and not just creating a new file each time. Is this possible ?
Nope. But you can concatenate multiple tags files into one or just multiple tags files on their own.
Again, be more descriptive please. What does "error file location in complex file structures" mean?
Ok ...
I have a large project (again, XFC actually), that uses automake, and a lot or directories.
I have made a project where the base path, is the main project path (lets say ~/svn/XFC).
When I build this project, and get an error down in, lets say ~/svn/XFC/example/ui/printing/printing.cc, it will not position the editor and find the error. It is to be found in the compiler output, but Geany simply ignore the error.
When I do this in a project with not that deep dir structure, it works as expected.
Ah ok. Just to get sure, you don't have "~/..." literally in the project properties as base path? I doubt the tilde is properly substituted in all parts of the code. But even if not, maybe Geany's parsing of make's messages like 'Entering directory foo' is not smart enough or some other parts of the code fails to work with deep directory structures. A detailed test case would help. Do you use Geany 0.17? If so, you might get caught by the limitation that only the first 100 compiler messages are parsed. This is to increase performance by only parsing the top error messages because usually you are just interested in the first few compiler warnings/errors, fix them and then continue compiling. But it might be that if you already have lots of build output before, that the parsing stops before. You could check this either by recompiling Geany after heavily increasing the GEANY_BUILD_ERR_HIGHLIGHT_MAX macro at the beginning in src/build.c or by triggering a compiler warning/error early in the whole build output.
Hope these explanations are more clear.
Yes, thanks :).
Regards, Enrico
Enrico Tröger wrote:
No idea, sorry. First, I can't reproduce this assuming we are talking about switching from a workspace A to workspace B where Geany is running on B.
Yes, this is what I mean.
And I'm not sure whether this is Geany's fault. At least Geany shouldn't do anything special when it gets the focus. Or maybe, it's related to the delayed colouring.
Sounds interesting, is this the editor widget that "recolour" the open files ? In that case it could be the reason.
BUT when the desktop session is shutdown, we don't receive any signal nor any other indication that we should quit ourselves cleanly. AFAIK the only way to get notice of a desktop session shutdown is to use libSM as I said earlier. I'd be happy if anyone proves me wrong and points out an easier way to handle this. Otherwise I might have a look at this issue and how much work it would be to make use of libSM.
Hmm, ok ... I had hoped the session manager were a little more polite, like sending a nice kill other than 9 :-)
Not sure what you mean here. I don't like something like 'regularly saving the config' as it Pidgin does. This is weird, to me. Why should we save our state on 'save all', this seems totally unrelated.
Just trying to find a way to enforce a config persisting action, in Geany.
Only partly. The plugin basically only needs to say Geany that it should quit. This is indeed not completely trivial because simply running the main quit function wouldn't work as this function would unload the plugin which called the function...but this can be fixed.
Sounds simple, yes :-)
Nope. But you can concatenate multiple tags files into one or just multiple tags files on their own.
Ok, maybe I just need a "tag file merger/linker" then :-)
Ah ok. Just to get sure, you don't have "~/..." literally in the project properties as base path? I doubt the tilde is properly substituted in all parts of the code.
ok, I have been looking at the error code again, and it seems that automake, compiles a file in it's local dir. So it provide the following information :
Entering directory `/home/bl/svn/XFC/examples/ui/printing'
then (the error) :
... printing.cc:19: error: stray ‘#’ in program printing.cc:21: error: variable or field ‘on_draw_page’ declared void printing.cc:21: error: expected ‘;’ before ‘%’ token printing.cc:50: error: no ‘void PagePrinting::on_draw_page(Xfc::Gtk::PrintContext&, int)’ member function declared in class ‘PagePrinting’
and then :
Leaving directory `/home/bl/svn/XFC/examples/ui/printing'
The other project I have been working on uses cmake, which provide the full path, and geany can parse that in one go.
Either this dir info need to be parsed by Geany, or automake need to be instructed to provide full path ?
Do you use Geany 0.17?
Not anymore, using head ... :-)
/BL
On Sun, 05 Jul 2009 18:18:26 +0200, Bo wrote:
Enrico Tröger wrote:
No idea, sorry. First, I can't reproduce this assuming we are talking about switching from a workspace A to workspace B where Geany is running on B.
Yes, this is what I mean.
And I'm not sure whether this is Geany's fault. At least Geany shouldn't do anything special when it gets the focus. Or maybe, it's related to the delayed colouring.
Sounds interesting, is this the editor widget that "recolour" the open files ? In that case it could be the reason.
Only partly. If this is the reason, then your argument that it is slower the more files you have open doesn't make sense because this delayed colouring affects only the current document.
BUT when the desktop session is shutdown, we don't receive any signal nor any other indication that we should quit ourselves cleanly. AFAIK the only way to get notice of a desktop session shutdown is to use libSM as I said earlier. I'd be happy if anyone proves me wrong and points out an easier way to handle this. Otherwise I might have a look at this issue and how much work it would be to make use of libSM.
Hmm, ok ... I had hoped the session manager were a little more polite, like sending a nice kill other than 9 :-)
Maybe but if then it is something different from SIGTERM and SIGINT, these are *not* sent.
Not sure what you mean here. I don't like something like 'regularly saving the config' as it Pidgin does. This is weird, to me. Why should we save our state on 'save all', this seems totally unrelated.
Just trying to find a way to enforce a config persisting action, in Geany.
As long as you quit Geany so that Geany knows that it should quit, the config is persistent. The key is to make Geany knowing that it should quit :).
Ah ok. Just to get sure, you don't have "~/..." literally in the project properties as base path? I doubt the tilde is properly substituted in all parts of the code.
ok, I have been looking at the error code again, and it seems that automake, compiles a file in it's local dir. So it provide the following information :
Entering directory `/home/bl/svn/XFC/examples/ui/printing'
then (the error) :
... printing.cc:19: error: stray ‘#’ in program printing.cc:21: error: variable or field ‘on_draw_page’ declared void printing.cc:21: error: expected ‘;’ before ‘%’ token printing.cc:50: error: no ‘void PagePrinting::on_draw_page(Xfc::Gtk::PrintContext&, int)’ member function declared in class ‘PagePrinting’
and then :
Leaving directory `/home/bl/svn/XFC/examples/ui/printing'
The other project I have been working on uses cmake, which provide the full path, and geany can parse that in one go.
Either this dir info need to be parsed by Geany, or automake need to
The dir change info is parsed, i.e. Geany scans for "Entering directory `..." messages and adjust the path when parsing error messages. So it *should* work. And since it doesn't do for you, it's probably a bug. If you are bored enough, have a look at src/build.c in build_parse_make_dir().
Do you use Geany 0.17?
Not anymore, using head ... :-)
Even better :).
Regards, Enrico
Enrico Tröger wrote:
Only partly. If this is the reason, then your argument that it is slower the more files you have open doesn't make sense because this delayed colouring affects only the current document.
Ok, with this in mind I will test it even more next week, to see if there is any difference between having a lager and an small file in focus when switching workspace.
Maybe but if then it is something different from SIGTERM and SIGINT, these are *not* sent.
ok, now I know what need to be done ... more on the todo list :-)
As long as you quit Geany so that Geany knows that it should quit, the config is persistent. The key is to make Geany knowing that it should quit :).
Well back where i started, but a little wiser :-)
The dir change info is parsed, i.e. Geany scans for "Entering directory `..." messages and adjust the path when parsing error messages. So it *should* work. And since it doesn't do for you, it's probably a bug. If you are bored enough, have a look at src/build.c in build_parse_make_dir().
Ok, I will look into src/build.c next time it does not work to see if there is anything I can do about it :-)
/BL
On Sun, 5 Jul 2009 17:42:10 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sun, 05 Jul 2009 12:50:45 +0200, Bo wrote:
The entire Geany app. just frezz for a short while (and consumes a lot of CPU), I assume it is re-render some (editor ?) elements, but I can't see anything, other than CPU usage. The more files I have open, the longer the frezz gets.
No idea, sorry. First, I can't reproduce this assuming we are talking about switching from a workspace A to workspace B where Geany is running on B. And I'm not sure whether this is Geany's fault. At least Geany shouldn't do anything special when it gets the focus. Or maybe, it's related to the delayed colouring.
I can remember something similar when chaninging virtual desktops with not correct working composite configuration of XServer.
Cheers, Frank
On Sun, 05 Jul 2009 22:14:39 +0200 Bo Lorentsen bl@lue.dk wrote:
Frank Lanitz wrote:
I can remember something similar when chaninging virtual desktops with not correct working composite configuration of XServer.
But, this behavior does not apply other apps (firefox, thunderbird, pidgen).
OK. Just a thought ;)
Cheers, Frank
On Sun, 5 Jul 2009 17:42:10 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
The entire Geany app. just frezz for a short while (and consumes a lot of CPU), I assume it is re-render some (editor ?) elements, but I can't see anything, other than CPU usage. The more files I have open, the longer the frezz gets.
No idea, sorry. First, I can't reproduce this assuming we are talking about switching from a workspace A to workspace B where Geany is running on B. And I'm not sure whether this is Geany's fault. At least Geany shouldn't do anything special when it gets the focus. Or maybe, it's related to the delayed colouring. Nick any idea?
The delayed colouring should only colour the document if it is needed, so just switching workspaces should not trigger this - it will trigger some signal handlers but they should be fast in this case.
It's possible there's a bug in determining when a document needs recolouring, but I think switching workspaces won't trigger it.
You can try running Geany in GDB, press Ctrl-C, then: -------------- Program received signal SIGINT, Interrupt. 0x00110402 in __kernel_vsyscall () (gdb) b sci_colourise Breakpoint 2 at 0x80d7612: file sciwrappers.c, line 623. (gdb) command 2 Type commands for when breakpoint 2 is hit, one per line. End with a line saying just "end".
call utils_beep() c end
(gdb) c Continuing.
Breakpoint 2, sci_colourise (sci=0x9be3290, start=0, end=-1) at sciwrappers.c:623 623 SSM( sci, SCI_COLOURISE, start, end); --------------
This beeps every time Geany recolours a document.
Could geany save its states on a more regular basis (only when needed of cause), like on the save-all function, this would eliminate the "need of restart" problem ?
Not sure what you mean here. I don't like something like 'regularly saving the config' as it Pidgin does. This is weird, to me. Why should we save our state on 'save all', this seems totally unrelated.
Yes, and it would be strange when using multiple instances of geany, e.g. 2 instances overwriting the config file with different settings.
Regards, Nick
This beeps every time Geany recolours a document.
Ok, I tried it (gdb is a very cool debugger:-)) and it did not colourise when changing workspace.
The only thing, I can think of now, is missing double buffering in the editor widget. Could that cause this behavior ?
/BL
On Thu, 09 Jul 2009 18:28:05 +0200, Bo wrote:
This beeps every time Geany recolours a document.
Ok, I tried it (gdb is a very cool debugger:-)) and it did not colourise when changing workspace.
The only thing, I can think of now, is missing double buffering in the editor widget. Could that cause this behavior ?
Not sure. Maybe. But if so, it would be probably more a problem in Scintilla. Can you reproduce the issue with Scite?
Anyway, even if it would be the Scintilla widget, in one of your first mails you said it's the whole Geany UI which freezes, so it's rather unlikely Scintilla is at fault.
Frank mentioned composite settings (btw, please don't compare Geany with Firefox or Thunderbird, these are not really GTK apps :D), maybe it's related to this or to the used video driver or some weird combination of those.
But this should be easy to test with some other "real" GTK app which has a somewhat big UI (which pidgin not has compared to Geany's one).
Regards, Enrico
Enrico Tröger wrote:
Not sure. Maybe. But if so, it would be probably more a problem in Scintilla. Can you reproduce the issue with Scite?
Nope, and I guess it's more on my laptop (intel graphics), than on my desktop (nvidia).
In fact ... at the moment I can't replicate the problem any longer ...
Anyway, even if it would be the Scintilla widget, in one of your first mails you said it's the whole Geany UI which freezes, so it's rather unlikely Scintilla is at fault.
Yeps, it's seem quite fast to me, too.
Frank mentioned composite settings (btw, please don't compare Geany with Firefox or Thunderbird, these are not really GTK apps :D), maybe it's related to this or to the used video driver or some weird combination of those.
I know that mozilla products don't use GTK+, but I thought that they where a bit more heavy than GTK+, but why both used the same Xorg :-) Yes, I will try to see if I can find a more stable pattern for this behavior, and maybe its only my laptop that really have this effect.
But this should be easy to test with some other "real" GTK app which has a somewhat big UI (which pidgin not has compared to Geany's one).
I use pidgin all the time, but no "slow" GUI update here !
I will see if I can recreate the situation again, but it have gone as I wrote before ...
/BL
On Tue, 14 Jul 2009 20:17:00 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 09 Jul 2009 18:28:05 +0200, Bo wrote:
This beeps every time Geany recolours a document.
Ok, I tried it (gdb is a very cool debugger:-)) and it did not colourise when changing workspace.
The only thing, I can think of now, is missing double buffering in the editor widget. Could that cause this behavior ?
Not sure. Maybe. But if so, it would be probably more a problem in Scintilla. Can you reproduce the issue with Scite?
Anyway, even if it would be the Scintilla widget, in one of your first mails you said it's the whole Geany UI which freezes, so it's rather unlikely Scintilla is at fault.
Frank mentioned composite settings (btw, please don't compare Geany with Firefox or Thunderbird, these are not really GTK apps :D), maybe it's related to this or to the used video driver or some weird combination of those.
But this should be easy to test with some other "real" GTK app which has a somewhat big UI (which pidgin not has compared to Geany's one).
I had something like that also with Sylpheed. Maybe its worth to check.
Thanks, Frank
On Fri, 17 Jul 2009 08:44:07 +0200, Bo wrote:
Enrico Tröger wrote:
Not sure. Maybe. But if so, it would be probably more a problem in Scintilla. Can you reproduce the issue with Scite?
I have changed my WM from xfwm4 to compiz, and now the problem have gone totally.
This is still weird. I don't think it's xfwm4 to blame, would be interesting what's the real cause but of course, if it's working now for you, it's good enough.
Regards, Enrico