Re: GLib 2.26.0

[Martyn Russell]

On 14/10/10 12:18, Esben Stien wrote:

Ryan Lortiede...@desrt.ca  writes:


You can grab your 2.26.0 tarballs here:


Why isn't the website updated?


Thanks for updating this Tor.

--
Regards,
Martyn
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Cross plattform GTK look

[Robin Heggelund Hansen]

Hi!

I'm looking at making a program with GTK, but i really need the UI to look 
identical on Windows, Mac and Linux... This might have been simple if I were to 
use the standard engine... But I'm planing on making the UI look cool and not 
native as well, which might cause some problems I imagine...

From what I understand you define themes in a gtkrc file, but to get full 
flexability of the UI you need a gtk-engine as well... Can I force a 
gtk-program to use a specific engine, and are gtk-engines cross platform?

Thanks!
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Window as Popup

[benya]

Hello there,
I am trying to create a calculator window that has to popup on a button
press. 

The window pops up with the buttons on it, but when I press a button, the
event is not propagated or generated or the event handler is not called.

void on_recall_clicked (GtkWidget *widget, gpointer user_data){
recall_dialog(GTK_WINDOW(user_data));
}

void recall_dialog (GtkWindow *parent) {
   GtkWidget *calci, *content_area, *numTable; 
   GtkWidget *oneBut, *twoBut, *threeBut, *fourBut, *fiveBut, *sixBut,
*sevenBut,*eightBut,
   *nineBut, *zeroBut, *enterBut, *clearBut;
   
  /* Create the widgets */  
  calci = gtk_window_new(GTK_WINDOW_POPUP);
  gtk_window_set_default_size(GTK_WINDOW(calci), 300, 300); 
  gtk_window_set_position(GTK_WINDOW(calci), GTK_WIN_POS_CENTER);
  gtk_container_set_border_width(GTK_CONTAINER(calci), 10);   
  gtk_window_set_title(GTK_WINDOW(calci), Calculate a Receipt);   

...
adding the buttons and their event handler
...

g_signal_connect (G_OBJECT (calci), delete_event,
  G_CALLBACK (gtk_widget_destroy), NULL);
g_signal_connect (G_OBJECT (enterBut), destroy,
  G_CALLBACK (gtk_main_quit), NULL);

gtk_window_set_transient_for(GTK_WINDOW(calci),GTK_WINDOW(window));
gtk_widget_show_all (calci);

I am not sure what is wrong in my code. I am new to Gtk and I  would
appreciate any help on this. 
Thank you
Denny
-- 
View this message in context: 
http://old.nabble.com/Window-as-Popup-tp29953023p29953023.html
Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

grabbing focus to destination widget after drag-and-drop

[max ulidtko]

Hi list,

I'm having troubles in implementing rather simple but convenient
behaviour: my widget, which is accepting drag-and-drops from other
applications, should receive keyboard focus right after the drops. I'm
trying to achieve this using gtk_widget_grab_focus() inside
'drag-data-received' signal handler (as it turns out that this signal
is the last in d-n-d procedure which destination widget can receive;
connecting to 'drag-end' signal won't work). But the focus doesn't get
grabbed, and gtk_widget_has_focus() returns FALSE. How can i beat
this?


-
Regards,
max ulidtko
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

poll with timeout 0 in main loop

[Juan Pablo L .]

Hi, i have a problem with an application i m building with glib-2.24.2 on 
linux, i create a server socket which i use to create a GIOChannel and add it 
to a main loop, everything was fine until i found that the application consumes 
99.8% of the CPU while waiting for connections (doing nothing else just sitting 
there waiting for connections) and it gets even worse as new connections come 
in because i create a new loop in each connection (i create a thread for each 
connection) to deal with the incoming packages and each connection has N 
handlers to process the requests, each handler has its main loop for 
asynchronous communication between them and the connection thread that owns the 
handlers, so i did a strace and found out that the time out being passed to 
poll is 0 so for each iteration the poll returns inmediatly therefore i m stuck 
with a busy wait in all main loops, so i have read the documentation trying to 
find out how to modify this bahaviour but i could find nothing ab
 out it, can you please tell me why this is happenning ?? thanks!
  
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: poll with timeout 0 in main loop

[Maginot Junior]

On Thu, Oct 21, 2010 at 11:27 PM, Juan Pablo L. 
jpablolorenze...@hotmail.com wrote:


 Hi, i have a problem with an application i m building with glib-2.24.2 on
 linux, i create a server socket which i use to create a GIOChannel and add
 it to a main loop, everything was fine until i found that the application
 consumes 99.8% of the CPU while waiting for connections (doing nothing else
 just sitting there waiting for connections) and it gets even worse as new
 connections come in because i create a new loop in each connection (i create
 a thread for each connection) to deal with the incoming packages and each
 connection has N handlers to process the requests, each handler has its main
 loop for asynchronous communication between them and the connection thread
 that owns the handlers, so i did a strace and found out that the time out
 being passed to poll is 0 so for each iteration the poll returns inmediatly
 therefore i m stuck with a busy wait in all main loops, so i have read the
 documentation trying to find out how to modify this bahaviour but i could
 find nothing ab
  out it, can you please tell me why this is happenning ?? thanks!

 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



Can you post an snipt of your code?

And if you started a Thread and a loop inside it, it will stay interacting
if you don't stop it, this will consume CPU for sure. I think you must work
with signals or interrupts, I'm not sure about GIOChannel, maybe a snipt
would clear a bit.

[ ]'s


--
Maginot Júnior
LPIC 1 - LPIC 2 - LPIC 3 -  CCNA - CLA - Forensics Analyst
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: poll with timeout 0 in main loop

[Maginot Junior]

2010/10/22 Juan Pablo L. jpablolorenze...@hotmail.com

  hi, this is the code that makes the server socket

 // create the server socket and return the file descriptor
 fd = tcp_server_listerner_new(new_server-configurations,error);
 if(fd  0)
 {
 g_error(Could not create listener, server creation aborted:
 %s,error-message);
 g_error_free(error);
 return NULL;
 }

 // create the GIOChannel for the server socket
 new_server-socket = g_io_channel_unix_new(fd);
 // set the encoding safe to read binary data on the server GIOChannel
 g_io_channel_set_encoding(new_server-socket,NULL,NULL);

// create a source for connection events on the server socket
 new_server-event_source =
 g_io_create_watch(new_server-socket,G_IO_IN|G_IO_PRI|G_IO_ERR|G_IO_HUP|G_IO_NVAL);
 // set the callback function to handle connection events

 g_source_set_callback(new_server-event_source,(GSourceFunc)tcp_server_handle_connection_events,new_server,NULL);
 // attach the server socket connection event source to the server
 context
 g_source_attach(new_server-event_source,new_server-context);

new_server-main_loop = g_main_loop_new(new_server-context,FALSE);

 and this is how i run the main loop:

 void tcp_server_run(GMTCPServer *p_server)
 {
 // run the main loop now
 g_main_loop_run(p_server-main_loop);

 g_thread_exit(NULL);
 }

 this method is run from the main thread like this:

 gm_tcp_server-server_thread =
 g_thread_create((GThreadFunc)tcp_server_run,gm_tcp_server,TRUE,/*error*/NULL);

 and this is how i create the server socket:

 int tcp_server_listerner_new(const Configurations *p_configurations,GError
 **p_error)
 {
 int fd;
 struct sockaddr_in servAddr;
 int set_option = 1;

 // create the socket
 fd = socket(AF_INET,SOCK_STREAM,IPPROTO_TCP);
 if(fd  0)
 {
 *p_error =
 g_error_new(G_IO_CHANNEL_ERROR,G_IO_CHANNEL_ERROR_FAILED,Could not create
 server socket: %s,strerror(errno));
 return -1;
 }
 // set some options on the socket
 fcntl(fd,F_SETFL,O_NONBLOCK);// set the socket non-blocking

 setsockopt(fd,SOL_SOCKET,SO_REUSEADDR,set_option,sizeof(set_option));//
 reuse address

 setsockopt(fd,SOL_SOCKET,SO_KEEPALIVE,set_option,sizeof(set_option));//
 send keep alive messages

 // construct local address structure
 memset(servAddr,0x00, sizeof(servAddr));
 servAddr.sin_family = AF_INET;
 servAddr.sin_addr.s_addr =
 inet_addr(p_configurations-tcp_server.interface);
 servAddr.sin_port = htons(p_configurations-tcp_server.port);
 // Bind to the local address
 if(bind(fd,(struct sockaddr*)servAddr,sizeof(servAddr))  0)
 {
 *p_error =
 g_error_new(G_IO_CHANNEL_ERROR,G_IO_CHANNEL_ERROR_FAILED,Could not bind
 server socket: %s,strerror(errno));
 // close the socket
 close(fd);
 return -1;
 }
 if(listen(fd,10)  0)
 {
 *p_error =
 g_error_new(G_IO_CHANNEL_ERROR,G_IO_CHANNEL_ERROR_FAILED,Could not start
 listening on the server socket: %s,strerror(errno));
 // close the socket
 close(fd);
 return -1;
 }

 return fd;
 }


 thanks !


 --
 Date: Fri, 22 Oct 2010 00:06:08 -0200
 Subject: Re: poll with timeout 0 in main loop
 From: maginot.jun...@gmail.com
 To: jpablolorenze...@hotmail.com
 CC: gtk-app-devel-list@gnome.org



 On Thu, Oct 21, 2010 at 11:27 PM, Juan Pablo L. 
 jpablolorenze...@hotmail.com wrote:


 Hi, i have a problem with an application i m building with glib-2.24.2 on
 linux, i create a server socket which i use to create a GIOChannel and add
 it to a main loop, everything was fine until i found that the application
 consumes 99.8% of the CPU while waiting for connections (doing nothing else
 just sitting there waiting for connections) and it gets even worse as new
 connections come in because i create a new loop in each connection (i create
 a thread for each connection) to deal with the incoming packages and each
 connection has N handlers to process the requests, each handler has its main
 loop for asynchronous communication between them and the connection thread
 that owns the handlers, so i did a strace and found out that the time out
 being passed to poll is 0 so for each iteration the poll returns inmediatly
 therefore i m stuck with a busy wait in all main loops, so i have read the
 documentation trying to find out how to modify this bahaviour but i could
 find nothing ab
  out it, can you please tell me why this is happenning ?? thanks!

 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



 Can you post an snipt of your code?

 And if you started a Thread and a loop inside it, it will stay interacting
 if you don't stop it, this will consume CPU for sure. I think you must work
 with signals or interrupts, 

Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]

[Tristan Van Berkom]

On Thu, 2010-10-21 at 14:51 +0900, Tristan Van Berkom wrote:
 On Thu, 2010-10-21 at 14:10 +0900, Tristan Van Berkom wrote:
  On Thu, 2010-10-21 at 13:57 +0900, Tristan Van Berkom wrote:
   On Mon, 2010-10-18 at 01:28 -0400, Havoc Pennington wrote:
Hi,

On Sun, Oct 17, 2010 at 11:58 PM, Tristan Van Berkom
trista...@openismus.com wrote:

 What happens when another subclass wants to use
 -adjust_size_allocation() to realign itself further ? how
 can it cooperate with GtkWidgetClass and not cause bad side
 effects ?

In the patch I posted (assuming the FIXME is fixed), what would still 
be broken?
I'm sort of lost what problems are unsolved. Granted, I might find out
if I tested the patch ;-)

   
   This part will be re-broken, in this patch you are not adjusting the
   allocated width for margins and alignments *before* getting the height
   for the real allocated width:
   
   ---
 adjusted_allocation = real_allocation;
 if (gtk_widget_get_request_mode (widget) ==
 GTK_SIZE_REQUEST_HEIGHT_FOR_WIDTH)
   {
 int min_width;
   
 gtk_widget_get_preferred_width (widget, min_width,
 natural_width);
 /* natural_width is a white lie; it's reduced to the
  * actual allocation but kept above min.
  */
 if (natural_width  real_allocation.width)
   natural_width = MAX(real_allocation.width, min_width);
 gtk_widget_get_preferred_height_for_width (widget, natural_width,
NULL, natural_height);
   }
 else ...
   ---
   
   And then it goes on too adjust the allocations after checking
   the height for width:
   ---
   
 GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_HORIZONTAL,
natural_width,
adjusted_allocation.x,
adjusted_allocation.width);
 GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_VERTICAL,
natural_height,
adjusted_allocation.y,
adjusted_allocation.height);
   ---
   
   Let's see what we can do with this api... it would have to be
   something more like:
   
  
  Actually even that is wrong, since we're passing a size that
  has it's margins stripped to get_height_for_width(), which
  will do the operation again on the for_size.
  
  So it needs to add another line:
  
   ---
   
   if (widget_is_height_for_width) {
   
 gtk_widget_get_preferred_width (widget, min_width,
 natural_width);
 GTK_WIDGET_GET_CLASS (widget)-adjust_size_allocation (widget,
GTK_ORIENTATION_HORIZONTAL,
natural_width,
adjusted_allocation.x,
adjusted_allocation.width);
  
  After adjusting adjusting the allocated width with the aid of the real
  natural width... we get a new adjusted_allocation.width, before passing
  that width to get_preferred_height_for_width we need to:
  
  gint adjusted_allocated_width = adjusted_allocation.width;
  
  GTK_WIDGET_GET_CLASS (widget)-adjust_size_request(widget, 
 GTK_ORIENTATION_HORIZONTAL,
 /* for_size is never needed
for this api afaics */
 adjusted_allocated_width,
 NULL);
  
  And then we need to call get_height_for_width () to obtain the natural
  height for the allocated width... /after/ adding some margins to the
  inner allocated width, since those margins will be removed from the
  for_size deep inside get_height_for_width() and then others re-added 
  to the output natural height.
  
  Thanks for trying a patch out with this new API (it helps alot), 
  I'll try updating the patch to do what I think it needs to do and 
  send that one back.
  
  I'll remove the for_size argument from -adjust_size_request() as
  well since it's not used anywhere and I cant imagine what it can
  be used for.
  
 
 I've attached my patch here, with your API approach seems everything
 falls into place.
 
 Besides the changes I outlined above I also had to change GtkContainer
 

Re: Doubts about GPeriodic

[Havoc Pennington]

Another issue, seems like the ticker needs to be per-native-window:

* the GL context is per-window so the vsync mechanism also is

* we ought to shut down the ticker on windows that aren't visible

* each screen has its own vsync and the window is the normal
convention to imply a screen

* the general principle that widgets should be getting context and
state from parent widgets, in most cases ultimately from the toplevel
- but by chaining through parents. Rather than from global singletons
or state. attempted to explain in
http://log.ometer.com/2010-09.html#19 (so any gtk widget that's a
child of a clutter stage for example, would want to be asking that
clutter stage for paint clock)

Native windows would be either toplevels or embedded clutter/glarea
widgets, generally. But maybe just saying any native window can have
its own clock is right.

There probably shouldn't even be a global API because using it would
be broken, right?

When not actually using GL or vsync, then I think all native windows
could just inherit a single global ticker that would just be a
timeout, but that's more of an implementation detail than an API
thing.

Another thought, in the patch
   periodic-last_run = now;
I think this will look a little rocky - the frames are going to
display at actual-screen-hz intervals, no matter what time it is when
you record last_run and no matter what time it is when you call your
drawing APIs. So things look better if you keep the tween timestamp
on hz intervals. The last_run time probably has very little to do with
when frames hit the display. Animations should go ahead and paint
assuming they are hitting the display at a fixed fps.

In the litl shell fwiw the pseudocode for the tween time on each frame is:

int frame_time = 1000 / fps;
int actual_time = time since start of animation - current_ticker_time;
int frames_late = (actual_time / frame_time) - 1;
current_ticker_time += frame_time;
 if (frames_late  0) {
current_ticker_time += (frame_time * (frames_late + 1));
 }

The idea of this is: decide to drop frames based on floor(frames_late)
and then skip ahead by ceil(frames_late). The point of that is to bias
against dropping a frame until we're a full frame behind, but then be
sure we drop enough frames to get ahead a bit when we do drop them,
and always stay on a multiple of the refresh rate.

Due to this and also the desire to not explode when the computer's
clock is set, I would define the ticker to be a monotonic value that
is in time units but is not a wall clock time. i.e. if I change my
computer's clock back an hour, the ticker should keep marching
forward, and the ticker is allowed to be fudged to make animations
pretty.

Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Doubts about GPeriodic

[Emmanuele Bassi]

On Thu, 2010-10-21 at 03:09 -0400, Havoc Pennington wrote:
 Another issue, seems like the ticker needs to be per-native-window:
 
 * the GL context is per-window so the vsync mechanism also is

no, the GL context should *not* be per window. multiple GL contexts
usually pose more problems than they solve, in synchronization and
context switching, on basically all drivers - except maybe on nvidia[0].

this has nothing to do about whether GPeriodic should be per-window or a
global singleton - it's just that multiple contexts in a single process
are generally a no-no.

 Due to this and also the desire to not explode when the computer's
 clock is set, I would define the ticker to be a monotonic value that
 is in time units but is not a wall clock time. i.e. if I change my
 computer's clock back an hour, the ticker should keep marching
 forward, and the ticker is allowed to be fudged to make animations
 pretty.

the g_source_get_current_time() function will use the monotonic clock on
Linux assuming you link against gthread; since gobject does that, we can
safely assume that it will be using a monotonic clock.

ciao,
 Emmanuele.

[0] the first implementation of Clutter used multiple contexts, one for
each top-level, and shared the texture list to allow sharing resources
across top-levels; it did not have nice results - ironically, mostly on
fglrx, so I couldn't even look at a solution.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Doubts about GPeriodic

[Emmanuele Bassi]

On Thu, 2010-10-21 at 09:26 +0100, Emmanuele Bassi wrote:

 the g_source_get_current_time() function will use the monotonic clock on
 Linux assuming you link against gthread; since gobject does that, we can
 safely assume that it will be using a monotonic clock.

sorry, I'm confusing myself with a patch from Maemo:

  https://bugzilla.gnome.org/show_bug.cgi?id=540545

that I thought we already applied...

for monotonic sources, g_thread_gettime() is the monotonic clock API.

nothing to see here, move along... :-)

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Doubts about GPeriodic

[Ryan Lortie]

hi Havoc,

First I want to note that GPeriodic was only an attempt to get the
timing right.  It's just a clock.  It is not in any way meant to provide
policy about how a paint cycle is actually run.

That said, I did make a Gtk branch with some crackful experimentation
(currently shoving GPeriodic into gdkthreads in a global way).  This is
not meant to be the way -- it was just a convenient place to stick it
for now so that we could experiment with getting some widgets animating
using it.  Of course, we're discovering that resize handling and stuff
is quite difficult (another mail for all that stuff).

It's worth noting, though, that Emmanuele was able to get Clutter's
paint cycle working on top of it without modification, so there is
something here...

Anyway.  GPeriodic is just a clock, so let's talk timing.

On Thu, 2010-10-21 at 03:09 -0400, Havoc Pennington wrote:
 Another thought, in the patch
periodic-last_run = now;
 I think this will look a little rocky - the frames are going to
 display at actual-screen-hz intervals, no matter what time it is when
 you record last_run and no matter what time it is when you call your
 drawing APIs. So things look better if you keep the tween timestamp
 on hz intervals. The last_run time probably has very little to do with
 when frames hit the display. Animations should go ahead and paint
 assuming they are hitting the display at a fixed fps.

This is something that gave me a great deal of pause, and is a rather
interesting question.  I'll attach the full code fragment in its current
form, for context:

  /* Update the last_run.
   *
   * In the normal case we want to add exactly 1 tick to it.  This
   * ensures that the clock runs at the proper rate in the normal case
   * (ie: the dispatch overhead time is not lost).
   *
   * If more than one tick has elapsed, we set it equal to the current
   * time.  This has two purposes:
   *
   *   - sets last_run to something reasonable if the clock is running
   * for the first time or after a long period of inactivity
   *
   *   - resets our stride if we missed a frame
   */
  now = g_periodic_get_microticks (periodic);
  elapsed_ticks = (now - periodic-last_run) / 100;
  g_assert (elapsed_ticks  0);

  if G_LIKELY (elapsed_ticks == 1)
periodic-last_run += 100;
  else
periodic-last_run = now;

[[and yes, I'm using G_LIKELY strictly for documentation purposes]]

In the usual case, it's true that the ticker (which is expressed in
microframes, by the way) is advanced exactly one frame when dispatching
from the main context (ie: free-running clock with no external synch
information from vblank).

The only place I disagree with you is on what to do when we want to skip
a frame.

 In the litl shell fwiw the pseudocode for the tween time on each frame is:
 
 int frame_time = 1000 / fps;
 int actual_time = time since start of animation - current_ticker_time;
 int frames_late = (actual_time / frame_time) - 1;
 current_ticker_time += frame_time;
  if (frames_late  0) {
 current_ticker_time += (frame_time * (frames_late + 1));
  }

 The idea of this is: decide to drop frames based on floor(frames_late)
 and then skip ahead by ceil(frames_late). The point of that is to bias
 against dropping a frame until we're a full frame behind, but then be
 sure we drop enough frames to get ahead a bit when we do drop them,
 and always stay on a multiple of the refresh rate.

This is an interesting proposal.

The problem when the clock is free-running is that we don't know exactly
what side of the vblank we're on.  That's the point of resetting the
stride (ie: assuming that the new top-of-the-frame time is now).  That
might end up being right, or it might be wrong.  In the event that we
are late for only one frame, it's a cointoss.

On the other hand, if we are consistently dropping frames -and- are
unaware of the vblank, I think I could mount a statistical argument that
my approach is more likely to result in a more smooth/accurate animation
(say, RMS of correct position vs. actual position for each frame that
actually hits the monitor).

Far more interesting, I think is in unblock():

  periodic-last_run = g_periodic_get_microticks (periodic);

In the event that we *do* have vblank information, we set the counter to
exactly the wallclock time at some semi-random interval (namely:
whenever our process bothered to notice the notification from the X
server).

I'm actively unhappy with that.  I was talking with Emmanuele about the
information that's in the vblank notification we get from the server.
There is timestamp information there.  I'd be quite a lot happier if we
had a method to inject that information into GPeriodic (ie: a timestamp
parameter on the unblock API).

 Due to this and also the desire to not explode when the computer's
 clock is set, I would define the ticker to be a monotonic value that
 is in time units but is not a wall clock time. i.e. if I change my
 computer's clock back an hour, the 

Re: Doubts about GPeriodic

[Ryan Lortie]

Hi Owen,

A few questions, if you don't mind me picking your brain:

On Wed, 2010-10-20 at 14:58 -0400, Owen Taylor wrote:
 The real problem is that the phases of the repaint cycle matter. We
 don't just have a bunch of stuff we need to do every frame, we need to
 do things in the order:
 
  * Process events

The only benefit I see to processing input events at the start of a
frame cycle is that we possibly get to merge them.  We probably do want
that.

What about non-input events, though?  Like, if some download is
happening and packets are coming in and causing dispatches from the
mainloop that we do not have control over.

Do we try to ensure that those people treat this 'external stimulus' in
the same way that we treat events (ie: possibly merge multiple incoming
packets so that they update their UI state only once in response to it)
or do we want them to just call the GTK API on the spot and risk
duplicated work because that's quite a lot easier to understand?

Maybe we should have some mechanism that allows them to choose.

If we elect not to have that mechanism, then the input problem is
actually quite easy, by virtue of the fact that there is only ever one
person managing input from the X server.

  * Update animations

tick

  * Update layout

Clutter and GDK want to do two different things here, it seems.
Presently (and almost by chance) GPeriodic is emitting a tick signal
after running all of the tick functions and Emmanuele is using this to
run stage updates on all of the Clutter stages.  This is a little bit
like Gtk managing it's geometry but not exactly.

In Gtk's case, we have a chance to do this a bit more programmatically -
only run layout adjustments on widgets/windows that have been marked as
requiring some resize (ie: toplevels and containers with
GTK_RESIZE_QUEUE themselves).  That could be handled from a 'tick'
handler, or we could add some more hooks to GPeriodic.

A reason that I think it makes sense to do layout updates separate from
repainting is that layout updates can result in us wanting to change the
size of our toplevels (eg: someone opened GtkExpander).

This is a *really* tough problem because if that happens, we can't just
paint.  We have to wait until the window manager has actually given us
our new size.  I did some benchmarking, and that tends not to happen
until about 1ms later (a bit less for metacity, a bit more for compiz
and mutter).

So do we block the mainloop for ~1-2ms and desperately suck from the X
socket until we receive ConfigureNotify (at least until some timeout)?
Do we skip drawing the window and wait until next frame if we have a
pending ConfigureNotify?  Is there some way we can abuse
_NET_WM_SYNC_REQUEST to make this problem easier?


On the Gtk experiment branch, layout updates are actually done pretty
much on the spot right now (ie: you make some changes to the layout
which will queue a idle that will run pretty much immediately).  There
have been no changes to this part yet.

  * Repaint

This part is what I originally intended the damage/repair mechanism to
be used for.

 If GTK+ and Clutter are working together in the same process, then we
 still need to go through those phases in the same order and do
 everything for each phase.
 
 It looks like GPeriodic has two phases:
  
  - Tick
  - Repair
 
 Which I guess are meant to be update animations and relayout and
 repaint. I can sort of see how I can squeeze the right behavior out of
 it given various assumptions. In particular, you need to only ever have
 one one repair function that does all the work of relayout then repaint
 - you can't have separate repair functions for relayout and repaint. Or
 for clutter and for GTK+.

GPeriodic is probably going to need to gain some more phases, indeed.  I
don't plan to have relayout and repaint shoved into the same stage for
the reasons listed above, but also for reasons of sanity.

 But does an abstraction make sense at that point? If we need to
 explicitly glue GTK+ into clutter or clutter into GTK+ using hooks
 provided in GTK+ and Clutter, then all that GPeriodic is doing is saving
 a bit of code reuse.

Right.  Another way we could do this is by having some hooks in Gtk:

  - do this
  - do that
  - do the other thing

and have those clocked internally by Gdk in the Gtk-runs-itself case and
by Clutter in the Clutter-runs-Gtk case.

That certainly could make sense for the set tasks like layout,
drawing, etc.  In fact, all of these things could be driven by
one-big-handler on the tick signal that GPeriodic currently emits.

For timeline advancement, however (ie: the stuff that the user wants to
do) I think an abstraction like GPeriodic is quite useful.  It gives a
common place that users can register their animation hooks that works
the same way for both Clutter and Gtk.  It prevents us from having some
timeline system within Gtk that is clocked by Clutter telling Gtk run
all your timelines now!.  Cody is creating a timeline class right now
as part of 

Re: Doubts about GPeriodic

[Havoc Pennington]

Hi,

On Thu, Oct 21, 2010 at 4:26 AM, Emmanuele Bassi eba...@gmail.com wrote:
 no, the GL context should *not* be per window. multiple GL contexts
 usually pose more problems than they solve, in synchronization and
 context switching, on basically all drivers - except maybe on nvidia[0].

Fair enough, I didn't realize it was actually possible to do one
global context for all windows.

I would still argue for per-window (so we can shut down
unmapped/hidden windows and so widgets look at parent, not a global)

Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Doubts about GPeriodic

[Havoc Pennington]

Hi,

On Thu, Oct 21, 2010 at 5:46 AM, Ryan Lortie de...@desrt.ca wrote:

 What about non-input events, though?  Like, if some download is
 happening and packets are coming in and causing dispatches from the
 mainloop that we do not have control over.

I brought this up a bit in the earlier thread.

My takeaway is that for I/O type stuff you usually want what we ended
up with at litl, which is to limit it to some length of time per
frame. Unfortunately GMainLoop has no native way to do that. I
described our solution a bit in the old paint clock thread.

There's a danger both of some random download starving animation and
of your download spinner starving the download.

Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib 2.26.0

[Martyn Russell]

On 14/10/10 12:18, Esben Stien wrote:

Ryan Lortiede...@desrt.ca  writes:


You can grab your 2.26.0 tarballs here:


Why isn't the website updated?


Thanks for updating this Tor.

--
Regards,
Martyn
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk+-3 trunk compilation as documented in gtk-doc and libtool quick-fix

[Ralf Wildenhues]

Hello Ingo,

thanks for the report.

* Ingo Krabbe wrote on Tue, Sep 28, 2010 at 10:07:44AM CEST:
 The problem with both of those programs was, that the libtool link
 wrapper had build a LD_LIBRARY_PATH that contained the system directory
 /usr/lib64 before $prefix/lib, as it found as a sub-dependency of
 the local gtk-x11.la and gdk-x11.la, some global .la files such as
 libXinerama.la, before the more local ones libpangocairo*.la for
 example.
 
 And that how the LD_LIBRARY_PATH of the wrapper has been built, not
 obeying the link order given by -L and -R flags, that have been
 calculated in the right order.

Can you please send the build output for those programs, I'd especially
be interested in the 'libtool --mode=link' command lines for the
programs, and all output they generate.

Even better would be a small reproducible example.

Is this on GNU/Linux?

 As I hope this helps you further, I want to provide that patch against
 libtool, and I hope that it will make into libtool development or is a
 good anchor point to modify libtool in a different way.

Well, for a patch we definitely need something reproducible.
The patch itself has problems too (BTW, it is easier to comment on if
you send it inline or with text/x-patch or text/plain); see below.

Instead of the patch, I'm guessing that the actual problem lies
somewhere else completely: libtool thinks /usr/lib64 isn't in
sys_lib_search_path_spec or not in sys_lib_dlsearch_path_spec.
Can you try out the following for me:

If your generated libtool script does not list /usr/lib64 in these
variables, add it there please and rebuild.  If generated .la files
(either from your build, or from previously installed libraries you
link against) contain -L/usr/lib64 entries, they are most likely all
wrong, too, and should be removed.  I'm guessing that these two changes
will fix your build.

Just for the record:

 --- a/libltdl/config/ltmain.m4sh
 +++ b/libltdl/config/ltmain.m4sh
 @@ -4356,6 +4356,10 @@ func_mode_link ()
  xrpath=
  perm_rpath=
  temp_rpath=
 +nl_add=# nl_add will contain a converted newlib_search_path
 +   # to be added to temp_rpath for the wrapper
 +abs_base=$(cd `dirname $0`  pwd) # this is used to check if a path is

unfortunately, $(cmd) command substitution is not something we can
portably rely on just yet.  libtool has func_dirname and progpath
instead of dirname and $0.

This heuristic will fail in packages that contain sub-configure scripts,
IOW a package hierarchy, where you may link against uninstalled
libraries from sibling packages.

 +   # relative to our build directory
  thread_safe=no
  vinfo=
  vinfo_number=no
 @@ -5839,6 +5843,15 @@ func_mode_link ()
test -z $old_library; }; then
 # We need to hardcode the library path
 if test -n $shlibpath_var  test -z $avoidtemprpath ; then
 + # quick and dirty patch to obey -L and -R options in the wrapper
 + # script
 + if [ -z $nl_add ]; then case $absdir in
 +   *$abs_base*) ;; # when we leave the build base
 +   *)# we will simply add newlib_search_path
 + nl_add=$(printf $newlib_search_path| sed -e s/ 
 *\(.*\)$/\1/|tr \\040 :)

See above on $(...)
printf interprets its argument; inside libtool, use $ECHO, and
elsewhere, use
  printf %s\n ...

\040 is ASCII-specific.


 + temp_rpath+=$nl_add:

+= is bash-specific.  (The generated libtool script contains them only
if we know we're running bash.)

 + ;;
 + esac fi
   # Make sure the rpath contains only unique directories.
   case $temp_rpath: in
   *$absdir:*) ;;

Hope that helps.

Cheers,
Ralf
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

gtk+-3 trunk compilation as documented in gtk-doc and libtool quick-fix

[Ingo Krabbe]

Hi,

I know you want to tell me to use jhbuild to compile gtk+-3 and friends,
but I don't like such tools and I tried to do my own build which worked
quite fine until I encountered small errors during the build of gtk+-3
itself, when programs, linked during the build later got called from the
build.  There where two of such programs I detected:

gtk/gtk-query-immodules-3.0

and as I compiled with --enable-gtk-doc --enable-man:

docs/reference/gtk/gtk3-scan

which is a temporary executable done by gtkdoc tools.

The problem with both of those programs was, that the libtool link
wrapper had build a LD_LIBRARY_PATH that contained the system directory
/usr/lib64 before $prefix/lib, as it found as a sub-dependency of
the local gtk-x11.la and gdk-x11.la, some global .la files such as
libXinerama.la, before the more local ones libpangocairo*.la for
example.

And that how the LD_LIBRARY_PATH of the wrapper has been built, not
obeying the link order given by -L and -R flags, that have been
calculated in the right order.

Luckily libtool-2.4.1a from libtool git master, had a newlib_search_path
constructed at the time the wrapper is built, that contains the
whitespace seperated list of -L and -R paths arguments, so that I could
do a quick fix with a little sed, to strip the leading space and tr to
convert spaces into a colon.

As I hope this helps you further, I want to provide that patch against
libtool, and I hope that it will make into libtool development or is a
good anchor point to modify libtool in a different way.

I will be glad too if you, dedicated developers of gtk+ and libtool
would make your comments on it and discuss that patch with me and the
possibilities to do it else, as the building of LD_LIBRARY_PATHs for the
wrappers seems to me as a severe and long-term problem of libtool.

Anyway with this patch the gtk+-3 trunk compilation works like charme
here, with simple autogen.sh, make, make install commands:

# this is what I use to configure.
#   INSTPATH can be set as preferred
PATH=$INSTPATH/bin:$PATH
PKG_CONFIG_PATH=$INSTPATH/lib/pkgconfig
export PKG_CONFIG_PATH PATH

export INSTPATH
LD_LIBRARY_PATH=${INSTPATH}/lib
export LD_LIBRARY_PATH
export ACLOCAL_FLAG=-I $INSTPATH/share/aclocal
./autogen.sh --prefix=${INSTPATH} --enable-gtk-doc --enable-man

bye ingo


-- 
i don't do signatures
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 0418007..13fbe05 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -4356,6 +4356,10 @@ func_mode_link ()
 xrpath=
 perm_rpath=
 temp_rpath=
+nl_add=# nl_add will contain a converted newlib_search_path
+   # to be added to temp_rpath for the wrapper
+abs_base=$(cd `dirname $0`  pwd) # this is used to check if a path is
+   # relative to our build directory
 thread_safe=no
 vinfo=
 vinfo_number=no
@@ -5839,6 +5843,15 @@ func_mode_link ()
   test -z $old_library; }; then
# We need to hardcode the library path
if test -n $shlibpath_var  test -z $avoidtemprpath ; then
+ # quick and dirty patch to obey -L and -R options in the wrapper
+ # script
+ if [ -z $nl_add ]; then case $absdir in
+   *$abs_base*) ;; # when we leave the build base
+   *)# we will simply add newlib_search_path
+ nl_add=$(printf $newlib_search_path| sed -e s/ 
*\(.*\)$/\1/|tr \\040 :)
+ temp_rpath+=$nl_add:
+ ;;
+ esac fi
  # Make sure the rpath contains only unique directories.
  case $temp_rpath: in
  *$absdir:*) ;;


pgpLFlGPqBEaW.pgp
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

g-ir-scanner fails when using ccache

[Natanael Copa]

Hi,

I noted that packages like dconf fails to build when CC is set to
ccache gcc. Setting it to gcc makes it compile. I traced it to the
introspection compiler.

I use gobject-introspection-0.9.10

To reproduce, unpack dconf-0.5.1 and run configure. Then make sure
ccache is installed and run make like this:

  make CC=ccache gcc

I get:
...
  GENlibdconf.so
  GISCAN dconf-1.0.gir
Traceback (most recent call last):
  File /usr/bin/g-ir-scanner, line 45, in module
sys.exit(scanner_main(sys.argv))
  File /usr/lib/gobject-introspection/giscanner/scannermain.py, line
405, in scanner_main shlibs = create_binary(transformer, options, args)
  File /usr/lib/gobject-introspection/giscanner/scannermain.py, line
309, in create_binary gdump_parser.get_get_type_functions())
  File /usr/lib/gobject-introspection/giscanner/dumper.py, line 233,
in compile_introspection_binary return dc.run()
  File /usr/lib/gobject-introspection/giscanner/dumper.py, line 140,
in run self._link(bin_path, o_path)
  File /usr/lib/gobject-introspection/giscanner/dumper.py, line 228,
in _link subprocess.check_call(args)
  File /usr/lib/python2.6/subprocess.py, line 493, in check_call
retcode = call(*popenargs, **kwargs)
  File /usr/lib/python2.6/subprocess.py, line 480, in call
return Popen(*popenargs, **kwargs).wait()
  File /usr/lib/python2.6/subprocess.py, line 633, in __init__
errread, errwrite)
  File /usr/lib/python2.6/subprocess.py, line 1139, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
make[1]: *** [dconf-1.0.gir] Error 1
make[1]: Leaving directory
`/home/ncopa/aports/wip/dconf/src/dconf-0.5.1/client' make: ***
[all-recursive] Error 1

When CC=gcc then it works.

Thanks!

-nc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

issues in my gtk builder code

[javier godas vieitez]

hi, I am making a little gtk-c-shell program and i need to boot up an glade 
file, so i did it, but my intemption is to make it as an presentation, so once 
you press enter, i want to destroy that window and do another command

This my mistaked code:

// Compilar con: gcc -o init init.c $(pkg-config --cflags --libs gtk+-2.0 
gmodule-2.0) -lncurses//
#include stdio.h
#include stdlib.h
#include string.h
#include gtk/gtk.h
#include curses.h
 
int
main( intargc,
  char **argv )
{
GtkBuilder *builder;
GtkWidget  *window;
GError *error = NULL;

int tecla;
 
// Iniciar GTK+ //
gtk_init( argc, argv );

/* Inicializar la operacion de ncurses */
initscr ();
 
// Crer nuevo objeto de GtkBuilder //
builder = gtk_builder_new();

// Cargar la UI desde archivo. Si da error, lo reporta y sale de la 
aplicación.
// Reemplazar [nombre].glade por el nombre de tu archivo [*.glade]. //
if( ! gtk_builder_add_from_file( builder, presentacion.glade, error ) )
{
g_warning( %s, error-message );
g_free( error );
return( 1 );
}

// Obtiene el puntero principal de la UI //
window = GTK_WIDGET( gtk_builder_get_object( builder, window1 ) );
 
// Conectar señales de GTKBuilder //
gtk_builder_connect_signals( builder, NULL );

  // Cierra el Builder, ya no se necesita //
g_object_unref( G_OBJECT( builder ) );

 
// Mostrar la ventana. Las otras ventanas las muestra GTKBuilder //
gtk_widget_show( window );

/* Recibir teclas en modo sin buferes (es decir, sin esperar a que se
 * pulse ENTER) */
cbreak ();
tecla = getch ();

if( tecla == 10)
{
gtk_widget_destroy( window );
}

/* Finalizar ncurses. Esto es necesario para volver al modo estandar de
 * la terminal */
endwin ();

// Arranca el principal //
gtk_main();

return( 0 );

}

  ___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

New rule

[Richard Hughes]

How about, if you plan to break API, it's mandatory to write entries
in the migration guide. Heck, even a quick email to the mailing list
explaining how to convert code might be nice.

I'm getting really tired from people changing big parts of the API a
few days before release, and then release teams expecting developers
to produce tarballs that actually work. gtk-2.91.1 is broken for
GtkComboBoxText, and gtk git master is broken for any GtkApplication
using application. libnotify just changed API in a major way, which
means we can't even use old tarballs until everything settles down.
devhelp won't compile, so we can't even use the viewer application.

Could somebody please port all my projects. I've got better things to
do than re-port all my stuff without a migration document. Again.

Richard
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: New rule

[Tristan Van Berkom]

On Thu, 2010-10-21 at 17:33 +0100, Richard Hughes wrote:
 How about, if you plan to break API, it's mandatory to write entries
 in the migration guide. Heck, even a quick email to the mailing list
 explaining how to convert code might be nice.
 
 I'm getting really tired from people changing big parts of the API a
 few days before release, and then release teams expecting developers
 to produce tarballs that actually work. gtk-2.91.1 is broken for
 GtkComboBoxText, and gtk git master is broken for any GtkApplication
 using application. libnotify just changed API in a major way, which
 means we can't even use old tarballs until everything settles down.
 devhelp won't compile, so we can't even use the viewer application.
 
 Could somebody please port all my projects. I've got better things to
 do than re-port all my stuff without a migration document. Again.

Initial thoughts, I suppose it's good to have a head start on 
catching up to GTK+ 3.0 by porting early, however the cost of
that is dealing with api shifts (all in all I think we should
appreciate the effort but in no way require this of anyone,
trying to catch up to GTK+ means you are helping us test new
api paths; that's great).

However I expect a general latency of around 3 or 4 months
after GTK+ 3.0 is actually released for very active projects to 
catch up and port.

If anyone expects to release GNOME 3.0 apps with GTK+ 3.0 release
all at the same time, I have to say that's a bit far fetched.

We should instead recommend that people port their applications
to GTK+ 3.0 *once we have an API*; after 3.0 is released.

Cheers,
 -Tristan

 
 Richard
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-devel-list


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: New rule

[Bastien Nocera]

On Fri, 2010-10-22 at 01:48 +0900, Tristan Van Berkom wrote:
 On Thu, 2010-10-21 at 17:33 +0100, Richard Hughes wrote:
  How about, if you plan to break API, it's mandatory to write entries
  in the migration guide. Heck, even a quick email to the mailing list
  explaining how to convert code might be nice.
  
  I'm getting really tired from people changing big parts of the API a
  few days before release, and then release teams expecting developers
  to produce tarballs that actually work. gtk-2.91.1 is broken for
  GtkComboBoxText, and gtk git master is broken for any GtkApplication
  using application. libnotify just changed API in a major way, which
  means we can't even use old tarballs until everything settles down.
  devhelp won't compile, so we can't even use the viewer application.
  
  Could somebody please port all my projects. I've got better things to
  do than re-port all my stuff without a migration document. Again.
 
 Initial thoughts, I suppose it's good to have a head start on 
 catching up to GTK+ 3.0 by porting early, however the cost of
 that is dealing with api shifts (all in all I think we should
 appreciate the effort but in no way require this of anyone,
 trying to catch up to GTK+ means you are helping us test new
 api paths; that's great).
 
 However I expect a general latency of around 3 or 4 months
 after GTK+ 3.0 is actually released for very active projects to 
 catch up and port.
 
 If anyone expects to release GNOME 3.0 apps with GTK+ 3.0 release
 all at the same time, I have to say that's a bit far fetched.
 
 We should instead recommend that people port their applications
 to GTK+ 3.0 *once we have an API*; after 3.0 is released.

Except that we're talking about applications that are in the core
desktop (gnome-bluetooth, gnome-power-manager, gnome-color-manager,
gnome-packagekit, gnome-control-center), or in the default applications
(totem in my case, which also got bitten by the sizing changes, and that
I have no idea how to fix [1]).

Porting after GTK+ 3.0 is released would set us back a number of months.

And it doesn't fix our problems of applications being unportable to the
current GTK+ 3.x branch either.

[1]: Thanks for the very helpful RTFM I got from the hackfest, if I
could build devhelp, I surely would read those.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: New rule

[Bastien Nocera]

On Fri, 2010-10-22 at 02:26 +0900, Tristan Van Berkom wrote:
 
  And it doesn't fix our problems of applications being unportable to
 the
  current GTK+ 3.x branch either.
 
 If apps are actually not portable at all to the new api, that's
 definitely a problem we should address before actually releasing a 
 new stable api.
 
 The api is a work in progress, the porting guide is also a work in
 progress. I see little sense in wasting peoples efforts in rewriting
 porting guide sections for any micro-point release based on an api
 that may be subject to change before a stable release. 

And we know about those API problems because we tried to port the
applications.

If we didn't, we'd have been stuck with broken API when GTK+ 3.x was
released.

Helping port the core modules should be part of the deal when changing,
or committing new APIs.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: New rule

[Matthew Barnes]

On Fri, 2010-10-22 at 01:48 +0900, Tristan Van Berkom wrote:
 If anyone expects to release GNOME 3.0 apps with GTK+ 3.0 release
 all at the same time, I have to say that's a bit far fetched.
 
 We should instead recommend that people port their applications
 to GTK+ 3.0 *once we have an API*; after 3.0 is released.

+1

This is why Evolution's GTK+ requirement remains at 2.22 with an option
to -try- to build against gtk+-3.0.  And I plan to keep it that way
until GTK+ 3.0 is released.

Evolution is a BIG app and we simply can't keep up with this madness.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Doubts about GPeriodic

[Owen Taylor]

On Thu, 2010-10-21 at 08:17 -0400, Havoc Pennington wrote:
 Hi,
 
 On Thu, Oct 21, 2010 at 5:46 AM, Ryan Lortie de...@desrt.ca wrote:
 
  What about non-input events, though?  Like, if some download is
  happening and packets are coming in and causing dispatches from the
  mainloop that we do not have control over.
 
 I brought this up a bit in the earlier thread.
 
 My takeaway is that for I/O type stuff you usually want what we ended
 up with at litl, which is to limit it to some length of time per
 frame. Unfortunately GMainLoop has no native way to do that. I
 described our solution a bit in the old paint clock thread.

 There's a danger both of some random download starving animation and
 of your download spinner starving the download.

I think to start off we have to realize that a GTK+ application is
significantly different from a compositor like Mutter or the litl shell
in a number of ways:

* GTK+ is quite efficient when just a small amount of stuff is
  changing. Even if the entire toplevel takes a long time to paint,
  a cheesy animation somewhere in the frame isn't going to cause
  all the time to be spent painting.

* GTK+ is not going to be using a blocking glSwapBuffers(); GTK+ will
  be timing frames either based on a straight-up timer, or by getting
  frame-complete signals back from the compositor.

* It's not the compositor - if painting blocks, it's not the end
  of the world.

Once we move beyond that, then I'm skeptical about lumping everything
that's not events/animation/relayout/repaint into the same bucket.
Everything else includes a number of different things:

* UI updates being done in response to asynchronous IO finishing

  In this case, I think usually you just want to do the updates
  immediately; for most UI updates the real expense is the relayout/
  repaint, so there's no advantage to trickling them in... if you
  get such a bunch of updates that you block for a couple hundred
  ms, then you just accept a small stutter.

  If that might be a couple of seconds, then I think it's up to
  the app author to figure out how to fix the situation - if updates
  can be batched and batching reduces the work that needs to be done,
  then an easy to use before relayout API is handy.

* Computations being done in idle chunks because threads are evil.

  If the computations don't affect the GUI, then in my mind they
  should just happen in whatever time isn't needed to draw whatever
  is going on. We have no way of knowing whether whatever is going
  on is a spinner or is a video playing.

  In other words, progress displays need to be self-limiting to eat
  only a small amount of CPU. After all, it's pretty bad if my
  computation is going on at *half*-speed because of the progress
  spinner!

* Servicing incoming IPC calls

  Assuming incoming calls queue up, I think it's fine to just handle
  them at higher priority than the repaint.

  The pathological case here is that Totem is playing a movie which
  is maxing out the frame rate, and somebody in another process does
  sync calls:

   for (movie in allMovies)
  movie.length = totemProxy.getPlayingTime(movie.id);

  And Totem handles one call, then paints a frame, then handles another
  call and the whole thing takes forever. This is clearly bad, but I
  don't think the solution is for totem to reserve 5ms for ever 
  frame of every movie just because someone might start using the
  D-Bus API it exports. Solutions here are general solutions:

   - Don't put service API's in the GUI thread of GUI applications
   - Use async calls - if the above was done by making a bunch of
 async calls in parallel, it would be completed in one frame.

* Expensive GUI work done incrementally (adding thousands of items
  to a GtkTreeView, say) Threads not useful because GTK+ isn't
  thread-safe.

  This one is slightly harder because each update can actually trigger
  a relayout/repaint, which might be expensive. So if this is being
  done at idle priority, you may be in the situation of do one chunk,
  which takes 0.1ms, repaint for 20ms, do another chunk, and so forth.

  This is the case where something like your proposal of reserving
  time per frame starts making sense to me. But rather than just doing
  a blanket reservation of 5ms per frame, it seems better to actually
  let the master clock know what's going on. To have an API where you
  add a function and the master clock balances calling it with relayout.
 
  That a) avoids wasting time waiting for nothing to happen
  b) allows better handling of the case where the relayout takes 100ms
  not 20ms so you don't work for 5ms, relayout for 100ms, repeat.

- Owen


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: New rule

[Owen Taylor]

On Fri, 2010-10-22 at 02:26 +0900, Tristan Van Berkom wrote:
  Except that we're talking about applications that are in the core
  desktop (gnome-bluetooth, gnome-power-manager, gnome-color-manager,
  gnome-packagekit, gnome-control-center), or in the default applications
  (totem in my case, which also got bitten by the sizing changes, and that
  I have no idea how to fix [1]).
 
 And having core desktop modules depend on an API that's still unfinished
 and still unstable is a good idea... because ?

There's three things going on here:

 * As Bastien said, having the core of the GNOME desktop ported to 
   GTK+ 3 is incredibly useful validation of the new APIs.

 * If GNOME 3 is going to ship against GTK+ 3, it has to be ported now.
   We can't wait until 3.0 is out in December or January and then
   start porting.

 * The decision to base GNOME 3 on GTK+ 3 was made when it still looked
   like GTK+ 3 was going to be ABI and minor API changes release.

   The fact that major API changes are being made now isn't necessarily
   a bad thing ... I was never too happy with the idea of a GTK+ that
   just broke ABI for no good reason. 

   *But* it's unexpected, it doesn't really fit in with the planned
   release schedule, and causes problems for trying to actually
   work on the user parts of GNOME 3.

I think there's definitely a need for the people working on GTK+ 3 to be
respectful of GNOME 3, to make sure that making GTK+ 3 better doesn't
make GNOME 3 worse. That doesn't mean not making API changes, but it
does mean:

 - Making sure there is information out about how to fix applications
   that need to be fixed. If updating the porting guide is too hard
   to do immediately, or you are changing something that was never
   in GTK+ 2, then send mail to desktop-devel-list describing the
   change and what it takes to deal with it.

 - Considering how your changes fit in with the release schedule. If
   GNOME 2.91 is going out on Monday, don't land a breaking ABI on
   Friday.

 - If your change is going to cause major breakage, figuring out
   in advance what's going to break and work with maintainers to make
   sure that there are fixes ready to go in immediately.

(And, yes, people have often been doing these things.)

In order for GNOME 3 to ship on time, to be a good release, it needs to
build every day. And that's going to require coordination between GTK+
and GNOME.

- Owen


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Doubts about GPeriodic

[Havoc Pennington]

Hi,

I guess a frame-complete signal (or timer) acts like the 5ms to create
a window for other event sources to run? So painting should not starve
other stuff, the mainloop could dispatch other stuff while the frame
is being completed. Given a gap waiting for frame-completed you don't
need a hardcoded 5ms (makes sense to me).

Re: frame-complete, it of course assumes working drivers... If you
don't have the async frame completed signal you may be back to the 5ms
thing, no? I guess with direct rendering you are just hosed in that
case... with indirect you can use XCB to avoid blocking and then just
dispatch for 5ms, which is what we do, but with direct rendering you
might just have to block. Unless you're using fglrx which vsyncs but
does not block to do so (at least with indirect, not totally sure on
direct). Sigh. The driver workarounds rapidly proliferate. Maybe
clutter team already debugged them all and the workarounds are in
COGL. :-P
I guess COGL or whatever could in theory just send frame-completed
after a fixed 5ms as a workaround on platforms that need it. There's
also ARM and whatever platforms with no X to consider.

Re: priorities, I would think once the frame-complete comes back (or
5ms expires, absent frame-complete) it's appropriate to drop
everything else (unless it's explicitly asked to be super high
priority) and paint. paint includes processing entire event queue
and relayout, so that should have the UI sufficiently updated.

You were talking about handling incoming IPC at higher priority than
repaint... it sort of depends on what the IPC is about. For example,
we have some that is UI-related, similar to events, and other that is
basically IO. If you have a flood of IO coming in (say downloading a
big file) then I don't think it's acceptable to wait for that queue to
drain before painting - it could be minutes, not seconds. If you think
about something like the dbus main loop source, the dbus library
doesn't know what the heck is going to be coming in, and you can't
tune the main loop source depending on what kind of message it is.

Anything with a queue doesn't really have a bounded time within which
its GSource won't be ready anymore. Threads only help if you can
squish the queue in the thread... otherwise the unboundedness ends up
in the main thread anyway. For example if you're reading a file, then
if you can parse it and convert it to a small object in the thread,
there's no potential paint starvation problem, but if you need to feed
the whole unbounded dataset over into a TextView/TreeView, then there
is (as you mention).

I feel like most stuff should be below paint priority, not above, and
then each frame should have a window (either while waiting for
frame-completed or fixed time like 5ms or whatever) in which things
below paint priority are going to run. That way things more or less
can't break, as long as each individual dispatch() is reasonably
fast/bounded.

If most stuff is below paint priority (in order to ensure we keep up
the frame rate), that could be implemented either by making most stuff
an idle, or by making paint priority above default.

Most stuff should be an idle is weird to me - seems to make default
priority kind of meaningless and render g_*_add() etc. APIs useless.
Why not make paint priority greater than the default priority, and so
most things should be default, and idle is reserved for things that
it's acceptable to starve?

Conceptually, events+paint _should_ be highest priority - without
those we are hiccuping and breaking interactivity - the only thing is,
they can't run continuously, each frame needs a slice of doing other
stuff and that could be a fixed interval, or given decent drivers,
the time during which the GPU is chewing on the frame / waiting on
vsync.

Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Doubts about GPeriodic

[David Zeuthen]

Hi,

On Thu, Oct 21, 2010 at 4:25 PM, Havoc Pennington h...@pobox.com wrote:
 If you think
 about something like the dbus main loop source, the dbus library
 doesn't know what the heck is going to be coming in, and you can't
 tune the main loop source depending on what kind of message it is.

Note that with GDBus the resulting GDBusMessage is actually being
built in a separate (and private) thread - so in practice there is
zero overhead in the GUI thread - in particular it doesn't depend on
what kind of message it is or how big the message is. The same is true
for most of libgio's file and networking primitives (e.g.
g_file_load_contents_async() will cause work to happen in a worker
thread etc.).

David
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Doubts about GPeriodic

[Havoc Pennington]

Hi,

On Thu, Oct 21, 2010 at 5:47 PM, David Zeuthen zeut...@gmail.com wrote:
 Note that with GDBus the resulting GDBusMessage is actually being
 built in a separate (and private) thread - so in practice there is
 zero overhead in the GUI thread - in particular it doesn't depend on
 what kind of message it is or how big the message is. The same is true
 for most of libgio's file and networking primitives (e.g.
 g_file_load_contents_async() will cause work to happen in a worker
 thread etc.).

I don't think this matters as long as there's effectively a queue in
the main thread (i.e. each message or IO chunk has a handler in the
main thread).

If you dispatch once per dbus message from an X-priority main loop
source, then lower-than-X-priority handlers will not run until there
are no dbus messages available. So if you are getting flooded with
messages, for example if a stream of data is being dbus-transmitted,
you would need to chew through that whole stream - _or_ it would have
to just happen that on one iteration of the main loop the message
processing had caught up with the message sending and the queue was
empty. Moreover that iteration would have to happen to have no other
X-priority sources ready. In that case a lower-than-X-priority
dispatch could occur. As the number of X-priority sources goes up
(think big complex app with plugins) the odds of getting no X-priority
sources on a given iteration would presumably drop.

As long as the main loop is seeing a stream of items with no
guaranteed pauses in the stream, in theory that main loop source runs
unbounded. (yes, in practice it usually doesn't run unbounded, but I
bet trying to hold 60fps will make the in-practice glitches more
visible)

Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: New rule

[Xan Lopez]

On Fri, Oct 22, 2010 at 1:44 AM, Bastien Nocera had...@hadess.net wrote:
 On Thu, 2010-10-21 at 17:33 +0100, Richard Hughes wrote:
 How about, if you plan to break API, it's mandatory to write entries
 in the migration guide. Heck, even a quick email to the mailing list
 explaining how to convert code might be nice.

 I'm getting really tired from people changing big parts of the API a
 few days before release, and then release teams expecting developers
 to produce tarballs that actually work. gtk-2.91.1 is broken for
 GtkComboBoxText, and gtk git master is broken for any GtkApplication
 using application. libnotify just changed API in a major way, which
 means we can't even use old tarballs until everything settles down.
 devhelp won't compile, so we can't even use the viewer application.

 devhelp won't compile because WebKitGTK wasn't ported.


We released 1.3.5 a few days ago for 2.91.1, and things seems to work
fine with GTK+ master? What are we missing?

Xan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: New rule

[Matthias Clasen]

On Thu, Oct 21, 2010 at 8:54 PM, Owen Taylor

  - Making sure there is information out about how to fix applications
   that need to be fixed. If updating the porting guide is too hard
   to do immediately, or you are changing something that was never
   in GTK+ 2, then send mail to desktop-devel-list describing the
   change and what it takes to deal with it.

  - Considering how your changes fit in with the release schedule. If
   GNOME 2.91 is going out on Monday, don't land a breaking ABI on
   Friday.

  - If your change is going to cause major breakage, figuring out
   in advance what's going to break and work with maintainers to make
   sure that there are fixes ready to go in immediately.

 (And, yes, people have often been doing these things.)


Here is what I have done:

1. Introduce new GtkComboBoxText api in 2.91.1

2. Backport new GtkComboBoxText api in 2.23.0

3. Deprecate GtkComboBoxEntry and combo box text convenience api in
both 2.23.0 and 2.91.1

4. Write patches to port some 30 modules to the new apis and file them
all in bugzilla

5. Remove the deprecated api in git master


Now, this was certainly done very quickly, and not widely announced.
But I don't accept the notion that I haven't tried hard to avoid a)
breaking 2.91.1 with this change and b) make it as easy as possible
for people to keep things working after 2.91.1.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list