[Geany] UI rebuild in xfwm, project status in sessions, tag file append, compile error possitioning

Enrico Tröger enrico.troeger at xxxxx
Sun Jul 5 15:42:10 UTC 2009


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

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/users/attachments/20090705/343fee20/attachment.pgp>


More information about the Users mailing list