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