[aqualung-friends] Re: CVS commit (patch by Tomek)

[Tom S. <tsz...@us...>]

On Fri, 24 Jun 2005 01:20:01 +0200, pasp <pa...@ll...> wrote:

> > One minor point, though: I would like you to maintain
> > the code indentation in the future (so it fits with the
> > rest of the sources). We have an established standard of
> > 1 tab == 8 spaces everywhere.
>
> ahh, sorry for that.. but i use tab=4 spaces :) [the next patch will be
> correct]. can we add modelines to src files ?

I use emacs, and with it, the "-*- linux-c -*-" string in the comment
block at the top of each file does the trick. For this to work, you
need to put this in your .emacs file:

(defun linux-c-mode ()
  "C mode with adjusted defaults"
  (interactive)
  (c-mode)
  (c-set-style "K&R")
  (setq c-basic-offset 8))

If you use another editor, I suppose you can also set it to use 8 spaces.
If you need to place something else at the top of the files in a similar
manner, that's OK, just include it in your patches.


> >         * BackSpace key restarts current song
>
> following code should do the trick :)
> [...]

Very good, thank you. Committed.


> Tom, I have two questions...
>
> 1) Can we bump required version of GTK+ to 2.4.x or 2.6.x and port
> depreciated widgets to new ones ?

I would be happy to receive patches for converting deprecated widgets to
non-deprecated ones. If we're done with this (shouldn't take too long),
I will bump the GTK required version. Which is now just 2.0, not 2.4,
which may be incorrect since we may well be using 2.4 features. :)


> 2) There are many calls of deflicker() function in gui_main.c. Is this
> function really required ?

Yes, I believe it is. In an event handler (e.g. "change skin"'s button press
event) you want to make changes to the GUI which require much repainting.
If there are no explicit calls to process pending messages in the event
queue inside the event handler, GTK will only start processing when it
gets back to the main loop (out of the event handler). Our previous
experience showed that with many changes made to more than one window (eg.
changing the skin), GTK started to process messages in a somewhat broken
way; some windows start to appear, then disappear more than once in a short
period of time, and other strange things happen. The final result is good,
but it takes much longer for the painting to finish and it's an unwanted
thing for the user to see. We discovered that by manually flushing the
event queue after individual changes within the event handler (thus
effectively "committing" the changes to the screen), the bad behavior
could be stopped from appearing.

It could be that this is window manager dependent (we use Window Maker),
GTK version dependent (we started writing Aqualung with GTK 2.0), or
something else.

You can easily test if it really makes a difference if you comment out
the contents of the deflicker() function. :)


> If yes it shoud be as follows (for GTK+-2.x)
>
> while (g_main_context_iteration(NULL, FALSE));
>
> instead of
>
> while (gtk_events_pending())
>         gtk_main_iteration();

I have changed (and committed) this also.

Aqualung version bumped to 0.142.1.


Tom