from:"Jasper St. Pierre"

Would it be possible for me to fund / help maintain official GNOME
Win32 bundles and an SDK? I'd love to improve Windows support of GTK+,
but I'm never sure where the status is. Last time I tried jhbuild it
failed on something early on -- I believe fontconfig, so that was a
bummer.

On Thu, Jun 11, 2015 at 9:15 AM, Emmanuele Bassi eba...@gmail.com wrote:
 Hi;

 On 11 June 2015 at 13:44, anatoly techtonik techto...@gmail.com wrote:
 On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi eba...@gmail.com wrote:

 The current stance of everyone involved in the Windows backend for
 GLib and GTK+ is to stop advertising binary builds for Windows — as we
 don't do that for any other platform, and nobody sticks around long
 enough to keep doing that or to set up a continuous integration build
 for GTK.

 Stop advertising == stop supporting?

 If I wanted to say stop supporting, I would have said that. Not that
 we *ever* supported binary builds, on any platform. If you want
 commercial support, you should contract somebody.

 Currently, we advertise ad hoc Windows builds on gtk.org; those are
 out of date, and lack many of the bug fixes that went into GTK. This
 situation is confusing for application developers, and makes the
 project look bad. It also reflect badly on the great work that
 developers have been doing in order to make GTK work well on Windows.

 On top of that, we don't offer binary builds for any other platform,
 and instead rely on distributors — like Homebrew on Mac; the *BSD
 ports; or the various Linux distributions — to provide binary builds
 for them. Windows is an anomaly, mostly because there weren't
 good/usable software distributions in the past. This has now changed,
 and it's a good thing to ensure that developers on Windows get
 reliable, up to date software.

 Developers using the G* core platform libraries on Windows are
 strongly encouraged to use the MSYS2 distribution:

   https://msys2.github.io/

 Like Git? Ship 200Mb of additional value on top? Just for comparison
 Mercurial installation is 37Mb compared with 267Mb of Git. And that for
 every GTK application?

 MSYS2 is for developers, not for end users.

 You're supposed to set up the development enviroment on *your*
 development machine(s); once you have built your application, you can
 take your binary artefacts, including the DLLs you depend on, put them
 into an installer, and let your users download the installer — which
 is exactly what you should have done in the past, even with pre-built
 DLLs. The intended change is for application developers to get
 pre-built, up to date binaries using MSYS2, instead of downloading zip
 files from gtk.org that we cannot reliably keep up to date.

 Telling your users to download your application; download DLLs from
 gtk.org; shove them into some directory; and, finally, hope for the
 best, was never a good software distribution mechanism.

 This will provide you with pre-built packages that are known to work
 and maintained. It also allows you to build your own packages on top
 of it, and create an installer from the result.

 Can GTK be cross-compiled for Windows?

 Yes, it can, and it routinely is.

 What the GTK team would love, on the other hand, is somebody putting
 the effort in setting up and maintaining a continuous integration
 service — similar to https://build.gnome.org — for Windows builds.
 This way we would be able to catch build regressions after every
 commit, without relying on the application developers to file bugs.

 http://www.appveyor.com/ if using closed source service is okay.

 No, it's really not — especially if it has to run on the gnome.org
 infrastructure.

 Ciao,
  Emmanuele.

 --
 https://www.bassi.io
 [@] ebassi [@gmail.com]
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list



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

Re: Outdated win32 bundle

Would it be possible for me to fund / help maintain official GNOME
Win32 bundles and an SDK? I'd love to improve Windows support of GTK+,
but I'm never sure where the status is. Last time I tried jhbuild it
failed on something early on -- I believe fontconfig, so that was a
bummer.

On Thu, Jun 11, 2015 at 9:15 AM, Emmanuele Bassi eba...@gmail.com wrote:
 Hi;

 On 11 June 2015 at 13:44, anatoly techtonik techto...@gmail.com wrote:
 On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi eba...@gmail.com wrote:

 The current stance of everyone involved in the Windows backend for
 GLib and GTK+ is to stop advertising binary builds for Windows — as we
 don't do that for any other platform, and nobody sticks around long
 enough to keep doing that or to set up a continuous integration build
 for GTK.

 Stop advertising == stop supporting?

 If I wanted to say stop supporting, I would have said that. Not that
 we *ever* supported binary builds, on any platform. If you want
 commercial support, you should contract somebody.

 Currently, we advertise ad hoc Windows builds on gtk.org; those are
 out of date, and lack many of the bug fixes that went into GTK. This
 situation is confusing for application developers, and makes the
 project look bad. It also reflect badly on the great work that
 developers have been doing in order to make GTK work well on Windows.

 On top of that, we don't offer binary builds for any other platform,
 and instead rely on distributors — like Homebrew on Mac; the *BSD
 ports; or the various Linux distributions — to provide binary builds
 for them. Windows is an anomaly, mostly because there weren't
 good/usable software distributions in the past. This has now changed,
 and it's a good thing to ensure that developers on Windows get
 reliable, up to date software.

 Developers using the G* core platform libraries on Windows are
 strongly encouraged to use the MSYS2 distribution:

   https://msys2.github.io/

 Like Git? Ship 200Mb of additional value on top? Just for comparison
 Mercurial installation is 37Mb compared with 267Mb of Git. And that for
 every GTK application?

 MSYS2 is for developers, not for end users.

 You're supposed to set up the development enviroment on *your*
 development machine(s); once you have built your application, you can
 take your binary artefacts, including the DLLs you depend on, put them
 into an installer, and let your users download the installer — which
 is exactly what you should have done in the past, even with pre-built
 DLLs. The intended change is for application developers to get
 pre-built, up to date binaries using MSYS2, instead of downloading zip
 files from gtk.org that we cannot reliably keep up to date.

 Telling your users to download your application; download DLLs from
 gtk.org; shove them into some directory; and, finally, hope for the
 best, was never a good software distribution mechanism.

 This will provide you with pre-built packages that are known to work
 and maintained. It also allows you to build your own packages on top
 of it, and create an installer from the result.

 Can GTK be cross-compiled for Windows?

 Yes, it can, and it routinely is.

 What the GTK team would love, on the other hand, is somebody putting
 the effort in setting up and maintaining a continuous integration
 service — similar to https://build.gnome.org — for Windows builds.
 This way we would be able to catch build regressions after every
 commit, without relying on the application developers to file bugs.

 http://www.appveyor.com/ if using closed source service is okay.

 No, it's really not — especially if it has to run on the gnome.org
 infrastructure.

 Ciao,
  Emmanuele.

 --
 https://www.bassi.io
 [@] ebassi [@gmail.com]
 ___
 gtk-devel-list mailing list
 gtk-devel-l...@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list



-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Outdated win32 bundle

I can take a look at the gobject-introspection work. Bugzilla links?

On Thu, Jun 11, 2015 at 10:57 AM, Ignacio Casal Quinteiro
nacho.r...@gmail.com wrote:


 On Thu, Jun 11, 2015 at 4:51 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 Would it be possible for me to fund / help maintain official GNOME
 Win32 bundles and an SDK? I'd love to improve Windows support of GTK+,
 but I'm never sure where the status is. Last time I tried jhbuild it
 failed on something early on -- I believe fontconfig, so that was a
 bummer.


 Well the current status is quite good compared with how it was a few years
 ago.
 The main problems are still:
 1. that we have lots of downstream patches still on msys2, even though I
 spent quite a lot of time pushing them upstream.
 2. building anything out of git is a nightmare, you need a tarball or
 everything gets in your way
 3. gobject-introspection could get quite a bit of love for windows. There
 are though some patches in bugzilla that are waiting some review.
 4. jhbuild would require some serious work.

 Cheers.




 On Thu, Jun 11, 2015 at 9:15 AM, Emmanuele Bassi eba...@gmail.com wrote:
  Hi;
 
  On 11 June 2015 at 13:44, anatoly techtonik techto...@gmail.com wrote:
  On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi eba...@gmail.com
  wrote:
 
  The current stance of everyone involved in the Windows backend for
  GLib and GTK+ is to stop advertising binary builds for Windows — as we
  don't do that for any other platform, and nobody sticks around long
  enough to keep doing that or to set up a continuous integration build
  for GTK.
 
  Stop advertising == stop supporting?
 
  If I wanted to say stop supporting, I would have said that. Not that
  we *ever* supported binary builds, on any platform. If you want
  commercial support, you should contract somebody.
 
  Currently, we advertise ad hoc Windows builds on gtk.org; those are
  out of date, and lack many of the bug fixes that went into GTK. This
  situation is confusing for application developers, and makes the
  project look bad. It also reflect badly on the great work that
  developers have been doing in order to make GTK work well on Windows.
 
  On top of that, we don't offer binary builds for any other platform,
  and instead rely on distributors — like Homebrew on Mac; the *BSD
  ports; or the various Linux distributions — to provide binary builds
  for them. Windows is an anomaly, mostly because there weren't
  good/usable software distributions in the past. This has now changed,
  and it's a good thing to ensure that developers on Windows get
  reliable, up to date software.
 
  Developers using the G* core platform libraries on Windows are
  strongly encouraged to use the MSYS2 distribution:
 
https://msys2.github.io/
 
  Like Git? Ship 200Mb of additional value on top? Just for comparison
  Mercurial installation is 37Mb compared with 267Mb of Git. And that for
  every GTK application?
 
  MSYS2 is for developers, not for end users.
 
  You're supposed to set up the development enviroment on *your*
  development machine(s); once you have built your application, you can
  take your binary artefacts, including the DLLs you depend on, put them
  into an installer, and let your users download the installer — which
  is exactly what you should have done in the past, even with pre-built
  DLLs. The intended change is for application developers to get
  pre-built, up to date binaries using MSYS2, instead of downloading zip
  files from gtk.org that we cannot reliably keep up to date.
 
  Telling your users to download your application; download DLLs from
  gtk.org; shove them into some directory; and, finally, hope for the
  best, was never a good software distribution mechanism.
 
  This will provide you with pre-built packages that are known to work
  and maintained. It also allows you to build your own packages on top
  of it, and create an installer from the result.
 
  Can GTK be cross-compiled for Windows?
 
  Yes, it can, and it routinely is.
 
  What the GTK team would love, on the other hand, is somebody putting
  the effort in setting up and maintaining a continuous integration
  service — similar to https://build.gnome.org — for Windows builds.
  This way we would be able to catch build regressions after every
  commit, without relying on the application developers to file bugs.
 
  http://www.appveyor.com/ if using closed source service is okay.
 
  No, it's really not — especially if it has to run on the gnome.org
  infrastructure.
 
  Ciao,
   Emmanuele.
 
  --
  https://www.bassi.io
  [@] ebassi [@gmail.com]
  ___
  gtk-devel-list mailing list
  gtk-devel-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-devel-list



 --
   Jasper
 ___
 gtk-list mailing list
 gtk-l...@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list




 --
 Ignacio Casal Quinteiro



-- 
  Jasper

Re: Outdated win32 bundle

I can take a look at the gobject-introspection work. Bugzilla links?

On Thu, Jun 11, 2015 at 10:57 AM, Ignacio Casal Quinteiro
nacho.r...@gmail.com wrote:


 On Thu, Jun 11, 2015 at 4:51 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 Would it be possible for me to fund / help maintain official GNOME
 Win32 bundles and an SDK? I'd love to improve Windows support of GTK+,
 but I'm never sure where the status is. Last time I tried jhbuild it
 failed on something early on -- I believe fontconfig, so that was a
 bummer.


 Well the current status is quite good compared with how it was a few years
 ago.
 The main problems are still:
 1. that we have lots of downstream patches still on msys2, even though I
 spent quite a lot of time pushing them upstream.
 2. building anything out of git is a nightmare, you need a tarball or
 everything gets in your way
 3. gobject-introspection could get quite a bit of love for windows. There
 are though some patches in bugzilla that are waiting some review.
 4. jhbuild would require some serious work.

 Cheers.




 On Thu, Jun 11, 2015 at 9:15 AM, Emmanuele Bassi eba...@gmail.com wrote:
  Hi;
 
  On 11 June 2015 at 13:44, anatoly techtonik techto...@gmail.com wrote:
  On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi eba...@gmail.com
  wrote:
 
  The current stance of everyone involved in the Windows backend for
  GLib and GTK+ is to stop advertising binary builds for Windows — as we
  don't do that for any other platform, and nobody sticks around long
  enough to keep doing that or to set up a continuous integration build
  for GTK.
 
  Stop advertising == stop supporting?
 
  If I wanted to say stop supporting, I would have said that. Not that
  we *ever* supported binary builds, on any platform. If you want
  commercial support, you should contract somebody.
 
  Currently, we advertise ad hoc Windows builds on gtk.org; those are
  out of date, and lack many of the bug fixes that went into GTK. This
  situation is confusing for application developers, and makes the
  project look bad. It also reflect badly on the great work that
  developers have been doing in order to make GTK work well on Windows.
 
  On top of that, we don't offer binary builds for any other platform,
  and instead rely on distributors — like Homebrew on Mac; the *BSD
  ports; or the various Linux distributions — to provide binary builds
  for them. Windows is an anomaly, mostly because there weren't
  good/usable software distributions in the past. This has now changed,
  and it's a good thing to ensure that developers on Windows get
  reliable, up to date software.
 
  Developers using the G* core platform libraries on Windows are
  strongly encouraged to use the MSYS2 distribution:
 
https://msys2.github.io/
 
  Like Git? Ship 200Mb of additional value on top? Just for comparison
  Mercurial installation is 37Mb compared with 267Mb of Git. And that for
  every GTK application?
 
  MSYS2 is for developers, not for end users.
 
  You're supposed to set up the development enviroment on *your*
  development machine(s); once you have built your application, you can
  take your binary artefacts, including the DLLs you depend on, put them
  into an installer, and let your users download the installer — which
  is exactly what you should have done in the past, even with pre-built
  DLLs. The intended change is for application developers to get
  pre-built, up to date binaries using MSYS2, instead of downloading zip
  files from gtk.org that we cannot reliably keep up to date.
 
  Telling your users to download your application; download DLLs from
  gtk.org; shove them into some directory; and, finally, hope for the
  best, was never a good software distribution mechanism.
 
  This will provide you with pre-built packages that are known to work
  and maintained. It also allows you to build your own packages on top
  of it, and create an installer from the result.
 
  Can GTK be cross-compiled for Windows?
 
  Yes, it can, and it routinely is.
 
  What the GTK team would love, on the other hand, is somebody putting
  the effort in setting up and maintaining a continuous integration
  service — similar to https://build.gnome.org — for Windows builds.
  This way we would be able to catch build regressions after every
  commit, without relying on the application developers to file bugs.
 
  http://www.appveyor.com/ if using closed source service is okay.
 
  No, it's really not — especially if it has to run on the gnome.org
  infrastructure.
 
  Ciao,
   Emmanuele.
 
  --
  https://www.bassi.io
  [@] ebassi [@gmail.com]
  ___
  gtk-devel-list mailing list
  gtk-devel-l...@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-devel-list



 --
   Jasper
 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list




 --
 Ignacio Casal Quinteiro



-- 
  Jasper

Re: In GTK, how are screen coordinates mapped to GUI objects?

2015-05-11 Thread Jasper St. Pierre

Computers are *fast*. It turns out that simply recursively walking
down all children is fast enough for most cases. It's a complicated
walk, but it's entirely doable. You can see the code for the walk
here:

https://git.gnome.org/browse/gtk+/tree/gdk/gdkwindow.c#n7247

More complex data structures, like a map of pixel to object, would
take up too much memory, or require too much effort to suitably parse.
The simple and brute force solution often works well, because you'll
never have more than 100 visible children in the worst case, and 100
is not a big enough number to optimize for.

On Mon, May 11, 2015 at 2:14 PM, George Nychis gnyc...@gmail.com wrote:
 I am trying to gain a very technical understanding of how operating systems
 and GUI systems (like GTK) scalably map coordinates on the 2d screen to
 objects.  For example, there are many applications running with graphical
 interfaces to them active on the screen, and each application interface has
 dozens (if not hundreds) of objects (buttons, scroll bars, etc.).  Some
 objects are contained within other objects.

 So, what I am trying to learn more about is how something like GTK maps a
 screen coordinate (and an action like a mouse click) to an object quickly to
 generate a callback to the appropriate application or object.  In
 particular, when there are objects within objects, how it narrows the search
 down to the smallest element that your mouse is hovering over when a click
 event fired.

 I'd love to know about what data structures and algorithms are used to
 perform this mapping between the 2D graphical space to objects.

 Thanks!
 George

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




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: In GTK, how are screen coordinates mapped to GUI objects?

2015-05-11 Thread Jasper St. Pierre

Right. If you were building a scalable UI with a flat hierarchy of
objects that do not move often (scrolling is OK, since scrolling is
just an offset across the whole set of objects), then one solution is
known as a quadtree. The idea here is that you recursively subdivide
the scene into quadrants and try to balance it such that each quadrant
has 5-10 objects. You spend a lot more time building the quadtree but
it will significantly cut down on lookup time.

On Mon, May 11, 2015 at 2:37 PM, Paul Davis p...@linuxaudiosystems.com wrote:


 On Mon, May 11, 2015 at 5:30 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 Computers are *fast*. It turns out that simply recursively walking
 down all children is fast enough for most cases. It's a complicated
 walk, but it's entirely doable. You can see the code for the walk
 here:

 https://git.gnome.org/browse/gtk+/tree/gdk/gdkwindow.c#n7247



 notice the assumption that there's no Z-axis ordering. this is important and
 simplifies the code/algorithm significantly. many modern applications occupy
 what we might call 2-1/2D, where the 3rd dimension doesn't represent real
 space, but the stacking of items does have some semantic significance.

 the tree walking algorithm also causes issues with any situations (which
 admittedly are rare) where objects are highly non-rectangular.



 More complex data structures, like a map of pixel to object, would
 take up too much memory, or require too much effort to suitably parse.
 The simple and brute force solution often works well, because you'll
 never have more than 100 visible children in the worst case, and 100
 is not a big enough number to optimize for.


 this number isn't realistic in the more general case where the things on
 the screen are less heavy-weight than widgets. So certainly it works OK for
 the GDK/GTK case, but in terms of a general mapping, optimizations do and
 can matter. A typical somewhat complex session in Ardour that involves MIDI
 and audio data might have in excess of 2k objects on the screen, and in
 extreme cases, a factor of ten larger.

 unfortunately, the map of pixel to object is also too expensive in that
 case. we don't have the right answer (yet), so we too walk the tree, but we
 have to take layering (z-axis) into account. it easy to see this slow down
 certain aspects of GUI performance.






-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Repost question from 2013. I have same problem.

2015-05-08 Thread Jasper St. Pierre

There's a few bugs here. First, you forgot to unref the builder, which
keeps a reference to all its objects. Second, windows must be destroyed
with gtk_widget_destroy to ensure they are properly cleaned up. Windows, as
toplevel widgets, need to interact with the windowing system at any time,
even if you unreffed them.
On May 8, 2015 2:25 AM, Konstantin P. ria.freelan...@gmail.com wrote:

 The following code spawns a window --

 if (connect_build_object != NULL) {
 g_object_unref (G_OBJECT ( connect_build_object ));
 object = NULL;
 }
 connect_build_object = gtk_builder_new();

 gtk_builder_add_from_resource ( connect_build_object, 
 /erg/app/ui/main_window.ui,
 NULL );

 gtk_builder_connect_signals ( connect_build_object, NULL );

 connect_window = GTK_WIDGET ( gtk_builder_get_object ( connect_build_object,
 connec ) );

 gtk_widget_show ( connect_window );

 Where connect_build_object is a global variable.


 Before spawning, it's checked if connect_build_object is initilized, if that's
 the case, its destroyed by g_object_unref.

 Closing the window calls the default handler.

 Problem: Each time I open and close a window, memory usage increases.
 And it does not decreases after builder unref.
  Why it is increases, and how I can avoid this?


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


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

Re: How to get Colors?

2015-05-04 Thread Jasper St. Pierre

There are lots of widgets which don't (yet) respect all CSS
properties. That's because when you try, you break themes which do
something like: * { background: gray; }, and some widgets weren't
expecting to get a gray background.

We're trying to make more widgets respect CSS, but it's a careful
balancing act to play.

On Mon, May 4, 2015 at 2:05 PM, salsaman salsa...@gmail.com wrote:
 a) CSS styling is broken in gtk. I have tried to use it set various widgets
 and a lot of the time it fails.

 b) The only functions which work semi-consistently in gtk+ 3.0 are:
 gtk_widget_override_color() and gtk_widget_override_background_color()

 c) The above functions work for most widgets, except for a few cases like
 the background for labels in spinbuttons and the background colour for tabs
 in gtk notebook widgets. There is apparently no way to set these. You can
 try via the above functions or by CSS but the colour cannot be changed
 within an application.

 Regards,
 Salsaman



 http://lives.sourceforge.net
 https://www.openhub.net/accounts/salsaman



 On Mon, May 4, 2015 at 10:01 AM, The Devils Jester
 thedevilsjes...@gmail.com wrote:

 That may be an elegant solution to drawing using theme parts, but thats
 not the question.  That is not an elegant solution for getting solid colors
 that are similar to the overall theme, but not using gradients or textures.
 The deprecated function gives me a useful, expected value, what ever it does
 to give a reasonable approximation has worked great for years, where as the
 other function gives me black for all background colors, all the time, on
 almost every widget. (Some give white).

 On May 4, 2015 7:49 AM, Emmanuele Bassi eba...@gmail.com wrote:

 Hi;

 On 4 May 2015 at 13:38, The Devils Jester thedevilsjes...@gmail.com
 wrote:
  I am aware of the dynamics of GTK

 If you say this, followed by:

  In the same vein, of colors, can someone explain what I am doing wrong
  when:
  gtk_style_context_get_background_color(context, GTK_STATE_FLAG_NORMAL,
  bg_n); gives me nothing but black for the same widget that
  gtk_widget_get_style gives me the (expected) rgb (214,214,214) ?

 Then it means you're not really aware of the dynamics of GTK.

 The gtk_widget_get_style() function is a deprecated API that we had to
 leave in there because the CSS style machinery wasn't finished by the
 time we released 3.0, and because applications would have needed much
 more porting from 2.x to 3.0 if we downright eliminated that function.
 It was not optimal, but the other option would have been to delay GTK
 3.0 by another 6 to 12 months, and that would have had a cascade of
 effects on the rest of the ecosystem based on GTK+. Historical reasons
 aside, this means that gtk_widget_get_style() returns a best effort
 value which may or may not make sense.

 For instance, if you ask gtk_widget_get_style() the for the background
 color of a widget using a with a background image in CSS, what color
 should you get? What happens if the widget is using a gradient? Right
 now, it's completely undefined. That is why you don't query a style
 context for a background color: you just ask the style context to draw
 a background, according to the state in which the style context is.

  but the need to render custom widgets to
  use a similar color palette to the current theme is a real one that
  does not
  seem to have an elegant solution.

 The elegant solution is to use the gtk_render_* family of functions.

 Ciao,
  Emmanuele.

 --
 https://www.bassi.io
 [@] ebassi [@gmail.com]


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



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




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GDK_KP_Decimal (on Windows)

2015-04-29 Thread Jasper St. Pierre

It was likely left out by accident, and nobody so far hit this code
path yet. Thanks for finding it! It looks super easy to fix.

On Wed, Apr 29, 2015 at 8:01 AM, John Emmas john...@tiscali.co.uk wrote:
 On 29/04/2015 08:54, John Emmas wrote:


 The Windows version looks slightly different:-

 case VK_ADD:
   *ksymp = GDK_KP_Add; break;
 case VK_SEPARATOR:
   *ksymp = GDK_KP_Separator; break;
 case VK_SUBTRACT:
   *ksymp = GDK_KP_Subtract; break;

 // some others

 However, the list for Windows doesn't seem to include 'GDK_KP_Decimal'.
 Might this explain why the decimal point key is getting ignored on Windows?


 Just for the hell of it I decided to add an entry for GDK_KP_Decimal - and
 sure enough, it seems to have fixed the problem.  Does anyone know of a
 valid reason why that one got left out for the Windows list?  Thanks.


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



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

Re: dependency graph

2015-04-06 Thread Jasper St. Pierre

The one in here, perhaps?

https://github.com/hexchat/gtk-win32/blob/master/README.md

On Mon, Apr 6, 2015 at 10:55 AM, Paul Davis p...@linuxaudiosystems.com wrote:
 sometime in the last few months, somebody posted a link to (or the actual
 image of) a really really nice diagram laying out the dependencies in the
 GTK stack. i am having a hard time finding it. does anyone have any
 pointers? it was nicely organized by functionality etc.

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




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

Re: I'm done with O_CLOEXEC

2015-03-28 Thread Jasper St. Pierre

Thanks. I have refactored this code to use GSubprocess:

https://git.gnome.org/browse/mutter/commit/?id=d4e8d97e58f9c931a14ea9b6484890d7a66e65e7

Not overly happy with the hardcoded fd assignments, but it's not the
end of the world.

On Fri, Mar 20, 2015 at 10:28 PM, Ryan Lortie de...@desrt.ca wrote:
 hi,

 On Sat, Mar 21, 2015, at 01:19, Jasper St. Pierre wrote:
 Right now, we use raw fork/exec in mutter where we need to do some tricky
 management and explicitly leak an FD into the correct place [0]. Does
 this
 mean that from now on, glib might leak an FD and we need to be prepared
 to
 handle that? Refactoring the code to use a child setup func and using
 g_spawn isn't quite really what I want to do (can I even leak an FD made
 with socketpair through in that case?), but I want to be aware of what
 might break in the future, and whose bug it should be.

 I recommend using GSubprocess.

 g_subprocess_launcher_take_fd() lets you give an fd (along with a
 target_fd number).  This fd will appear in the newly-spawned process as
 the target number you gave.  This is what I mean by code that spawns
 processes having explicit control over what they do.

 For example:

   int sv[2];

   socketpair (..., sv);
   g_subprocess_launcher_take_fd (launcher, sv[1], 3);
   g_subprocess_launcher_spawn (launcher, NULL, /usr/bin/whatever);

 will put the sv[1] end of the socket pair into the launched process as
 fd 3.

 I know it's difficult to set a policy about this, but is there anything I
 can do to prevent too much damage in the future? If I file a patch
 against
 glib for where it might not set CLOEXEC with an easy flag the syscall,
 will
 you accept it, or are you going to reject it to stop me from relying on
 CLOEXEC?

 I'm not sure.  It probably depends on the outcome of this thread.  I'm
 leaning towards we won't do it if it complicates the code.

 Cheers



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

Re: GTK+, WM, desktops and CSD

2015-03-23 Thread Jasper St. Pierre

On Mon, Mar 23, 2015 at 2:25 PM, Pavel Machek pa...@ucw.cz wrote:

 Hi!

  I am not one of them, but there are a lot of people (including KDE
  devs apparently) concerned about CSD because it means different
  decorations depending on the apps/toolkit = Consistency might
  suffer.

 Consistency already suffers. Chromium pulls this trick, and it means
 you can't move such web browser to other workspace, easily (as right
 click produces useless Chromium's menu, while right click on normal
 windows produces expected WM's menu, including move to another
 desktop).

  I think it's very little change in GTK+ as it's already able to do
  both SSD and CSD (currently, decision to use CSD or SSD being made at
  run time based on the availability of a compositor).

 If you are modifying protocol between WM and application, would it be
 possible to arrange right click on title event to windowmanager, so
 that it can display its full menu?


This request already exists.

http://cgit.freedesktop.org/wayland/weston/tree/protocol/xdg-shell.xml#n187


 Thanks,
 Pavel

 --
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures)
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list




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

Re: I'm done with O_CLOEXEC

2015-03-20 Thread Jasper St. Pierre

Sorry, I'm not overly familiar with this sort of stuff.

Right now, we use raw fork/exec in mutter where we need to do some tricky
management and explicitly leak an FD into the correct place [0]. Does this
mean that from now on, glib might leak an FD and we need to be prepared to
handle that? Refactoring the code to use a child setup func and using
g_spawn isn't quite really what I want to do (can I even leak an FD made
with socketpair through in that case?), but I want to be aware of what
might break in the future, and whose bug it should be.

I know it's difficult to set a policy about this, but is there anything I
can do to prevent too much damage in the future? If I file a patch against
glib for where it might not set CLOEXEC with an easy flag the syscall, will
you accept it, or are you going to reject it to stop me from relying on
CLOEXEC?

[0]
https://git.gnome.org/browse/mutter/tree/src/wayland/meta-xwayland.c#n458

On Fri, Mar 20, 2015 at 10:10 PM, Ryan Lortie de...@desrt.ca wrote:

 On Fri, Mar 20, 2015, at 23:33, Matthias Clasen wrote:
  So,  you found that dup3 doesn't do what you want, and now you want to
  throw out the baby with the bathwater and just say I don't care
  anymore if we leak fds ?

 dup3() was a bit of a straw that broke the camel's back case.  I could
 point at the existence of g_unix_open_pipe() as a similarly ridiculous
 case, or many others.

 I'm also not impressed by the inaccurate categorisation.  I thought I
 explained fairly clearly why I believe that leaked fds will _not_ be the
 case, even without O_CLOEXEC.

 I was looking for some slightly more constructive arguments...

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




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

Re: GL and libepoxy

2015-03-06 Thread Jasper St. Pierre

Are you sure? This shouldn't be the case since

https://github.com/anholt/libepoxy/commit/e3051481cc9f5b7b36b317aff1454ee16ea9cdb9

On Fri, Mar 6, 2015 at 7:54 PM, John Ralls jra...@ceridwen.us wrote:

 It looks like we've committed to using libepoxy[1] as a shim for GL
 support. It looks quite nice, but there's a catch: In spite of the claim in
 our INSTALL that it's cross-platform, it actually depends on X11.

 I think that means that we need to have a separate GL interface
 per-backend.

 Regards,
 John Ralls

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




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

Re: GTK+, WM, desktops and CSD

2015-03-05 Thread Jasper St. Pierre

Ah, I think I see the disagreement.

We don't decide between SSD and CSD based on the presence of a compositor
and _GTK_FRAME_EXTENTS, we instead push really hard for CSD with an SSD
fallback.

It's a subtle difference, but it shows our preference: we don't want a hint
to say that the DE prefers SSD, we want a hint to say that the DE can
support/not support CSD.

If you want to help improve CSD fallbacks to behave better when we don't
have a compositor, that would be great! But ultimately, SSD does not lead
to the types of applications and the types of experiences we want to
create, so a hint asking us to prefer to use SSD that we would
realistically mostly ignore isn't particularly useful.

On Thu, Mar 5, 2015 at 12:29 PM, Olivier Fourdan four...@gmail.com wrote:

 Hi

 On 5 March 2015 at 20:09, Emmanuele Bassi eba...@gmail.com wrote:
  On 5 March 2015 at 19:17, Florian Müllner fmuell...@gnome.org wrote:
  What about apps that rely on CSD for part of their UI? Will those
 have the
  final word as well, or are they just screwed?
 
  The same as now without a compositor :)
 
  a) X11 without a compositor is a deeply uninteresting case; I'd go as
  far as saying that if you're running X11 without a compositor you're
  basically asking for a broken system

 I am not sure I am following you here, but people do run WM without a
 compositor, it is a reality.

 And GTK supports that, at least up until now, and that's fine by me.

  b) not having a compositor is not at all equivalent to changing a UI
  from a CSD to a SSD scenario. The UI *changes*, even in drastic ways
  for the user interaction. The application has to be informed about it,
  and has to be designed with those two cases in mind. It has to ship
  with two fairly different sets of UIs. It already happens for menus,
  but you'll have to convince application developers to ship those two
  UIs, maintain them, and keep them from going out of sync. Your idea
  stops at providing a patch for a hint. You're vastly underestimating
  the effort that such hint entails on the larger ecosystem.

 But it's already the case, I am not advocating to reinvent the entire
 ecosystem of UI interactions here, I am merely asking if a setting to
 help GTK decide to go CSD or SSD instead of just detecting the
 presence of the compositor alone would be interesting...

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




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

Re: GTK+, WM, desktops and CSD

2015-03-05 Thread Jasper St. Pierre

On Thu, Mar 5, 2015 at 10:37 AM, Olivier Fourdan four...@gmail.com wrote:

 +gtk-devel-list

 Argh sorry, I didn't mean to make that email private,  thought my
 mailer would copy the list as well, my bad :(

 On 5 March 2015 at 19:29, Olivier Fourdan four...@gmail.com wrote:
  Emmanuele,
 
  Let's face it, I doubt GTK+ will ever dominate the world, so the it's
  not consistent because we're not using a single toolkit is not going
  to be solved overnight. And frankly, as much as I like GTK+, I do not
  wish other toolkits to go away either, so we shall have to deal with
  heterogeneous toolkits for any foreseeable future.
 
  GTK already check for a compositor and detecting the DE to adapt is
  really not a good approach, it doesn't scale, and worse it ends up
  being really confusing (I can't remember which famous app was doing
  that, but I do remember that we ended up pretending to be gnome in the
  session just so it would work reliably...).


Hi,

GTK+ should not try to detect the DE it is running under. It should check
for the _GTK_FRAME_EXTENTS protocol in _NET_SUPPORTED on the root window.


  As I wrote, the final word would remain the to apps, just like now,
  all I'm proposing is to replace the decision made by GTK to use CSD
  based on a compositor with a hint from the DE instead, nothing more.
 
  Cheers,
  Olivier
 
 
  On 5 March 2015 at 19:18, Emmanuele Bassi eba...@gmail.com wrote:
  Hi;
 
  On 5 March 2015 at 17:51, Olivier Fourdan four...@gmail.com wrote:
 
  I am not one of them, but there are a lot of people (including KDE
  devs apparently) concerned about CSD because it means different
  decorations depending on the apps/toolkit = Consistency might suffer.
 
  I don't strictly buy the consistency argument at all.
 
  Right now, on my desktop, I have open two different browsers — Firefox
  and Chrome — that do not look like anything on my desktop. I also have
  an office suite using its own toolkit which passes a slight
  resemblance to GTK, if I squint my eyes and tilt my head a bit. If I
  were so inclined, I could be probably running some non-GTK
  applications, and those would look fairly different.
 
  There's no consistency because we're not running a platform with a
  single toolkit.
 
  If you're referring to the window controls, you can specify them even
  for GTK windows using client-side decorations; it's a setting that can
  be changed to reflect your environment — that's why both server-side
  and client-side decorated GTK windows have the same buttons.
 
  I think it's very little change in GTK+ as it's already able to do
  both SSD and CSD (currently, decision to use CSD or SSD being made at
  run time based on the availability of a compositor).
 
  That's not entirely correct. The decision to use client-side
  decorations is up to the application developers, not to the toolkit.
  An application developer may decide to support both the UIs, and opt
  for client-side decorations if they detect that the application is
  running under GNOME, but the toolkit is only tangentially involved.
  The only place where GTK decides to use an header bar or not is for
  the dialog windows it creates — file selection dialogs, print dialogs,
  color selection dialogs, etc. Those are under the control of the
  toolkit, so the toolkit can make a decision. The UI of an application,
  on the other hand, is the remit of its developer. The toolkit cannot
  really move widgets around, because it's missing context to do so. If
  I use a GtkHeaderBar with a button at the top left, and the
  environment does not support CSD properly, where should the toolkit
  put that button? Keep the header bar, but still have decorations on
  top, thus replicating things like titles?
 
  Your proposal for an hint could be simply solved with a check on
  whether the screen is composited (which is already available) and/or a
  check on the desktop environment. Sure, we can add a freedesktop.org
  spec that tells us if the application is running under GNOME, KDE,
  XFCE, or whatever. Obviously, it all breaks apart as soon as choice
  is factored in — if somebody is running under KDE with KWin without
  compositing, what would the environment be? Same with XFCE running
  with another window manager. Let's ignore that for a minute, though,
  and figure out the issues of such a hint.
 
   • How does that hint get specified? Is it an X11 property on the root
 window?
   • How does it get monitored? What happens if the user changes the
  setting at run time? Do we get a client message?
   • How are applications supposed to react when that setting is found,
  or when it changes? Do they ship with two different UIs, one for CSD
  and one for SSD?
   • What happens if the application does not have two UIs? Is the
  setting ignored, and the application stays with client-side
  decorations even if the window manager does not support the Motif WM
  hints?
 
  At the end of the day, though, if the application developer

Re: GTK+, WM, desktops and CSD

2015-03-05 Thread Jasper St. Pierre

On Thu, Mar 5, 2015 at 1:21 PM, David Nečas y...@physics.muni.cz wrote:

 On Thu, Mar 05, 2015 at 10:01:44PM +0100, Olivier Fourdan wrote:
   It's a subtle difference, but it shows our preference: we don't want a
 hint
   to say that the DE prefers SSD, we want a hint to say that the DE can
   support/not support CSD.
 
  That would work as well, why not.

 As long as I can set up my DE to pretend not to support CSD, whatever
 the actual state is.  Because this is, at the end, user's preference.


It's the application developer's decision to build the application and the
UI they want to build. GtkHeaderBar, like GtkButton or GtkMenuBar, is
simply a widget in their box of tools to construct their UI. These
applications might be free software, in which case you have the freedom to
change the code and the UI. You are still welcome to do this. GTK+ is an
application toolkit and is not in the business of constructing policy about
what the application developer can and cannot do.

If you do not like CSD, do not use applications that use CSD in their UI,
or change the application's code to stop it from using CSD.

We wouldn't accept a patch that radically changed GtkButton because it is,
at the end, user's preferenece about whether GtkButton should be allowed.
The same can be said about other UI elements that application developers
use to construct your UI.


   But ultimately, SSD does not lead to the types of applications and
   the types of experiences we want to create...

 This is sad.  Once your mission becomes creating certain types of
 experience, instead of enabling them, everything else gets destroyed,
 whether the types of experience it enables are also good or not.  And
 there does not seem anything capable of stopping the destructive mindset
 at this moment...


Honest question: What is the everything else that is being destroyed? Are
there some issues you have with our CSD implementation? I can try to help
fix them.


 Yeti




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

Re: Memory leak in gdbus-codegen generated code

2015-02-09 Thread Jasper St. Pierre

The base class is simply never cleaned up. Typical types registered with
GType are static, meaning they aren't ever cleaned up for the entire
duration of the process.

Why do you need to clean up the type?

On Mon, Feb 9, 2015 at 10:59 PM, Norman, Anders anders.nor...@barco.com
wrote:

 Well, I consider it a leak and need it cleaned up.

 In gobject.c g_object_base_class_finalize() there is a call to
 _g_signals_destroy() but I don't see exactly how this ties into the type
 system of glib.

 Anders

 -Original Message-
 From: Tristan Van Berkom [mailto:tris...@upstairslabs.com]
 Sent: 9. februar 2015 16:35
 To: Norman, Anders
 Cc: gtk-list@gnome.org
 Subject: Re: Memory leak in gdbus-codegen generated code

 On Tue, 2015-02-10 at 00:32 +0900, Tristan Van Berkom wrote:
  On Mon, 2015-02-09 at 15:05 +, Norman, Anders wrote:
  [...]
   But the application ends up leaking the signal generated in
 `dbus_foo_default_init()` which looks like this:
  
   static void
   dbus_foo_default_init (DbusFooIface *iface)
   {
 /* GObject signals for incoming D-Bus method calls: */
 /**
  * DbusFoo::handle-bar:
  * @object: A #DbusFoo.
  * @invocation: A #GDBusMethodInvocation.
  *
  * Signal emitted when a remote caller is invoking the link
 linkend=gdbus-method-com-example-foo.BarBar()/link D-Bus method.
  *
  * If a signal handler returns %TRUE, it means the signal
 handler will handle the invocation (e.g. take a reference to @invocation
 and eventually call dbus_foo_complete_bar() or e.g.
 g_dbus_method_invocation_return_error() on it) and no order signal handlers
 will run. If no signal handler handles the invocation, the
 %G_DBUS_ERROR_UNKNOWN_METHOD error is returned.
  *
  * Returns: %TRUE if the invocation was handled, %FALSE to let
 other signal handlers run.
  */
 g_signal_new (handle-bar,
   G_TYPE_FROM_INTERFACE (iface),
   G_SIGNAL_RUN_LAST,
   G_STRUCT_OFFSET (DbusFooIface, handle_bar),
   g_signal_accumulator_true_handled,
   NULL,
   g_cclosure_marshal_generic,
   G_TYPE_BOOLEAN,
   1,
   G_TYPE_DBUS_METHOD_INVOCATION);
  
   }
  
   Am I using the generated code wrong or is it a bug in
 glib/gdbus-codegen?
 
  This is not considered a leak, a signal connection leaking would be a
  leak, but a signal declaration as such, is expected to be kept with
  the statically registered GTypeInstance.

 Err, I should have just said GType, the GTypeInstance is indeed instance
 data and freed with every object, sorry for the confusion.

 Cheers,
 -Tristan


 This message is subject to the following terms and conditions: MAIL
 DISCLAIMERhttp://www.barco.com/en/maildisclaimer
 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Multithreaded application freezing

2015-02-05 Thread Jasper St. Pierre

You can still deadlock with two different processes (getting your protocol
marshalling into a state where both processes are waiting for an RPC reply
from the other), and we've seen it with DBus interfaces before.

Really, the ability to not hang relies on careful engineering and
understanding the tradeoffs of your system.

Having two socket connections to the X server isn't magical, and if one
processes hangs, then one window of your two-window application is broken.
To a typical user, that's just as good as the entire thing hanging.

And when the window that's still alive tries to make RPC to the hung
processes, well, now your entire application is toast.

On Thu, Feb 5, 2015 at 9:28 AM, Paul Davis p...@linuxaudiosystems.com
wrote:



 On Thu, Feb 5, 2015 at 12:19 PM, Göran Hasse gor...@raditex.nu wrote:




 Sorry... I have NOT done mutch MS-Window programming. This since I
 for about 20 odd years ago noticed that sockets (file descriptors)
 is the ONLY safe way to do communications by. (select, poll or
 kernel-queue etc).


 this is false.


 And you should only have one place in your application for dispatching
 events.


 this is false, although in the limited sense that a particular event loop
 should only run in a single thread, it is correct.



 ALL other communications mechanism tend to lock upp your application in
 one
 way or the other.


 this is false.



 And since your communicate over a socket you can as well design
 a good protocol to communicate by. And then it is easy to split the
 application into serveral parts. You know like client/servers. And why
 not many client-servers.


 it might be easier for some purposes, but it is vastly more complex for
 others. and in your case, you recommended one process per window, which is
 absurd.



 If you need a large memory segment you can use mmap() to have larger
 memory area.

 And you can study this in
 http://www.ibm.com/developerworks/aix/library/au-spunix_sharedmemory/


 i've been writing Unix applications for nearly 30 years. I don't need to
 read AIX documentation, thanks.



 The process in Unix *is* the multitasking abstraction.


 process-level parallelism is certainly more common in the unix world than
 on other platforms. but there is no reason to avoid threads when they are
 appropriate. and there is certainly no reason to use one process per window.



 You must ask what event notification mechanisms you have
 between threads!

 Then read manual pages for kqueue() in BSD...
 https://www.freebsd.org/cgi/man.cgi?query=kqueue

 Were can i find something like this for threads?


 threads can use all the same mechanisms as processes, but don't have to
 use OS provided APIs to share address spaces. that's really the only
 difference.



 And yes. My programs are a little bit more complicated - but they don't
 hangs...


 my program typically runs between 12 and 26 threads inside a single
 process. It has only a single thread that makes any GUI function calls
 (other than g_idle_add() or its equivalent). it doesn't hang.

 but more generally, MOST applications don't need multiple threads or
 multiple processes, even when they have multiple windows. to suggest that
 you should plan on 1 process per window is crazy.



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




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Multithreaded application freezing

2015-02-03 Thread Jasper St. Pierre

Why? Having two socket connections make up one client can't really work
out, considering they're two different streams which can't be synchronized
between.


On Tue, Feb 3, 2015 at 12:05 AM, G Hasse gor...@raditex.nu wrote:

  Den 2015-02-03 03:26, Jasper St. Pierre skrev:



 On Mon, Feb 2, 2015 at 5:07 PM, G Hasse gor...@raditex.nu wrote:

  Den 2015-02-02 22:57, Gulshan Singh skrev:

 I strongly advice designing an application in this way.  Every window in
 an application should be a separate process. Between processes you should
 find a good protocol. This protocol should be transported over some
 message buss. (example: www.spread.org)


  This will break under Wayland, which has a strong tie for one socket
 connection = one client. Threads can be used successfully, but they require
 care and expertise. The recommended approach is to use worker threads which
 share as little as possible with the main thread.

Then Wayland is totaly broken... (In my opinion).


   Regardless, this really should be using more event-based programming
 than threads for this sort of communication.

 /gh


I've made a simplified example of this and asked it on StackOverflow:
 http://stackoverflow.com/questions/28287520/cant-type-in-gtkentry-after-exiting-forked-window-manager

 Any help is appreciated.
 On Fri Jan 30 2015 at 1:12:55 PM Gulshan Singh gsingh2...@gmail.com
 wrote:

 I'm working on a display manager here:
 https://github.com/gsingh93/display-manager/tree/tutorial (make sure
 you're on the `tutorial` branch, not `master`).

  When a user successfully logs in, I fork a new process that starts the
 window manager and wait for that process to terminate. Since this is a long
 running operation, I need to do this in a new thread so I don't block the
 GTK thread.

  However, I need to do various GTK operations during this long running
 thread, such as updating label text or hiding the window. I've read online
 that I should be using `gdk_threads_add_idle` to do this.

  Here are the relevant two functions:
  ```
 static void* login_func(void *data) {
 GtkWidget *widget = GTK_WIDGET(data);
 const gchar *username = gtk_entry_get_text(user_text_field);
 const gchar *password = gtk_entry_get_text(pass_text_field);

  gdk_threads_add_idle(set_status_label_text, Logging in...);
 pid_t child_pid;
 if (login(username, password, child_pid)) {
 gdk_threads_add_idle(hide_widget, widget);

  // Wait for child process to finish (wait for logout)
 int status;
 waitpid(child_pid, status, 0);
 gdk_threads_add_idle(show_widget, widget);

  gdk_threads_add_idle(set_status_label_text, );

  logout();
 } else {
 gdk_threads_add_idle(set_status_label_text, Login error);
 }
 gdk_threads_add_idle(set_password_entry_text, );

  return NULL;
 }

  static gboolean key_event(GtkWidget *widget, GdkEventKey *event) {
 if (event-keyval == ENTER_KEY) {
 pthread_create(login_thread, NULL, login_func, (void*) widget);
 } else if (event-keyval == ESC_KEY) {
 gtk_main_quit();
 }
 return FALSE;
 }
  ```
 The problem is when the process I forked ends (the fork happens in the
 `login` function, I see my display manager screen again but I can no longer
 type in any of the text boxes.

  If there isn't anything obvious wrong in the above code, I'd
 appreciate it if someone could run the display manager and take a look at
 what's wrong. You can run it with Xephyr. I start Xephyr with the command
 `Xephyr -ac -br -noreset -screen 800x600 :2 ` and then I run `DISPLAY=:2
 ./display-manager*`*. Note that when you log in, it executes the
 contents of ~/.xinitrc. In my case, I have that set to `exec awesome`, and
 everything works fine.

 Any help would be appreciated.



  ___
 gtk-list mailing 
 listgtk-list@gnome.orghttps://mail.gnome.org/mailman/listinfo/gtk-list



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




 --
   Jasper





-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Multithreaded application freezing

2015-02-02 Thread Jasper St. Pierre

On Mon, Feb 2, 2015 at 5:07 PM, G Hasse gor...@raditex.nu wrote:

  Den 2015-02-02 22:57, Gulshan Singh skrev:

 I strongly advice designing an application in this way.  Every window in
 an application should be a separate process. Between processes you should
 find a good protocol. This protocol should be transported over some
 message buss. (example: www.spread.org)


This will break under Wayland, which has a strong tie for one socket
connection = one client. Threads can be used successfully, but they require
care and expertise. The recommended approach is to use worker threads which
share as little as possible with the main thread.

Regardless, this really should be using more event-based programming than
threads for this sort of communication.

/gh


 I've made a simplified example of this and asked it on StackOverflow:
 http://stackoverflow.com/questions/28287520/cant-type-in-gtkentry-after-exiting-forked-window-manager

 Any help is appreciated.
 On Fri Jan 30 2015 at 1:12:55 PM Gulshan Singh gsingh2...@gmail.com
 wrote:

 I'm working on a display manager here:
 https://github.com/gsingh93/display-manager/tree/tutorial (make sure
 you're on the `tutorial` branch, not `master`).

  When a user successfully logs in, I fork a new process that starts the
 window manager and wait for that process to terminate. Since this is a long
 running operation, I need to do this in a new thread so I don't block the
 GTK thread.

  However, I need to do various GTK operations during this long running
 thread, such as updating label text or hiding the window. I've read online
 that I should be using `gdk_threads_add_idle` to do this.

  Here are the relevant two functions:
  ```
 static void* login_func(void *data) {
 GtkWidget *widget = GTK_WIDGET(data);
 const gchar *username = gtk_entry_get_text(user_text_field);
 const gchar *password = gtk_entry_get_text(pass_text_field);

  gdk_threads_add_idle(set_status_label_text, Logging in...);
 pid_t child_pid;
 if (login(username, password, child_pid)) {
 gdk_threads_add_idle(hide_widget, widget);

  // Wait for child process to finish (wait for logout)
 int status;
 waitpid(child_pid, status, 0);
 gdk_threads_add_idle(show_widget, widget);

  gdk_threads_add_idle(set_status_label_text, );

  logout();
 } else {
 gdk_threads_add_idle(set_status_label_text, Login error);
 }
 gdk_threads_add_idle(set_password_entry_text, );

  return NULL;
 }

  static gboolean key_event(GtkWidget *widget, GdkEventKey *event) {
 if (event-keyval == ENTER_KEY) {
 pthread_create(login_thread, NULL, login_func, (void*) widget);
 } else if (event-keyval == ESC_KEY) {
 gtk_main_quit();
 }
 return FALSE;
 }
  ```
 The problem is when the process I forked ends (the fork happens in the
 `login` function, I see my display manager screen again but I can no longer
 type in any of the text boxes.

  If there isn't anything obvious wrong in the above code, I'd appreciate
 it if someone could run the display manager and take a look at what's
 wrong. You can run it with Xephyr. I start Xephyr with the command `Xephyr
 -ac -br -noreset -screen 800x600 :2 ` and then I run `DISPLAY=:2
 ./display-manager*`*. Note that when you log in, it executes the
 contents of ~/.xinitrc. In my case, I have that set to `exec awesome`, and
 everything works fine.

 Any help would be appreciated.



 ___
 gtk-list mailing 
 listgtk-list@gnome.orghttps://mail.gnome.org/mailman/listinfo/gtk-list



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




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: RFC: GtkPreview library

2015-01-29 Thread Jasper St. Pierre

After talking to Owen today, I'm wondering if it makes sense to consider
GtkPreview a portable widget. These platforms tend to already have their
own document preview systems, and I'm not sure it makes sense to port all
our apps (evince preview system, LibreOffice preview system) to use our own
system instead of simply using the native preview widget.

OS X has QuickLook:
https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/Quicklook_Programming_Guide/Introduction/Introduction.html

While I can't find a Win32 equivalent, it seems file pickers use
IThumbnailCache:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb774628%28v=vs.85%29.aspx

On Wed, Jan 28, 2015 at 1:23 AM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

All of this is part of wl_event_loop, which is an unfortunate public API
that should probably go away.

On Wed, Jan 28, 2015 at 1:21 AM, Philip Chimento
philip.chime...@gmail.com wrote:

On Tue, Jan 27, 2015 at 8:49 AM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

Gah. I always get those backwards. I actually typed SCM_RIGHTS and
then changed it to SCM_CREDENTIALS. I still don't understand why fd
passing is called rights.

On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:

On 27/01/15 15:55, Jasper St. Pierre wrote:
Wayland requires two features that would perhaps make it unportable:
FD
passing (SCM_CREDENTIALS), and shared memory (allocate a temporary
files, ftruncate it, mmap it, unlink it and then send the fd across
the
wire). Everything else is just a simple Unix domain socket. Does OS X
support those two features?

I think you mean SCM_RIGHTS?

SCM_RIGHTS is here's a message with an open fd attached. It's how
D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite
platform, Wayland fd-passing should too.

SCM_CREDENTIALS is here's a message with my uid, gid and pid[1]
attached, the kernel will check that I haven't lied to you (also called
SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a
syscall to query those things or both, but most Unixes also have their
own unique spelling for the API, because standards are hard.[2]

[1] Strictly speaking the uid, gid and pid I had at the time I opened
this socket
[2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and
several platforms (sadly not including Linux) share getpeereid(). For
the gory details see libdbus source code.

I put it to the test and tried to build Jasper's proof of concept (and
therefore Wayland) on OSX. I didn't get very far. Wayland's configure.ac
checks for SFD_CLOEXEC and TFD_CLOEXEC which implies that it uses
signalfd() and timerfd(), not available on OSX. I guess the replacement
would be something with kqueue though I really haven't the faintest idea
what I'm talking about there.

Wayland also wants clock_gettime() - not insurmountable to provide on OSX
but afaik uses a different API, quick googling showed up this:
http://stackoverflow.com/a/6725161/172999

PS. Funny thing that this is one of the top results for googling
SFD_CLOEXEC, even without adding osx or wayland:
http://stackoverflow.com/questions/27864027/sfd-cloexec-wayland

Best,
--
Philip

--
Jasper

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

Re: gtk_style_context_get()

2015-01-29 Thread Jasper St. Pierre

This is a pipe dream, I imagine, but would it be possible to get people to
cache their stuff only inside size_allocate(); or draw();, and just do
something dumb like lie to the user and warn if they do it outside of one
of those paths?

I think doing drawing of the DND window outside of the frame clock is a bit
much --  we should be synchronized to that in any case.

I haven't investigated how much breakage something like that would cause.

On Thu, Jan 29, 2015 at 11:51 PM, Benjamin Otte o...@gnome.org wrote:

 Hey,

 Here's a problem I'm currently thinking about and would like input on. I
 discussed it with Matthias on #gtk+ today and he suggested I'd reach out to
 more people. I've included the log below and formatted it for clarity so
 that it reads like a QA-style interview. I hope it is not too inconvenient
 to read.

 Company the question we're trying to answer is this: What CSS values
 does GtkStyleContext return?
 Company this question is relevant because every time we change the CSS
 tree, we need to (potentially) update the value

 Company 3.0.0 used the approach of immediately updating everything once
 the css tree changed somehow
 Company so if you did: context.add_class(a); context.add_class(b);
 context.add_class(c);
 Company it would recompute the CSS 3x
 Company which gets real slow really fast

 Company in 3.4 or so I changed that to always return a stale value
 Company until we validated the style via gtk_container_idle_sizer()
 (when the frame clock runs)
 Company so from that point on everything was fast, but the values were
 sometimes incorrect

 mclasen wouldn't you want to mark the values as stale, and force a
 recompute when somebody asks for a value ?
 Company ideally, you would
 Company the reason I did not do that was the style-updated signal
 Company when should that be emitted?
 Company if we emit it once a context gets invalid, we go back to 3.0
 performance
 Company because every widget queries values in the style-updated
 handler...

 mclasen you could do some freeze/thaw to batch the 3 emissions from 3
 add_class calls
 Company I don't want to add freeze/thaw calls though, everybody would
 get those wrong

 mclasen who needs to listen to style-updated anyway ?
 mclasen other than the gtk redraw machinery
 Company mostly just that
 Company GtkWidget needs to update the pango context
 Company GtkImage needs to release the cached surface
 Company things like that
 Company and of course we need to queue_draw() or queue_resize()

 Company here's another caveat: computing the CSS values requires
 computing the CSS values of the parent

 mclasen is that on the person changing the style context, or do we do
 that automatically ?
 Company GtkWidget::style-updated does that
 Company based on the GtkCssAffects settings of the changed style
 properties

 mclasen my mental model of this is that css values are used when drawing
 happens, so they need to be current at that point
 mclasen and drawing happens when the frame clock comes around to tell us
 Company yes
 Company when the frame clock triggers, we (1) recompute styles, (2)
 size_allocate everything pending, (3) draw

 mclasen whether css values are up-to-date at other points in the frame
 cycle should not be important
 mclasen except for those 3rd party users who randomly poke at style
 contexts...
 Company but it is important
 Company otherwise you get shrinking gnome terminals and white firefox
 text
 Company the gnome terminal case is actually rather complex to get right
 with the should not be important assumption
 Company because it needs to compute a bunch of values based on multiple
 different widgets
 Company and it needs to compute those before size allocation happens
 Company in short: It needs to happen in style_updated() at the latest -
 but which style-updated, when it depends on multiple widgets?

 halfline can't you just give the right value any time the user asks for
 it (updating the cache for that property if it's stale), but also keep
 style-updated where it happens now ?
 Company that's one thing we could do
 Company there's many solutions to the problem(s)
 Company I haven't reached the point yet where want to talk about
 solutions
 Company so far I'm trying to list the problem(s) :)

 mclasen 'before size allocation' sounds like a global thing though ?
 like a point in the frame cycle
 mclasen as long as we keep information about which styles are
 up-to-date, doing on-the-spot validation for people who call
 gtk_style_context_get_foo outside of regular frame-based drawing may just
 fine ?
 mclasen at least, only the people doing the poking are paying the price
 of extra recomputations then

 Company lemme do a short jsfiddle to show you how the web does it
 Company http://jsfiddle.net/nbt2myzb/1/
 Company I hope that example is simple enough
 Company you wanna understand why uncommenting that 1 line of JS makes
 the animation restart
 Company (disclaimer: I'm using firefox, no idea if webkit does things

Re: RFC: GtkPreview library

2015-01-27 Thread Jasper St. Pierre

I've done the above.

https://github.com/magcius/wakefield

Check it out, run make, then run:

$ LD_LIBRARY_PATH=. ./test-compositor
$ ./test-client-2

Right now it's a very basic prototype -- it doesn't support all
functionality, it doesn't dynamically resize the surface the client handed
us, and will easily crash, but for a day and a half of work, I think it
proves that it can be done.


On Tue, Jan 27, 2015 at 5:19 AM, Cosimo Cecchi cosi...@gnome.org wrote:

 So you're effectively proposing that the transport of the data between
 plugins and the widget is always Wayland, even if the session is running
 under X11? That sounds like a good idea to me if it's possible to
 implement. I would definitely welcome a proof of concept!

 Thanks,
 Cosimo

 On Sun, Jan 25, 2015 at 4:21 PM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 We could indeed write a tiny Wayland compositor that composited a single
 wl_surface as a GTK+ widget, and I wouldn't feel too bad about it. We could
 even do it while under X11, and it might be an interesting proof of
 concept. I could do a PoC if you guys want.
 On Jan 25, 2015 8:05 AM, Cosimo Cecchi cosi...@gnome.org wrote:

 Fair enough, those are good points.
 To rephrase my last message I am not well-versed in the details of
 subsurfaces and how they would help in this case, so I will appreciate help
 to evolve my API proposal in that direction :-)

 Cosimo

 On Sun, Jan 25, 2015 at 3:49 PM, Emmanuele Bassi eba...@gmail.com
 wrote:

 hi;

 On 25 January 2015 at 13:31, Philip Withnall phi...@tecnocode.co.uk
 wrote:

  That's why my proposal doesn't enforce this specific design; I'm
  definitely open to think more about how a multi-process design looks
  like, but I wouldn't want to block until that is figured out.
 
  To me, the security and rendering architecture of this seems pretty
 core
  in the design, so I _would_ block on figuring it out. It doesn’t feel
  like the kind of thing which can easily be bolted on or fixed
  afterwards.

 I tend to agree; we need to start designing our API with sandboxing
 and security context separation from the start, these days, otherwise
 we'll have nothing but grief (in the form of API changes or, worse,
 complete rewrites) down the line.

 ciao,
  Emmanuele.

 --
 https://www.bassi.io
 [@] ebassi [@gmail.com]



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





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

Re: RFC: GtkPreview library

2015-01-27 Thread Jasper St. Pierre

All of this is part of wl_event_loop, which is an unfortunate public API
that should probably go away.

On Wed, Jan 28, 2015 at 1:21 AM, Philip Chimento philip.chime...@gmail.com
wrote:

 On Tue, Jan 27, 2015 at 8:49 AM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 Gah. I always get those backwards. I actually typed SCM_RIGHTS and then
 changed it to SCM_CREDENTIALS. I still don't understand why fd passing is
 called rights.

 On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie 
 simon.mcvit...@collabora.co.uk wrote:

 On 27/01/15 15:55, Jasper St. Pierre wrote:
  Wayland requires two features that would perhaps make it unportable: FD
  passing (SCM_CREDENTIALS), and shared memory (allocate a temporary
  files, ftruncate it, mmap it, unlink it and then send the fd across the
  wire). Everything else is just a simple Unix domain socket. Does OS X
  support those two features?

 I think you mean SCM_RIGHTS?

 SCM_RIGHTS is here's a message with an open fd attached. It's how
 D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite
 platform, Wayland fd-passing should too.

 SCM_CREDENTIALS is here's a message with my uid, gid and pid[1]
 attached, the kernel will check that I haven't lied to you (also called
 SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a
 syscall to query those things or both, but most Unixes also have their
 own unique spelling for the API, because standards are hard.[2]

 S

 [1] Strictly speaking the uid, gid and pid I had at the time I opened
 this socket
 [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and
 several platforms (sadly not including Linux) share getpeereid(). For
 the gory details see libdbus source code.


 I put it to the test and tried to build Jasper's proof of concept (and
 therefore Wayland) on OSX. I didn't get very far. Wayland's configure.ac
 checks for SFD_CLOEXEC and TFD_CLOEXEC which implies that it uses
 signalfd() and timerfd(), not available on OSX. I guess the replacement
 would be something with kqueue though I really haven't the faintest idea
 what I'm talking about there.

 Wayland also wants clock_gettime() - not insurmountable to provide on OSX
 but afaik uses a different API, quick googling showed up this:
 http://stackoverflow.com/a/6725161/172999

 PS. Funny thing that this is one of the top results for googling
 SFD_CLOEXEC, even without adding osx or wayland:
 http://stackoverflow.com/questions/27864027/sfd-cloexec-wayland

 Best,
 --
 Philip




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

Re: RFC: GtkPreview library

2015-01-27 Thread Jasper St. Pierre

Gah. I always get those backwards. I actually typed SCM_RIGHTS and then
changed it to SCM_CREDENTIALS. I still don't understand why fd passing is
called rights.

On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie 
simon.mcvit...@collabora.co.uk wrote:

 On 27/01/15 15:55, Jasper St. Pierre wrote:
  Wayland requires two features that would perhaps make it unportable: FD
  passing (SCM_CREDENTIALS), and shared memory (allocate a temporary
  files, ftruncate it, mmap it, unlink it and then send the fd across the
  wire). Everything else is just a simple Unix domain socket. Does OS X
  support those two features?

 I think you mean SCM_RIGHTS?

 SCM_RIGHTS is here's a message with an open fd attached. It's how
 D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite
 platform, Wayland fd-passing should too.

 SCM_CREDENTIALS is here's a message with my uid, gid and pid[1]
 attached, the kernel will check that I haven't lied to you (also called
 SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a
 syscall to query those things or both, but most Unixes also have their
 own unique spelling for the API, because standards are hard.[2]

 S

 [1] Strictly speaking the uid, gid and pid I had at the time I opened
 this socket
 [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and
 several platforms (sadly not including Linux) share getpeereid(). For
 the gory details see libdbus source code.

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




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

Re: RFC: GtkPreview library

2015-01-25 Thread Jasper St. Pierre

We could indeed write a tiny Wayland compositor that composited a single
wl_surface as a GTK+ widget, and I wouldn't feel too bad about it. We could
even do it while under X11, and it might be an interesting proof of
concept. I could do a PoC if you guys want.
On Jan 25, 2015 8:05 AM, Cosimo Cecchi cosi...@gnome.org wrote:

 Fair enough, those are good points.
 To rephrase my last message I am not well-versed in the details of
 subsurfaces and how they would help in this case, so I will appreciate help
 to evolve my API proposal in that direction :-)

 Cosimo

 On Sun, Jan 25, 2015 at 3:49 PM, Emmanuele Bassi eba...@gmail.com wrote:

 hi;

 On 25 January 2015 at 13:31, Philip Withnall phi...@tecnocode.co.uk
 wrote:

  That's why my proposal doesn't enforce this specific design; I'm
  definitely open to think more about how a multi-process design looks
  like, but I wouldn't want to block until that is figured out.
 
  To me, the security and rendering architecture of this seems pretty core
  in the design, so I _would_ block on figuring it out. It doesn’t feel
  like the kind of thing which can easily be bolted on or fixed
  afterwards.

 I tend to agree; we need to start designing our API with sandboxing
 and security context separation from the start, these days, otherwise
 we'll have nothing but grief (in the form of API changes or, worse,
 complete rewrites) down the line.

 ciao,
  Emmanuele.

 --
 https://www.bassi.io
 [@] ebassi [@gmail.com]



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


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

Re: GTK+ brochure for FOSDEM

2015-01-23 Thread Jasper St. Pierre

On Fri, Jan 23, 2015 at 3:37 AM, Sébastien Wilmet swil...@gnome.org wrote:

 On Thu, Jan 22, 2015 at 10:51:38PM +, Alberto Ruiz wrote:
  I agree with Paul here, GTK+ targets people who want to do desktop apps.
 I
  would actually try to sell all the new stuff for developers like the new
  introspection tool, the new widgets and some of the new CSS work with
  snippets.

 One purpose of the flyer that I had in mind is to explain what to learn
 for writing a GLib/GTK+ program, providing an overview. If people have
 never heard of GObject, they will look at some code and will be afraid
 of all the macros and other boilerplate code that they don't understand.

 The learning path for writing a GTK+ application should be: GLib -
 GObject (at least the basis) - a bit of GIO - and finally GTK+. All
 GTK+ widgets are GObject classes! we cannot ignore GObject… For me it's
 important to explain what it is, at least briefly.


I disagree. The learning path for writing a GTK+ app should start with GTK+
and let them venture into the utility libraries of GLib and Gio when they
need to. No need to start with here's the library that seemingly reinvents
all of C99 because people sometimes still use SunCC in TYOOL 2015.


 Also, it's important to note that GObject was intentionally designed
 with bindings in mind. It's also a selling point for many people.

 In general, Linux users know what is GTK+. GLib, GObject and GIO on the
 other hand are less well known, but deserve more attention (e.g. for
 writing daemons, as explained in the brochure).

 For the images, there is already a GNOME flyer with some screenshots if
 I remember correctly, so in my opinion it's not really important to
 include lots of GTK+ screenshots (but one more image at the end could be
 better).

 Sébastien
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list




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

Re: GTK+ brochure for FOSDEM

2015-01-23 Thread Jasper St. Pierre

On Jan 23, 2015 12:06 PM, Sébastien Wilmet swil...@gnome.org wrote:

 On Fri, Jan 23, 2015 at 06:18:02PM +, Alberto Ruiz wrote:
  I don't see much of a debate there. Most people want to solve a problem,
  and start from the problem, not from the tool to solve it

 That's why the brochure begins by an introduction to GTK+ and an
 architecture overview.

  People who are likely to use GTK will start from the problem they want
to
  solve and are in need for a graphical toolkit to draw widgets that do
what
  they want.

 Exactly. People who use GTK+ applications already know what is possible
 to do with GTK+. Or if they use KDE or Windows or whatever, the
 applications and the desktop are the visible part that they already
 understand well. You just need to say you can do that with GTK+.

 On the other hand, what happens under the hood isn't obvious, and can be
 interesting (e.g. for a CS student) even if the person doesn't want to
 write a GTK+ app.

 At FOSDEM there are some Belgian students (like me several years ago)
 that traverse every stand and take as many things as possible, be it
 stickers, brochures, pens, etc. I have that public in mind too. Imagine
 a young student who reads the GTK+ brochure, and then several years
 later he/she wants to write a daemon, ideally the student will remember
 the brochure about GLib/GObject and event-driven programming and will
 start learning GLib!

That seems like an extremely bizarre and specific use case to optimize for,
especially given that GLib's event loop isn't that well designed for server
scenarios. They'd be better served by libev / libevent.

  Point them at what the toolkit does and the easiest way to use it,
  and people will learn as they go. GObject and GIO by themselves are of
no
  interest for most people wanting to write apps, specially in C.

 Uh, it's quite the contrary IMHO. If a developer chooses the C language
 and wants to write a GTK+ application, it's advised to write GObject
 classes to have a good code architecture. Look at gedit for instance,
 it's full of GObject classes. You create a subclass of GtkApplication, a
 subclass of GtkWindow for your main window, subclasses of GtkGrid or
 GtkBox for some other components that you have in your application, etc.
 Without GObject, you can write structs, allocate them and pass a pointer
 as the self argument, but GObject is much more powerful. It's
 interesting to create signals for example.

 For developers who choose a higher-level language, knowing the basis of
 GObject is useful too: what is a GObject signal, what is a property, oh
 there is actually an object hierarchy and I can call a function from the
 parent class, etc.


 Sébastien
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GObject introspection for cairo

2015-01-22 Thread Jasper St. Pierre

Cairo-GObject provides access to enums, but it won't automatically get you
great cairo bindings. It might actually get you 90% of the way there,
though, and I'd be interested seeing how far you can run with just that,
and be happy to merge patches that make it easier.

Why? cairo has a subtype system where you have subtypes of cairo_surface_t
(e.g. cairo_image_surface_t) or cairo_pattern_t (e.g.
cairo_gradient_pattern_t) where some objects have special methods. You
determine which type this is by calling cairo_surface_get_type(); and
matching it against a closed enum (cairo_surface_type_t).

It might be enough to do 90% of the work with GObject-Introspection and
write some small by-hand functions when you need to cast to a specific
type in your binding, but you do always need some small native glue code
that calls cairo_surface_get_type();

On Thu, Jan 22, 2015 at 9:39 AM, Nicola Fontana n...@entidi.it wrote:

 Il Thu, 22 Jan 2015 16:28:19 + Emmanuele Bassi eba...@gmail.com
 scrisse:

  Cairo is not a GObject library, so introspection is fairly useless.

 Hi Emmanuele,

 the cairo source tree includes cairo-gobject [1] that already wraps
 enums and structs in GObject style. I just browsed the code and added
 the missing types to the gir file.

  for Cairo, you should always prefer native bindings — like pycairo, or
  the cairo GJS module.

 I'm using LGI [2] which provides automatic bindings based on GObject
 introspection. This gives me the ability to access all the libraries I
 need (cairo is only one of them) through the same interface.

 One of my API needs the cairo_surface_type_t enum, so adding a new
 dependency only for that is not an option. If the patches are rejected
 I'll wrap the enum on my side instead (or drop that particular feature).

  if you have patches, please attach them on Bugzilla.

 Sorry, my bad. I had really hard time trying to figure out how to submit
 bugs to gobject-introspection. I just discovered (10 mins ago) I need to
 select GLib as product first.

 Ciao.
 --
 Nicola

 [1] http://cgit.freedesktop.org/cairo/tree/util/cairo-gobject
 [2] https://github.com/pavouk/lgi
 ___
 gtk-devel-list mailing list
 gtk-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-devel-list




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

Re: a new combo box

2014-12-28 Thread Jasper St. Pierre

So let me ask a very basic question here, since I feel it's at the heart of
the dumb internet argument we're having.

What is this design trying to solve? What problems with the old ComboBox
are we trying to fix? What use cases is it designed for?

Is it the usability problems? Are we adding the search field to behave more
like Chosen [0] ? Because that's really cool. If that's the main purpose of
the redesign, I'd like to keep the old GtkComboBox API so that users
benefit by the new usability immediately.

Is it a just a visual refresh, making the new widget seem more new GTK+
than the old one?

Is it the ability to use widgets instead of cell renderers in ComboBox? OK.
Is that worth a new visual refresh and new usability scenario? Could we
upgrade both at the same time, and have one API for widgets, and one API
for cell renderers? Would that be feasible?

My issue, really, is that I haven't really been keeping up with GTK+
development and new widgets over the course of time. I hack on some
personal apps in my spare time.

If we add GtkCombo as a separate question, I have one simple question: when
should I use GtkCombo and when should I use GtkComboBox?

Cosimo talks about GtkPopover and GtkMenu, but those just sort of have me
stunned. Why should I use one instead of the other? We have GtkMenuButton,
GtkMenu, GtkModelMenu, GtkModelButton, GtkPopover, GtkPopoverMenu, and they
all sort of do the thing. I have no idea which to use nowadays.

(This is not a chance to explain what they do: I have an understanding of
what does what after reading the docs. But imagine someone who's never done
GTK+ development before. What's the new hot, correct, widget to use if
you want a menu button in your app? What's it called? OK. Why are the
others there?)

[0] http://harvesthq.github.io/chosen/

On Sat, Dec 27, 2014 at 5:02 AM, Matthias Clasen matthias.cla...@gmail.com
wrote:

Hi,

over Christmas, I had some for a little side project, a new combo
box. It is based on these mockups:

https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png

One question I need some feedback on is naming: We currently have
GtkComboBox and
GtkComboBoxText. I've gone with GtkCombo for now, which has the
downside that there is a widget by that name in gtk2. Alternatives
might be GtkChoice or GtkComboButton (with a possible avenue for
making the list-of-choices available for direct embeeding as
GtkComboWidget later).

There are some lose ends in the code, like the interaction of grouping
and search, but it is complete enough to give it a try and evaluate
the design. If you want to try it, the code is in the wip/combo
branch, and there is a testnewcombo test app with some examples.

I'm off for a few days now - would be great to hear some feedback when
I come back.

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

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

Re: gtk_widget_set_double_buffered() is deprecated, so what can replace it?

2014-11-26 Thread Jasper St. Pierre

On Wed, Nov 26, 2014 at 10:40 AM, Lance Arsenault lance.arsena...@gmail.com
 wrote:

 Hello GTK developer,

 I've read the latest docs, looked at the latest (git) GTK+3 code, and
 searched the archives, and found not direct answer to this question:

 1.  Is there a method, that is not deprecated, that can give the effect of
 gtk_widget_set_double_buffered() for GTK3?


No. It will continue to work on X11, but it won't work on new backends like
Wayland or Mir.


 There are a lot of apps that must use the underlying/native drawing APIs
 like libX11 and OpenGL to draw to a X11 window that is within a GTK+3.0
 app.  It is very clear that drawing to, or transferring content to, a Cairo
 surface is far too slow for apps that render real-time animations in an X11
 window.


Why would it be too slow? GDK has also recently gained support for native
GL drawing: https://developer.gnome.org/gtk3/unstable/GtkGLArea.html which
works perfectly in tandem with the double buffering drawing. Both of these
options should be performant enough, and if not, we'd prefer to improve the
performance of our cross-platform APIs rather than add new ways to work
around it.

Many apps must use X11 and/or OpenGL, and GTK+3.0 together, so what's the
 new hook that will stop GTK from using Cairo surface double buffering in a
 GTK+ drawing area.

 cheers
 lance





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




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

Re: gtk_widget_set_double_buffered() is deprecated, so what can replace it?

2014-11-26 Thread Jasper St. Pierre

Hey,

I just built Quickscope from source, and can't find any code that draws
using cairo inside it. Where is it?

On Wed, Nov 26, 2014 at 6:08 PM, Lance Arsenault lance.arsena...@gmail.com
wrote:

 Hi  Emmanuele,

  apps using X11 to draw directly should stop doing that, because this is
 not 1997 any more, and we have better drawing API.


 Many many apps need a faster drawing API than Cairo in order to do high
 frame rate animations.  Interactive games is the most popular example.

 I have an unusual app that requires faster drawing without animations.
 It's the difference between being able to use the app for some purposes or
 not, that is to say it's the difference between working and not working.
  So Cairo is just not usable in this case, it's far to slow.  Why should I
 care that libX11 is old?

 This is not a small set of users that need this.  People don't care that
 the code is old, so long as it works for what we are doing.  Please
 consider that Cairo is too slow for many applications.  The largest group
 of apps that require fast drawing are openGL apps, but there is also a
 somewhat smaller group of apps that need faster 2-D drawing too.  Cairo
 does not meet many minimum speed requirements.  I hear that GtkGLArea is
 coming of age.  I hope that I can use it for 2-D drawing too, but I will be
 sticking with libX11 drawing if that is faster than OpenGL for my use case,
 and I expect that drawing with libX11 will be faster for my use case.  (see
 below for more verbose with real runnable examples)

 I got two responses from my query.   I attach more below.  I forgot to CC
 the list in the email I sent before this one.

 cheers
 lance



 I'm not sure where this is going but I need to make sure I'm clearly
 understood.  Sorry for being too verbose. If you respond, please read it
 all.


 1.  on Cairo speed:   I've spent many days testing Cairo for speed.  Cairo
 draws lines very slowly compared to libX11 XDrawLines().  It does lots of
 nice things, but sometimes you just need to draw as fast as possible.  In
 the current app I'm developing I can't even use XDrawLines().  I use
 XDrawPoints() with my own line drawing code, and I use my own anti-aliasing
 code for some of the lines.

 2.  The GtkGLArea https://developer.gnome.org/
 gtk3/unstable/GtkGLArea.html is news to me.  I will look into it.
 Currently I'd like to use it to draw with libX11 and not directly with
 openGL given I'm just doing 2-D drawing with just point drawing.  It's a
 little unclear what the fastest simple 2-D pixel drawing method is, because
 I see the X-server may be doing the right things already for fast 2-D
 drawing, i.e. I see it's using shared memory to get my pixels from my
 program, it links with OpenGL libs, and etc.  Sounds like way way more than
 I need, and it's likely to slow things down, compared to what I have now.
 I'm also looking into libXrender, but know almost nothing about it yet.

 3.  If you'd like to understand my perspective about drawing speed I have
 an example that explains it well when using a GNU/Linux system.  Install
 quickplot (available on debian apt-get install quickplot) and run
 `quickplot LARGESOUNDFILE' where LARGESOUNDFILE is about a 3 minute sound
 file.  You will see quickplot display the whole sound file in about 3
 seconds.   Running `quickplot -c LARGESOUNDFILE' takes about 15 seconds to
 display.  That is because the '-c' option makes quickplot use Cairo to
 draw.  Of course back when I wrote quickplot using GTK+3.0 the difference
 was much more dramatic.  This may be a stupid example, but it makes my
 point, Cairo is slow.

 4.  Now I'm making a software oscilloscope and 2-D drawing speed is
 paramount.  I see that in the GTK+3.0 code that there is Cairo code in
 gtk_widget_send_expose() that is adding system resource waste with
 gdk_cairo_create(), which I don't need, given I'm drawing with libX11 and
 not Cairo.   This is not so bad, for this scope, given that most of the
 time the GTK+ draw event and its callbacks are not used in most of my
 draw display frames (just used in initial draws).  My code just draws over
 the X11 window without using GTK events, at like, for example, 60 times a
 second.  This seems like a nasty hack.  Clearly if GTK+3.0 has a method to
 add animations I do not want to use it, given that it will do a bunch of
 Cairo stuff that I'll just want to work around it order to get the speed
 that I need.

 5.   Optional:  If you got this far.   You can see for yourself what I'm
 up too and why GTK+3.0 needs to support fast 2-D drawing:

 sudo apt-get install libsndfile-dev  # the prerequisite you may not have
 \
 mkdir -p ${HOME}/tmp_quickscope  \
 cd ${HOME}/tmp_quickscope  \
 git clone https://github.com/lanceman2/quickscope.git  \
 cd ${HOME}/tmp_quickscope/quickscope  \
 ./bootstrap  \
 ./configure --enable-debug --enable-tests --prefix ${HOME}/tmp_quickscope
  \
 make -j3  ./tests/alsaCapture

 I just successfully cut and pasted and ran that on my

Re: help wanted for implementing GdkGLContext on Windows and MacOS X

2014-11-19 Thread Jasper St. Pierre

Yeah, this is an unfortunate bug with libepoxy right now. There's a PR on
GitHub if you want to see if that fixes it.

https://github.com/anholt/libepoxy/pull/28

All we can do is pressure Eric Anholt to merge it at this point.

On Wed, Nov 19, 2014 at 12:03 AM, Philip Chimento philip.chime...@gmail.com
 wrote:

 On Sun, Nov 16, 2014 at 6:32 AM, Emmanuele Bassi eba...@gmail.com wrote:

 hi all;

 I posted this on my blog, which is syndacated on Planet GNOME, but I
 thought about trying to reach out to more people by using the GTK+
 mailing list as well.

 GTK+ 3.16 will have OpenGL support out of the box — at least on X11 and
 Wayland.

 if you are using GTK+ 3.x on Windows and/or MacOS X, or if you're
 using external libraries like GtkGLExt and GtkGLArea with GTK+ 2.x or
 3.x, then I'm asking you to help out with patches and testing the
 OpenGL support in the master branch of GTK+. we'd really like to have
 OpenGL support working on all the major backends in GDK by the time we
 release GTK+ 3.16.0, next February.


 I've started trying to build GTK master on OSX; looks like libepoxy is now
 a dependency of GDK, and libepoxy in turn needs X11.h. How hard is that
 dependency? It seems to me that I shouldn't need X11 for the Quartz backend.
 --
 Philip

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




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

Re: GtkStatusIcon and Unity

2014-09-11 Thread Jasper St. Pierre

The StatusIcon technology is based on the System Tray Specification [0].

Ubuntu explicitly chose to remove support for the System Tray Specification
in favor of their proprietary app indicators.

KDE and GNOME are also considering removing support for status icons
because of some of the same limitations, so consider GtkStatusIcon
deprecated.

[0]
http://standards.freedesktop.org/systemtray-spec/systemtray-spec-latest.html

On Wed, Sep 10, 2014 at 7:04 PM, Andrew Kelley superjo...@gmail.com wrote:

 Hi there. Below is a simple tray icon example program.

 It does not create an icon in Unity.

 Is support for this planned? If not, why? I thought part of the goal GTK+
 was to be cross-platform?

 Regards,
 Andrew

 #include stdio.h
 #include gtk/gtk.h

 static void tray_icon_on_click(GtkStatusIcon *status_icon, gpointer
 user_data) {
 printf(Clicked on tray icon\n);
 }

 static void tray_icon_on_menu(GtkStatusIcon *status_icon, guint button,
guint activate_time, gpointer user_data)
 {
 printf(Popup menu\n);
 }

 int main(int argc, char * argv[]) {
 gtk_init(argc, argv);

 GtkStatusIcon *tray_icon = gtk_status_icon_new();

 g_signal_connect(G_OBJECT(tray_icon), activate,
 G_CALLBACK(tray_icon_on_click), NULL);
 g_signal_connect(G_OBJECT(tray_icon), popup-menu,
 G_CALLBACK(tray_icon_on_menu), NULL);

 gtk_status_icon_set_from_file(tray_icon, GTK_STOCK_MEDIA_STOP);
 gtk_status_icon_set_tooltip(tray_icon, Blend);
 gtk_status_icon_set_visible(tray_icon, TRUE);

 gtk_main();

 return 0;
 }


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




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GtkStatusIcon and Unity

2014-09-11 Thread Jasper St. Pierre

Well, multiple Linux distros simply don't have tray icons anymore, so no
tray icon class can possibly work cross-platform.

It depends on what the design of your application is. I'd recommend that
you sway away from tray icons entirely in your application. For some Linux
distros, GtkStatusIcon might be acceptable. For others, you might have to
write an app indicator or design something better.

On Thu, Sep 11, 2014 at 9:43 AM, Andrew Kelley superjo...@gmail.com wrote:

 On Thu, Sep 11, 2014 at 1:42 AM, Jasper St. Pierre jstpie...@mecheye.net
 wrote:

 consider GtkStatusIcon deprecated.


 Is there an alternative? I'm looking for something that will work
 cross-platform (multiple linux distros, windows, osx).

 Is the simplest and most robust solution writing special code for each
 target platform's tray icon?




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Accuracy of motion events

2014-09-01 Thread Jasper St. Pierre

Gtk+ queues up processing motion events until the next tick in the frame
clock. It doesn't matter how fast you draw, we still throttle event
processing to the compositor's redraw cycle.
On Sep 1, 2014 5:57 AM, Stefan Salewski m...@ssalewski.de wrote:

On Mon, 2014-09-01 at 14:12 +0200, ax487 wrote:
Ok, as far as I am concerned disabling the event compression solves
the
problem. In my case I have optimized the drawing routines such that
the
time needed to process a motion event (i.e. to draw a new segment onto
the canvas) is 1ms. Since my code is able to keep up with the rate
at
which uncompressed events are generated disabling the compression
makes
sense in my case.

Fine when it solves your problems.

From my current understanding it should not!

https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-set-event-compression

Determines whether or not extra unprocessed motion events in the event
queue can be discarded.

If your drawing is fast, there should never be unprocessed motion
events, so event-compression true or false should make no difference.

I have done my tests with Linux, GMOME 3, GTK 3.12, X11, Gentoo AMD64
box, and was not able to see an effect. Maybe with other configuration
there is an effect. Some years ago I did some testing with the
MOTION_HINT_MASK and also saw no effect, and googling gave me some post
of others having problems with the hint mask also...

But not a big problem for me currently, generally I get motion events at
least every 12 to 17ms, which is OK, I really think with a 60 Hz Display
there is no way to get more smooth movements. (Indeed I wonder if there
is a way to sync movement with display refresh rate. My guess is that
double buffering and 60 Hz screen refresh will ad more delay to the 12
ms event interval, which may result in not really smooth movements
sometimes.)

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

Re: GTK+ scene graph, API deprecations

2014-08-18 Thread Jasper St. Pierre

On Mon, Aug 18, 2014 at 9:50 AM, Sébastien Wilmet swil...@gnome.org wrote:

 On Mon, 2014-08-18 at 10:00 +0100, Emmanuele Bassi wrote:
  On 16 August 2014 16:23, Sébastien Wilmet swil...@gnome.org wrote:
 
   With GskLayerContent, will it be possible to unify cell renderer and
   widget drawing models? To simplify significantly the GtkTreeView
   implementation, for example, and be able to insert a GtkWidget in a
   GtkTreeView.
 
  not without breaking API.
 
  we cannot really re-implement GtkWidget using GSK layers without
  breaking ABI in any case — think of whoever connects to
  GtkDrawingArea's ::draw signal, or whoever subclasses a GtkWidget and
  overrides the draw() virtual function; suddenly, they wouldn't be
  drawing on a cairo_t associated with a whole GtkWidget, but on a GSK
  layer's content. where would that layer go? on top? at the bottom of
  the stack? what happens if I connect to ::draw and then stop the
  signal emission?
 
  for GTK+ 3.x, the scene graph API is going to be available for you to
  write new widgets with a scene inside them, and to put widgets inside
  a scene. the short term goal is to fully replace the current usage of
  Clutter and Clutter-GTK (and possibly Clutter-GStreamer) throughout
  the GNOME stack; anything else is on a purely speculative basis, and
  it will land if and only if it does not break API and/or ABI. a full
  rework of the GTK widgets to use the scene graph API is going to wait
  until we can release GTK+ 4.

 Ok I see.

  it is also my opinion that, if we break API, we may as well deprecate
  GtkTreeView and replace it with the list widget backend by a model,
  and drop the whole cell renderer scene API in the first place.

 But GtkTreeView has the advantage that it already works and is mostly
 feature complete (to display trees too), and is used in lots of
 libraries and applications, with custom models etc. It seems easier to
 me to do code refactorings in GtkTreeView than creating a completely new
 widget from scratch.


... ahahahahaha


 And if GSK can potentially simplify a lot the
 GtkTreeView implementation in the future, and with the API break for GTK
 + 4, another solution is to simplify both the API and implementation of
 GtkTreeView for GTK+ 4.

 That said, I've never worked on the GtkTreeView code.


Ah, that's why. I vote you a volunteer for the GSK-ification of GtkTreeView
then.


 Maybe one of the
 reasons to create a new widget from scratch is because nobody wants to
 work on GtkTreeView anymore. But if that is the case, maybe in 10 years
 nobody will want to work on GtkListBox anymore, and developers will
 reinvent the wheels continually, by deprecating more and more APIs,
 creating new ones every decade, and make application developers grumpy.

 So in short, if some of the GTK+ code is a mess, why not keeping the
 same APIs while improving internally the code?


Because every time we try to clean up GtkTreeView, we break some random
application. It's a widget that has twenty three gazillion use cases, and
so we have to keep it a mess, because removing the mess means removing one
use case, and we can't do that.

You're welcome to try, though.


 --
 Sébastien

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




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

Re: GSignalFlags

2014-08-15 Thread Jasper St. Pierre

This is a bug in our doc generator, gtk-doc. There's a flag in that enum,
G_SIGNAL_DEPRECATED, which confuses it into thinking the entire enum is
deprecated. It's not. I think the bug is fixed in the latest version of
gtk-doc.


On Fri, Aug 15, 2014 at 3:35 PM, Emmanuel Pacaud emman...@gnome.org wrote:

 Hi,

 The documentation of Glib says:

 GSignalFlags is deprecated and should not be used in newly-written
 code.

 But GSignalFlags is the type of one of the parameters of g_signal_new. I
 did not find in the documentation how to avoid the use of GSignalFlags.

 In my code, I have two calls to g_signal_new, using G_SIGNAL_RUN_LAST.
 If I replace this value by 0, I get a warning on every call to
 g_signal_emit.

 Any idea ?

 Thanks,

 Emmanuel.

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




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: How to Get TextEvent in a window of another running process(linux gtk)

2014-08-10 Thread Jasper St. Pierre

Why do you want the title of another window in another process? What are
you trying to do?


On Sat, Aug 2, 2014 at 3:34 AM, hello pr...@126.com wrote:

 I have read a lot of document.
 But I can't find a little clue.

 I want get the text  event in a window of a running process.

 I have not the source code of the process,of course.

 It is like the hook in a microsoft windows.

 thank for any tips.




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




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Would it be possible that gtk implementation in C++

2014-08-07 Thread Jasper St. Pierre

Rewriting a widely-used library in a new language, breaking all APIs, is
not a good idea when we're already struggling to maintain our current
codebase. Regardless of whether you like C++ or not, this isn't going to
happen. Sorry.


On Thu, Aug 7, 2014 at 10:06 PM, 黄羽众 ih...@163.com wrote:

 Thank you for point out predecessors' question!

 I read the question and get some points, but I thinks the situtations
 change a lot and I am not ask the same question.

 1. I am not ask for why GTK choose to implement in C, I know it have some
 historical reason. I want to make a proposal that gtk could be re-written
 with c++ just as GCC does. I want to discuss with you whether it is a good
 idea.

 2. Situations change a lot. Back to the time GTK was born, C++ is also
 very primitive so the developers would rather implement an object-system by
 hand. But nowadays C++ is stable and have many cool features especially in
 C++11 and the in-coming C++14. C++'s object-system is becoming more and
 more complete and add many useful features in GUI development such as
 exception, multi-threads and so on. I think due to the same reason did GCC
 turn to C++.

 3. Now, from the view of app developers, who are very likely learned
 C/C++/Java in classes, and learn Python/JS/PHP/Nodejs after class. And very
 probably have experiences coding with QT, HTML5, Android. They can't be
 more familiar with OOP and C++. But when they turn to GTK, they have to
 expand one line in C++ into three or more lines in C. This will threaten
 many developers. Although there are gtkmm available, but gtkmm didn't gain
 enough official support and recommend as GTK, and much fewer reference,
 help, support available. The official recommand is gtk in c rather than
 gtkmm in c++, so many devlopers read some tutorials and feel threatened and
 leave. What's worse, gtkmm didn't wrapper all of the gtk featurese. In some
 complex cases, developers have to use the low level gobj pointer to get
 things done.


 Now is in 2014, It can't be more normal to develop GUI application with
 OOP style. I think it's time to change.

 GTK could be rewritten in C++, and what's more important, GTK should
 officially recommend to develop apps in C++, which can't be more familiar
 to GUI developers.


 Sent from MEIZU MX

  Original Message 
 From：Florian Pelz pelzflor...@googlemail.com
 Time：Fri 8/8 05:23
 To：gtk-list@gnome.org
 Subject：Re: Would it be possible that gtk implementation in C++

 Hi,
 
 Someone asked this question on Stackoverflow:
 
 http://stackoverflow.com/questions/9747468/why-was-the-gobject-system-created
 I think they answer it pretty well. Also, C is much closer to the
 hardware and GCC's error messages for C++ are not that great.
 
 On 08/07/2014 10:49 PM, Dub wrote:
  tbh, the only reason I use GTK is because it is C.
 
  While C++ is probably a better choice. C allows you to easier
  integrate it with pretty much any language of your choosing easily
  (Vala, Ruby, PHP (lol), Python, Rust, Go, Perl, Lua, Javascript, etc)
  that in itself is a really good reason.
 
 
  On Thu, Aug 7, 2014 at 12:22 PM, 黄羽众 ih...@163.com
  mailto:ih...@163.com wrote:
 
  For the past few time, I am using gtkmm to development GUI
  application, and I am really enjoy it.
 
  I know that choose C as its implementation language makes gtk gain
  a wonderful performance,
  but recently GCC turn to C++.
  https://gcc.gnu.org/gcc-4.8/changes.html
 
  I think that as a complier which have to think a lot about
  performance, it turn to C++ for code elegance and development speed,
  a GUI application have no reason to continue using C stuff.
 
  Actually gtk implement a object system as its essential part, that
  did prove that GUI application need a object-oriented design.
  And C++ could provide this as a language level feaure, needless to
  implement it in application code.
 
  So I suggest that it is possible to develop gtk in c++ as
  main-line support?
 
  Unlike gtkmm, which is just a wrapper from c++ to c, turn to c++
  in main-line means a lot.
 
  GCC choose this and get good result, I think gtk could have a try.
 
 
 
  ___
  gtk-list mailing list
  gtk-list@gnome.org mailto:gtk-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-list
 
 
 
 
  ___
  gtk-list mailing list
  gtk-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-list
 
 
 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list

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




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org

Re: Notify a GtkContainer of a size change of a child widget

2014-08-05 Thread Jasper St. Pierre

If the size if your widget has changed, call gtk_widget_queue_resize on
your widget to queue a resize cycle.


On Tue, Aug 5, 2014 at 5:03 AM, ax487 ax...@gmx.de wrote:

 Hello all,

 I have the following scenario: I have a huge custom GtkWidget which I
 want to display inside a GtkViewport inside a GtkScrolledWindow. The
 custom widget has implemented the get_preferred_height /
 get_preferred_width methods to notify the container of its enormous
 dimensions. Now assume that I want to offer the user the functionality
 to zoom into the widget in question. Of course this would increase the
 dimensions of widget even further. However, the GtkViewport doesn't know
 that the widget's desired geometry has changed. Is there any way to
 notify the GtkViewPort of this change? I noticed the (deprecated /
 undocumented) gtk_container_resize_children method of the GtkContainer
 but other than that I can't find anything in the documentation. I would
 appreciate it if you could give me some pointers.

 ax487
 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GTK+ scene graph

2014-08-03 Thread Jasper St. Pierre

On Sun, Aug 3, 2014 at 6:08 AM, Sébastien Wilmet swil...@gnome.org wrote:

 Thanks for the explanation.

 On Sun, 2014-08-03 at 01:13 +0100, Emmanuele Bassi wrote:
  snip

  yes, it was considered, and no: depth (or similar terms) won't be used.
 
  people using a canvas with 3D transformations intuitively grasp the
  concept of a Z axis, as well as that of a coordinate on that axis.
  they understand rotations around that axis, as well as scaling and
  translation.
 
  using depth would be confused with the possibility of having real
  3D objects, with a width, height, and depth.

 Ok so there are good reasons behind that. depth-axis would be a
 solution, but it's too long and x/y/z is a widespread convention. I was
 just wondering if the GSK API contains other conventions, maybe less
 widespread.


An API designed to be commonly used and understood by graphics programmers
is exactly the place where you don't want to use obscure, less widespread
conventions.


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




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

Re: error: expected primary-expression before ‘)’ token cast issue

2014-08-02 Thread Jasper St. Pierre

This is an issue with the syntax in the code you wrote, not with GTK+. As
such, pseudo-code won't really help us find the issue, nor is gtk-list an
appropriate place to ask for help. Giving us your real code might help us
figure out why the compile error happens, but we understand that this might
be an issue for you.

On Sat, Aug 2, 2014 at 11:14 AM, Bill Brown wbrown...@comcast.net wrote:

 Hello.  I'm trying to figure out why I get a compile error (in the subject
 of this message) for this cast during the initialization of a struct member
 variable.

 in myclass.h

 class MyClass {
 ...
 public:
 struct cpresets {
 char* soundfont_key;
 char* exists;
 UT_hash_handle hh;
 };
 ...
 };
 in myclass.cc

 void myclass::mymethod() {
 ...
 struct cpresets *newpreset;
 newpreset = (cpresets*) malloc(sizeof( cpresets));
 ...

 }
 There is another place in the cc file where this works.

 in myclass.cc

 ...
 typedef struct {
 ...
 }mystruct;

 ...

 static instantiate(){
 ...
 //this line causes the compile error
 mystruct* me = (mystruct*) malloc(sizeof(mystruct));
 ...
 }
 I see the difference in the case where it works is that the struct is
 defined in the cc file and in the case where it doesnt work, the struct is
 a member vairable of the class header. Do you know why this is an issue or
 what I might be able to do to fix it?

 Thanks.
 Bill.

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




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Color for selections

2014-07-27 Thread Jasper St. Pierre

In GNOME, we use a fairly dark blue color for selections.

You can get it by applying the GTK_STYLE_CLASS_RUBBERBAND style to your
widget. If you don't have a widget, you can use the gtk_render_* APIs on a
style context so that the background and border are rendered correctly.


On Sat, Jul 26, 2014 at 12:23 PM, ax487 ax...@gmx.de wrote:

 Hello all,

 I am (still) porting from gtk2 to gtk3 and I just read about the style
 properties of widgets. I want to draw a selection around some objects
 (think of the rectangle / lasso selection in gimp). I would like to know
 if there is some theme-dependent color that I can use. The background of
 the selection is mostly white, so it should be something dark so there
 is sufficient contrast. Is a suitable color available using some
 `gtk_style_context_get_color' function?

 ax487
 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: How to add a callback that can be called whenever the event loop calls an event handler?

2014-07-23 Thread Jasper St. Pierre

Why, though? Why do you need this?


On Tue, Jul 22, 2014 at 9:40 PM, Gang Chen gang.chen...@gmail.com wrote:

 Yes, I need an after handler for every event. We can think it is called
 at the bottom of all event handlers. The function should be called not only
 after my own event handlers but also the widgets' event handlers.


 2014-07-22 22:17 GMT+08:00 Paul Davis p...@linuxaudiosystems.com:




 On Tue, Jul 22, 2014 at 8:55 AM, Jasper St. Pierre jstpie...@mecheye.net
  wrote:

 Call the function at the bottom of all your event handlers?

 I'd need more detail about your specific case in order to help you
 further.


 I think he wants the equivalent of an after handler for event. If he
 wanted a before handler for event, I believe that already works (it
 does in GTK+2, anyway)






-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: How to add a callback that can be called whenever the event loop calls an event handler?

2014-07-23 Thread Jasper St. Pierre

So every single time somebody presses a key or clicks a button or even
moves your window, or even when a redraw is queued on the window, you want
to check the internal state of the window and possibly do something? That
sounds like a ridiculously bad design to me, personally.

Just call the function whenever state might change.


On Wed, Jul 23, 2014 at 11:52 AM, Gang Chen gang.chen...@gmail.com wrote:

 The function checks the state of the application and does something
 accordingly. Because any code in an event handler may potentially change
 the state of the application, a quick method is adding the function as the
 after handler for every event.


 2014-07-23 22:26 GMT+08:00 Jasper St. Pierre jstpie...@mecheye.net:

 Why, though? Why do you need this?


 On Tue, Jul 22, 2014 at 9:40 PM, Gang Chen gang.chen...@gmail.com
 wrote:

 Yes, I need an after handler for every event. We can think it is
 called at the bottom of all event handlers. The function should be called
 not only after my own event handlers but also the widgets' event handlers.


 2014-07-22 22:17 GMT+08:00 Paul Davis p...@linuxaudiosystems.com:




 On Tue, Jul 22, 2014 at 8:55 AM, Jasper St. Pierre 
 jstpie...@mecheye.net wrote:

 Call the function at the bottom of all your event handlers?

 I'd need more detail about your specific case in order to help you
 further.


 I think he wants the equivalent of an after handler for event. If
 he wanted a before handler for event, I believe that already works (it
 does in GTK+2, anyway)






 --
   Jasper





-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: How to add a callback that can be called whenever the event loop calls an event handler?

2014-07-22 Thread Jasper St. Pierre

Call the function at the bottom of all your event handlers?

I'd need more detail about your specific case in order to help you further.


On Tue, Jul 22, 2014 at 6:06 AM, Gang Chen gang.chen...@gmail.com wrote:

 Hi,

 The callback does something common to every event handler. The callback
 should be called after any event handler is called. How to accomplish this?

 Thanks,
 Gang

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




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: expose vs draw

2014-07-16 Thread Jasper St. Pierre

The cairo context you get is already clipped to the exposed region. You
don't need to do any extra work.


On Wed, Jul 16, 2014 at 12:33 PM, ax487 ax...@gmx.de wrote:

 Hello all,

 I am currently porting an application from gtk2 to gtk3. I just noticed
 that the expose_event is no longer supported, instead there is a
 draw signal. I was just wondering, the expose_event always came with
 a GdkEventExpose* attached which did in particular contain the rectangle
 which was invalidated. Is it possible to obtain the invalidated
 rectangle inside the draw handler or is it necessary to repaint the
 entire widget? (I could not find a suitable function in the gtk3/gdk3
 documentation so far)

 ax487
 ___
 gtk-list mailing list
 gtk-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-list




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: cursor icon hotspots with PNG

2014-07-15 Thread Jasper St. Pierre

Why not provide the hotspot information as a separate, editable file? That
means that people don't have to go poking through some obscure PNG chunks
to find and edit data they're looking for.


On Tue, Jul 15, 2014 at 2:09 AM, John Emmas j...@creativepost.co.uk wrote:

 On 14/07/2014 13:35, Paul Davis wrote:

 does anyone know of any good (i.e. non-hacky) ways to define/provide
 cursor icon hotspots with PNG files, the way one can with various other
 image formats more intended for this purpose?


 Hi Paul,

 I'm not massively familiar with PNG but according to its spec, the
 ancillary chunk contains a couple of 'text' fields which can be used for
 storing name/value pairs.  It would essentially be private data of course
 (i.e. non-portable) but would that help you at all?  (if the data isn't
 present you simply assume 0,0 as the hotspot).

 According to Wikipedia there have been several extensions to the original
 PNG format but AFAICT none of them seem to offer this, which is quite
 weird...

 John

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




-- 
  Jasper
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

Hey everyone again

I wasn't expecting this much fallout from the change. I was hoping most of
the GTK+ applications were only using widgets and draw signals. I was wrong.

I've effectively pushed a revert of these changes:

https://git.gnome.org/browse/gtk+/commit/?id=984e811c16891cb4945a090bea8ec9e81ce3dba6
https://git.gnome.org/browse/gtk+/commit/?id=24b9e91f470d2f355c6e19013f302295151baacf

Note that gtk_widget_set_double_buffered is still deprecated, and calling
gdk_cairo_create outside of a begin_paint_region / end_paint is still
considered legacy and isn't guaranteed to work on any backends other than
X11. Everything should be functioning correctly. So, we're choosing to make
these things work for X11, but new backends like Wayland, Broadway and Mir
might not work with them.

If your application still has flickering or prints runtime warnings or
crashes, *please* let me know. We should be back to where we were
beforehand, but things do sometimes slip through the cracks.

Thanks to everyone who gave me feedback -- it's been a frustrating past few
days for everyone, and I'm sorry for the breakage I caused. I have a much
better handle on the situation now and the way applications are using our
toolkit.

If you have any other feedback about modern drawing in GTK+, please let us
know. We're always trying to support application developers, even if it may
not seem like it, and if our existing APIs aren't suiting your use cases,
we need to know.


On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

 To better support Wayland with fewer copies and less drawing artifacts,
 I've pushed some potentially breaking changes to GDK, namely around
 gdk_cairo_create and gdk_window_begin_paint_region.


 https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848

 https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e

 With these changes, it is now illegal to call gdk_cairo_create outside of
 a begin_paint / end_paint. This was always sketchy, and would never work on
 Wayland anyway. If your code does this, we will print a warning and return
 a dummy surface which won't ever be composited back into the main surface.

 Additionally, it is now forbidden to call gdk_window_begin_paint_region
 more than once. Previously, the code had a paint stack which tracked
 paints, but since GTK+ never used this codepath it was never actually
 tested and was indeed broken on Wayland due to the way the Wayland backend
 was written. Again, we will print a warning in this case and return.

 As part of these changes, gtk_widget_set_double_buffered was deprecated
 and removed. Again, it will never work on Wayland, as that is natively
 double-buffered, and it would simply break there.

 I tested with some local big applications like Ardour and the GNOME
 applications, but don't have a GTK+3 build of Firefox, LibreOffice,
 Eclipse, or any big GTK+ apps like Inkscape or The GIMP.

 Please double-check to make sure your apps still work fine. If you have a
 problem with any of this or I broke your apps by accident, please reply and
 I'll try to fix it.

 Thanks!

 --
   Jasper




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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

Sure, I'm not familiar with the Win32 or Quartz backends, so I didn't want
to say anything too definitive about those backends. But it's nice to hear
that it works as well.


On Mon, Jun 23, 2014 at 6:39 PM, Morten Welinder mort...@gnome.org wrote:

 For the record, the use of gdk_cairo_create outside of a
 begin_paint_region / end_paint pair also seems to work fine on win32.

 Morten


 On Mon, Jun 23, 2014 at 6:02 PM, Jasper St. Pierre
 jstpie...@mecheye.net wrote:
  Hey everyone again
 
  I wasn't expecting this much fallout from the change. I was hoping most
 of
  the GTK+ applications were only using widgets and draw signals. I was
 wrong.
 
  I've effectively pushed a revert of these changes:
 
 
 https://git.gnome.org/browse/gtk+/commit/?id=984e811c16891cb4945a090bea8ec9e81ce3dba6
 
 https://git.gnome.org/browse/gtk+/commit/?id=24b9e91f470d2f355c6e19013f302295151baacf
 
  Note that gtk_widget_set_double_buffered is still deprecated, and calling
  gdk_cairo_create outside of a begin_paint_region / end_paint is still
  considered legacy and isn't guaranteed to work on any backends other than
  X11. Everything should be functioning correctly. So, we're choosing to
 make
  these things work for X11, but new backends like Wayland, Broadway and
 Mir
  might not work with them.
 
  If your application still has flickering or prints runtime warnings or
  crashes, *please* let me know. We should be back to where we were
  beforehand, but things do sometimes slip through the cracks.
 
  Thanks to everyone who gave me feedback -- it's been a frustrating past
 few
  days for everyone, and I'm sorry for the breakage I caused. I have a much
  better handle on the situation now and the way applications are using our
  toolkit.
 
  If you have any other feedback about modern drawing in GTK+, please let
 us
  know. We're always trying to support application developers, even if it
 may
  not seem like it, and if our existing APIs aren't suiting your use
 cases, we
  need to know.
 
 
  On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre 
 jstpie...@mecheye.net
  wrote:
 
  To better support Wayland with fewer copies and less drawing artifacts,
  I've pushed some potentially breaking changes to GDK, namely around
  gdk_cairo_create and gdk_window_begin_paint_region.
 
 
 
 https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848
 
 
 https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e
 
  With these changes, it is now illegal to call gdk_cairo_create outside
 of
  a begin_paint / end_paint. This was always sketchy, and would never
 work on
  Wayland anyway. If your code does this, we will print a warning and
 return a
  dummy surface which won't ever be composited back into the main surface.
 
  Additionally, it is now forbidden to call gdk_window_begin_paint_region
  more than once. Previously, the code had a paint stack which tracked
  paints, but since GTK+ never used this codepath it was never actually
 tested
  and was indeed broken on Wayland due to the way the Wayland backend was
  written. Again, we will print a warning in this case and return.
 
  As part of these changes, gtk_widget_set_double_buffered was deprecated
  and removed. Again, it will never work on Wayland, as that is natively
  double-buffered, and it would simply break there.
 
  I tested with some local big applications like Ardour and the GNOME
  applications, but don't have a GTK+3 build of Firefox, LibreOffice,
 Eclipse,
  or any big GTK+ apps like Inkscape or The GIMP.
 
  Please double-check to make sure your apps still work fine. If you have
 a
  problem with any of this or I broke your apps by accident, please reply
 and
  I'll try to fix it.
 
  Thanks!
 
  --
Jasper
 
 
 
 
  --
Jasper
 
  ___
  gtk-devel-list mailing list
  gtk-devel-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-devel-list
 




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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

I can't reproduce any issue in scrolling with evince locally -- does it
only happen with certain documents? Can you point to a document where you
have problems?

I also just built Scintilla and SCiTE from source, but they both appear to
be using GTK+ 2, not GTK+ 3. Are you using some unofficial fork or port, or
did I do something wrong when building Scintilla/SCiTE?


On Mon, Jun 23, 2014 at 7:45 PM, Colomban Wendling 
lists@herbesfolles.org wrote:

 Le 24/06/2014 00:02, Jasper St. Pierre a écrit :
  Hey everyone again
 
  [...]
 
  I've effectively pushed a revert of these changes:
 
 
 https://git.gnome.org/browse/gtk+/commit/?id=984e811c16891cb4945a090bea8ec9e81ce3dba6
 
 https://git.gnome.org/browse/gtk+/commit/?id=24b9e91f470d2f355c6e19013f302295151baacf
 
  [...]
 
  If your application still has flickering or prints runtime warnings or
  crashes, *please* let me know. We should be back to where we were
  beforehand, but things do sometimes slip through the cracks.

 Sorry, but apparently 984e811c16891cb4945a090bea8ec9e81ce3dba6 (result
 of a bisect) breaks badly in some situation.  With it, if I scroll
 aggressively in some apps (at least Evince and SciTE) I can get the X
 server to start consuming extreme CPU (even after the scroll ended).

 Not only the application gets extremely slugish, but other apps too,
 e.g. scrolling a terminal is equally slow and consumes resources, as
 well as drawing other apps.

 However, as soon as I close the initial app, everything comes back to
 normal.

 I don't know really how to debug this, but tell me if I can do anything.

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




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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

May I ask why you can't paint in the draw signal? GDK already tracks
invalidated windows marked by exposes and gdk_window_invalidate_rect
itself. It should be as efficient as drawing in an idle handler, and also
cooperates with the paint clock, where we can be synchronized to a
compositor's redraw cycle.


On Mon, Jun 23, 2014 at 8:53 PM, Krzysztof Kosiński tweenk...@gmail.com
wrote:

 2014-06-21 3:00 GMT+02:00 Jasper St. Pierre jstpie...@mecheye.net:
  To better support Wayland with fewer copies and less drawing artifacts,
 I've
  pushed some potentially breaking changes to GDK, namely around
  gdk_cairo_create and gdk_window_begin_paint_region.
 
 
 https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848
 
 https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e
 
  With these changes, it is now illegal to call gdk_cairo_create outside
 of a
  begin_paint / end_paint. This was always sketchy, and would never work on
  Wayland anyway. If your code does this, we will print a warning and
 return a
  dummy surface which won't ever be composited back into the main surface.

 This will also break the GTK 3 version of Inkscape, which paints its
 canvas in an idle handler, and the draw signal only marks areas for
 redraw. However, it may be fixable by using the begin_paint APIs.

 Regards, Krzysztof




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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

Thanks, I managed to reproduce the issue with this. It only happens with
thumbnails visible, though, which suggests that evince is doing something
funny for the thumbnails view. I'll also check out Scintilla later.

On Mon, Jun 23, 2014 at 8:19 PM, Colomban Wendling 
lists@herbesfolles.org wrote:

 Le 24/06/2014 02:03, Jasper St. Pierre a écrit :
  I can't reproduce any issue in scrolling with evince locally -- does it
  only happen with certain documents? Can you point to a document where
  you have problems?

 I doubt it's document-related, as it worked with the first three PDFs
 I tried with.  Anyway, I can reproduce with e.g.
 http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf   Note however
 that you have to scroll *aggressively*, meaning I'm was assaulting my
 mouse wheel for several seconds, or take the scrollbar grip and shake it
 quick.  Also it's less directly visible with Evince itself which seems
 to have a very cheap scroll draw (yet you probably notice something),
 but other apps gets slow-slow (for example gedit's gear menu takes like
 5s to open).

 I also just tried to enable Metacity's compositing as I was using it
 without, and I can reproduce with and without compositing.

  I also just built Scintilla and SCiTE from source, but they both appear
  to be using GTK+ 2, not GTK+ 3. Are you using some unofficial fork or
  port, or did I do something wrong when building Scintilla/SCiTE?

 you need to set the GTK3 make variable to 1:

 $ cd gtk
 $ make GTK3=1

 Regards,
 Colomban


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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

Great eye! Pushed, thanks! I'm sure that's what it was.


On Mon, Jun 23, 2014 at 9:41 PM, Colomban Wendling 
lists@herbesfolles.org wrote:

 Le 24/06/2014 03:03, Jasper St. Pierre a écrit :
  Thanks, I managed to reproduce the issue with this. It only happens with
  thumbnails visible, though, which suggests that evince is doing
  something funny for the thumbnails view. I'll also check out Scintilla
  later.

 OK, it's fairly obvious after looking at the diff: there's a missing
 cairo_surface_destroy() in the new version of gdk_cairo_create(), hence
 the surface will probably be leaked and God knows what happens on the
 server side.  Patch attached.

 Regards,
 Colomban




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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

You can draw to a pixbuf or cairo image surface from another thread or in
an idle handler, and then paint it to your window in the draw handler.
That's probably the best idea, actually. This is what things like the new
GtkListBox do -- cache the pixels in a pixel cache, and use that to draw to
your window, synchronized with the paint clock.


On Mon, Jun 23, 2014 at 9:57 PM, Krzysztof Kosiński tweenk...@gmail.com
wrote:

 2014-06-24 3:02 GMT+02:00 Jasper St. Pierre jstpie...@mecheye.net:
  May I ask why you can't paint in the draw signal? GDK already tracks
  invalidated windows marked by exposes and gdk_window_invalidate_rect
 itself.
  It should be as efficient as drawing in an idle handler, and also
 cooperates
  with the paint clock, where we can be synchronized to a compositor's
 redraw
  cycle.

 If all drawing happens in the draw signal and the document has a lot
 of demanding effects, e.g. SVG filters, it would completely kill
 responsiveness of the UI. The idle handler solution also allows us
 easily move drawing to a separate thread in the near future.

 In general, the document displayed in Inkscape cannot be drawn in one
 piece; it must be rendered as a series of strips that are shown on the
 screen once they are ready. Otherwise it takes far too long.

 Although I heavily rewrote the lower levels of Inkscape canvas (those
 dealing with SVG objects) to use Cairo and generally cleaned it up,
 the upper levels, dealing with editing controls and scheduling the
 rendering, are still barely changed from the Sodipodi days. It is
 certainly possible to do all drawing in a draw signal, for example by
 submitting an invalidate request once a piece of the drawing has
 finished rendering, but it will require a nontrivial amount of work.

 Regards, Krzysztof




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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

Can you two explain exactly what Abiword and Gnumeric are doing, what APIs
they're using and why and so on? We're trying to come up with a solution
that will work well under both X11 and Wayland.

As I said, if it's a really bad break and would require intensive changes
to apps, I'll revert the patches. This is exactly why I sent out the mail.

On Sat, Jun 21, 2014 at 9:18 AM, Jean Brefort jean.bref...@normalesup.org
wrote:

 This will break abiword as well.

 Jean

 Le samedi 21 juin 2014 à 08:02 -0400, Morten Welinder a écrit :
  Argh!
 
  Will the stream of ABI changes never end?
 
  Gnumeric uses this to provide a walking-ant cursor large selected areas
 -- areas
  too big for processing in the normal paint loop.
 
  Morten


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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

Yes, that should work. Make sure to test it, though, as begin_paint_rect /
begin_paint_region currently clears the specified rect/region to the
background set on the GdkWindow. If passing a more exact region is too much
of an annoyance, I should be able to also change this without breaking too
much so that the clear to background only happens on expose events.

It's difficult to balance the requirements of everybody.


On Sat, Jun 21, 2014 at 9:44 AM, Jean Brefort jean.bref...@normalesup.org
wrote:

 Both abiword and gnumeric do something like:

 cr = gdk_cairo_create(win);
 ...do some drawing
 then relase the cairo.

 Will this still work if we use

 gdk_window_begin_paint_rect (win, rect);
 cr = gdk_cairo_create (win);
 ...do some drawing
 gdk_window_end_paint (win);

 ?



 Le samedi 21 juin 2014 à 09:33 -0400, Jasper St. Pierre a écrit :
  Can you two explain exactly what Abiword and Gnumeric are doing, what
  APIs they're using and why and so on? We're trying to come up with a
  solution that will work well under both X11 and Wayland.
 
  As I said, if it's a really bad break and would require intensive
  changes to apps, I'll revert the patches. This is exactly why I sent
  out the mail.
 
 
  On Sat, Jun 21, 2014 at 9:18 AM, Jean Brefort
  jean.bref...@normalesup.org wrote:
  This will break abiword as well.
 
  Jean
 
  Le samedi 21 juin 2014 à 08:02 -0400, Morten Welinder a
  écrit :
   Argh!
  
   Will the stream of ABI changes never end?
  
   Gnumeric uses this to provide a walking-ant cursor large
  selected areas -- areas
   too big for processing in the normal paint loop.
  
   Morten
 
 
  --
Jasper
 





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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

Honest question: which ones? The only requirement we have with Wayland is
that we know when a paint has begun and when it has ended, and also the
rough area of paint, so we can tell the Wayland compositor when to swap
buffers, and from which rectangles.

The draw signal does this automatically, but we can expose this in other
places.

I'm skeptical of the performance concerns of the draw signal. With the new
paint clock system we have, draw events are throttled and locked to the
compositor, so it should be faster to queue a redraw and wait until the
frame is drawn, and do it all in one go. But I'm fine with changing
begin_paint_region so that it no longer clears to background, if only to
help people trying to port to the crazy new drawing world.


On Sat, Jun 21, 2014 at 10:05 AM, Paul Davis p...@linuxaudiosystems.com
wrote:




 On Sat, Jun 21, 2014 at 10:02 AM, Jean Brefort 
 jean.bref...@normalesup.org wrote:


  you're drawing on the window outside of an expose/draw event?

 Yes, because using draw events presents serious performance issues.


 can you describe these or point to a description of them? there are
 several native window(ing) systems where this is actually impossible to
 do.




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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

On Sat, Jun 21, 2014 at 11:18 AM, Jean Brefort jean.bref...@normalesup.org
wrote:

 I know that an expose event contains a region, but this does not help,
 we use the draw event, and I don't know how to reliably access the
 region. More, it is not really easy to determine what needs to be
 redrawn from inside a draw event.


The cairo context you get in the draw signal is clipped to the expose
region by default, which means that cairo will do culling for you
automatically. If you need to do extra processing to determine if some
complex update method should be run based on the clip region (which is
really a big edge case -- you shouldn't need to do this!), you can use
cairo_in_clip or cairo_clip_extents.

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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

On Sat, Jun 21, 2014 at 10:26 AM, Jasper St. Pierre jstpie...@mecheye.net
wrote:

 Honest question: which ones? The only requirement we have with Wayland is
 that we know when a paint has begun and when it has ended, and also the
 rough area of paint, so we can tell the Wayland compositor when to swap
 buffers, and from which rectangles.

 The draw signal does this automatically, but we can expose this in other
 places.

 I'm skeptical of the performance concerns of the draw signal. With the new
 paint clock system we have, draw events are throttled and locked to the
 compositor, so it should be faster to queue a redraw and wait until the
 frame is drawn, and do it all in one go. But I'm fine with changing
 begin_paint_region so that it no longer clears to background, if only to
 help people trying to port to the crazy new drawing world.


Heads-up: I went ahead and pushed a branch for this at
https://git.gnome.org/browse/gtk+/log/?h=wip/paint-stack-cleanup

Basically, gdk_window_begin_paint_region / gdk_window_begin_paint_rect no
longer clear to the background automatically, which means you can use them
out-of-band. To clear to the background explicitly, you can use
gdk_window_paint_background.

Since it adds new API, I'm not going to push it to master until I can get
some peer review, which likely means it won't get pushed until Monday. If
you could test with this branch and let me know the results, that would be
great!

I do encourage everyone to try using the draw event / draw signal
again. With our recent paint clock and event throttling work from 3.8
onwards, we should be able to make it fast without having to resort to
hacks like gdk_cairo_create.

Sorry for all the breakage! I really don't want to bug anybody too much,
but I do want to make sure that our toolkit and all our applications can
work out of the box on modern platforms like Wayland.

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

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed