e directly, and I have to answer: "sorry -
> I'm just a user as well" ). If throwing money at the problem works, we
> might be able to arrange that, maybe via a crowdfunding page, or something
> less formal. Would it be worth it to you or Redhat?
>
> Dan
>
> On Fri, Dec
On Wed, 2017-05-17 at 17:45 +0200, Carlos Garnacho wrote:
> Hej hej,
>
> On Wed, May 17, 2017 at 3:27 PM, Alexander Larsson <al...@redhat.com>
> wrote:
> > On Wed, 2017-05-17 at 01:04 +0200, Carlos Garnacho wrote:
> > > Hey,
> > >
> > &g
ubwindow
without pass through, so you can get events on a subset of a window.
And in that cases you would get the in-between related events such as
the pointer enter/leave events on its way to the destination window.
In general, pass-through is related to a particular window, not the
entire sub-hierarchy. Thi
dget ever need to do anything on map?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a one-legged day-dreaming farmboy who hides his scarred face behind
a mask. She's a
we just drop these events?
[1] https://jsfiddle.net/mp1u3ncy/
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's
On tor, 2016-12-15 at 13:15 -0500, Owen Taylor wrote:
> On Thu, 2016-12-15 at 16:26 +0100, Alexander Larsson wrote:
> >
> > This combined with the fact that OpenGL makes it very hard,
> > flickerly
> > and generally poorly supported to do damage-style partial updates
can still cull everything whose clip rect doesn't intersect the (gsk)
> clip.
True, but we must have *a* clip which we know of a-priore, it can't be
unbounded.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson
a
texture. (Althogh maybe we can special-case very simple cases like a
transformed textured quad.)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexand
oint broadway becomes a problem to keep working
we're going to drop. I don't really forsee this happening at the
moment, but there are no guarantees.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson
n32 embedding working? I'm
not as sure about that part.
>
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a hate-fuelled crooked messiah who must take medicati
So, I had a quick look at the gsk-render branch. I don't really have
much time for an in depth review, but here are some issues i saw:
The first one is a detail in the gl renderer. As opposed to a regular
3d engine we will mostly be drawing things with z=0, with a lot of
overdraw. So, we have to
of your particular problem I can still make a guess. It
is likely that your more complicated apps (like eclipse) is trying to
do something that is specific to the X11 backend, without actually
verifying that the active backend is X11 (or verifying and bailing
out).
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
On Fri, 2015-06-26 at 20:50 -0700, Jasper St. Pierre wrote:
Yeah, we've all been sort of aware of this for some time. I've abused
it to the fact where I know that malloc and g_new / free and g_free
will *always* be the same since a specific glib version.
I think removing all the code is
So, I just tried to use the memory profiler in glib, and I crashes
really early because the gobject constructor (gobject_init_ctor) calls
g_malloc before main() is reached.
This means g_mem_set_vtable() is impossible to use. I don't necessarily
think this is all that bad. Honestly we should never
?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a scarfaced guerilla astronaut moving from town to town, helping
folk in trouble. She's a virginal hip-hop angel from the wrong side
some ideas to improve some parts of the code
once xp is dropped
Sounds like its time to drop it then!
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.com
that this is true already, I've not done any Win32 work
recently. If so, just drop it.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
On ons, 2015-04-01 at 13:31 +0100, Emmanuele Bassi wrote:
Hi;
On 1 April 2015 at 13:26, Alexander Larsson al...@redhat.com wrote:
On ons, 2015-04-01 at 14:24 +0200, Emmanuel Briot wrote:
Just for reference, we've already had this discussion various times:
https://mail.gnome.org
.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a benighted neurotic card sharp with a mysterious suitcase
handcuffed to his arm. She's a sarcastic
+ on XP.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's an all-American Jewish barbarian who dotes on his loving old ma
On ons, 2015-04-01 at 16:48 +0300, Mart Raudsepp wrote:
On K, 2015-04-01 at 14:33 +0200, Alexander Larsson wrote:
On ons, 2015-04-01 at 13:31 +0100, Emmanuele Bassi wrote:
Hi;
On 1 April 2015 at 13:26, Alexander Larsson al...@redhat.com wrote:
On ons, 2015-04-01 at 14:24 +0200
O_CLOEXEC is a nice thing to do, but doing so does
not change the fundamental fact that you can't rely on it being set.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al
On tis, 2015-03-31 at 09:48 +0200, Alexander Larsson wrote:
On lör, 2015-03-21 at 20:57 -0400, Ryan Lortie wrote:
hi,
On Sat, Mar 21, 2015, at 01:59, Jürg Billeter wrote:
I would keep using O_CLOEXEC as it's as close as we can get to the
behavior that should have been the default
).
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander LarssonRed Hat, Inc
al...@redhat.comalexander.lars...@gmail.com
He's a short-sighted coffee-fuelled cowboy with a secret. She's a blind
French-Canadian cab driver on the trail
On Thu, 2015-01-15 at 10:49 -0500, Morten Welinder wrote:
My plan is to make it a guarantee of the API that both CREATED
and CHANGED events will always be followed by a CHANGES_DONE
hint.
Great plan, but you cannot get that in a meaningful way. Think
creat
write
mmap
On sön, 2014-10-12 at 18:47 -0400, Owen Taylor wrote:
Performance on my system is actually quite poor in at the moment, which
seems at least to be pathological interactions with the system
(i915, Fedora 21, Haswell.) I see 60fps with the default configuration
of gdkgears for any windowed size
On sön, 2014-10-12 at 18:47 -0400, Owen Taylor wrote:
* It looks like there's a need to create a GdkGLContext for a window
*before* the paint callback it is first used, since we use the existence
of the internal paint GL context to know whether we are using GL for
this paint; this is not
On mån, 2014-08-18 at 18:09 +0200, Sébastien Wilmet wrote:
On Mon, 2014-08-18 at 10:01 -0400, Jasper St. Pierre wrote:
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
On mån, 2014-03-10 at 23:06 +0100, Stefan Sauer wrote:
On 03/10/2014 09:07 PM, Alexander Larsson wrote:
On mån, 2014-03-10 at 15:14 +0100, Stefan Sauer wrote:
hi,
I wanted to see the broadway backend in action. Using gtk+3.8 I run
broadwayd --address=ipaddr --port=8080 :5
On tis, 2014-03-11 at 13:52 +0100, Stefan Sauer wrote:
Okay, so I should not see these warnings? So the websocket connection is
from the client to the server on the same port?
Any ideas how I can narrow down whats the issue? Otherwise I'll need to
build things from source and sprinkle
On mån, 2014-03-10 at 15:14 +0100, Stefan Sauer wrote:
hi,
I wanted to see the broadway backend in action. Using gtk+3.8 I run
broadwayd --address=ipaddr --port=8080 :5
and
This has 8080
BROADWAY_DISPLAY=:5 GDK_BACKEND=broadway ./my-gtk3-app
On the browser side, all I get is a blank
On ons, 2013-10-23 at 13:16 +0200, Alberto Ruiz wrote:
Hey Alex,
I've been playing with this idea myself, have a look at this github
repo[0], don't pay too much attention to the ListView widget, I'm
pretty much replicating Gtk.ListBox for the sake of understanding how
to implement such
More and more gnome apps are migrating to GtkListBox rather than
GtkTreeView for lists, and we now have GtkFlowBox that replaces
GtkIconView. These are nice for smaller lists, but with larger lists
they are a bit heavy. We may want to look at optimizing whatever is
possible, but at some point it
On mån, 2013-10-21 at 10:34 -0400, Ryan Lortie wrote:
hi,
GLib aims to work on a wide range of operating systems, but we have no
good story for ensuring that this is the case. Mostly we do things for
Linux and, if they are the sort of thing that may cause problems, we
also check that they
On sön, 2013-09-29 at 22:28 -0400, Matthias Clasen wrote:
I've pushed a flowbox branch, which adds a GtkFlowBox widget. It is a
copy of the EggFlowBox widget that has been developed in the
egg-list-box module for a while, which is in turn based on an earlier
EggSpreadTable in libegg.
I
- Original Message -
On Wed, Jul 03, 2013 at 03:40:56PM +0200, Alexander Larsson wrote:
I just merged the wip/window-scales2 branch. This means that gtk+ master
has some level of support for window scaling.
If you want to test this, you will still need the cairo branch
I just merged the wip/window-scales2 branch. This means that gtk+ master
has some level of support for window scaling.
If you want to test this, you will still need the cairo branch at:
http://cgit.freedesktop.org/~ickle/cairo/log/?h=device-scale
(It still builds without it, but doesn't support
So, I just landed GtkListBox in Gtk+ master. Its essentially a slightly
evolved version of EggListBox. One of the main differences compared to
EggListBox is that it has a specific row widget GtkListBoxRow which is
the only thing that can be a child of a GtkListBox (well, if you add
anything else
On tor, 2013-05-16 at 18:08 +0200, Carlos Garnacho wrote:
First of all, I'm aware this partially collides with Alex's work[1], but
on this branch the backing surface scale details have just been sorted
out for the Quartz backend, so the meat in this branch can still greatly
benefit from his
On fre, 2013-05-03 at 21:59 -0400, Matthias Clasen wrote:
On Thu, May 2, 2013 at 2:40 PM, Alexander Larsson al...@redhat.com wrote:
I've tried a bunch of apps and most things seem to work. Currently I
know of two problems:
I've gone through gtk3-demo and our other test programs
On fre, 2013-05-03 at 21:59 -0400, Matthias Clasen wrote:
On Thu, May 2, 2013 at 2:40 PM, Alexander Larsson al...@redhat.com wrote:
I've tried a bunch of apps and most things seem to work. Currently I
know of two problems:
I've gone through gtk3-demo and our other test programs
I just merged the wip/simple-draw4 branch with master. It seems to work
pretty well now. Open issues i know of:
Anything using GdStack to do crossfades will show some weird coloring
during the fade, these apps should upgrade to the latest libgd (or
ideally to GtkStack).
The gnome-cc background
On fre, 2013-05-03 at 00:03 +0200, Søren Sandmann wrote:
Alexander Larsson al...@redhat.com writes:
* Try a tile-based approach for GtkPixelCache to avoid having
to do a same-surface copy (usign an intermediate surface) when
scrolling the cache.
An alternative to tiles is to keep
On tor, 2013-05-02 at 18:20 -0400, Paul Davis wrote:
On Thu, May 2, 2013 at 6:03 PM, Søren Sandmann sandm...@cs.au.dk
wrote:
Alexander Larsson al...@redhat.com writes:
* Try a tile-based approach for GtkPixelCache to avoid
having
to do
On fre, 2013-05-03 at 05:52 -0400, Paul Davis wrote:
On Fri, May 3, 2013 at 3:02 AM, Alexander Larsson al...@redhat.com
wrote:
things that are wide and tall ... well, they're on their
own ...
This is not really a problem the pixel cache
I've just pushed the wip/simple-draw4 branch which is the latest
version of my work trying to simplify and modernize the Gtk drawing
machinery. Its now in a state where I think its time to discuss the
merging of this.
The very first commit in the branch makes gdk_window_move() and
On Thu, May 2, 2013 at 2:40 PM, Alexander Larsson al...@redhat.com wrote:
. Secondly, in a more modern
scene graph like in recent gtk3 most windows have alpha pixels and
render over the window background rather than each window rendering
its own opaque background, so scrolling via copy
On tis, 2013-03-26 at 16:56 +0100, Alexander Larsson wrote:
I've done a bunch of work on the baseline stuff and rebased it into a
nice branch called wip/baseline3. Its got the core working with a bunch
of widgets converted.
I pushed some minor details that cosimo pointed out, and this solution
I've done a bunch of work on the baseline stuff and rebased it into a
nice branch called wip/baseline3. Its got the core working with a bunch
of widgets converted.
The only interesting widget that lacks baseline support (imho) is
GtkComboBox. But that one is hard due to it using GtkCellArea co.
I just pushed the wip/baseline branch to git. It contains the initial
steps towards adding baseline alignment in gtk+, by extending the
size request and size allocation framework with:
* A way to report a baselines corresponding to the minimum and
natural heights
* A way to allocate the baseline
On ons, 2013-02-27 at 17:47 +0900, Tristan wrote:
Ah, I think I understand your question better now.
Use a natural allocation process similar to
gtk_distribute_natural_allocation():
http://git.gnome.org/browse/gtk+/tree/gtk/gtksizerequest.c#n599
Instead of looping over widget size
On ons, 2013-02-27 at 21:22 +0900, Tristan Van Berkom wrote:
How do we assign 5 pixels above the baseline based on this? All we can
do is give the child more total height (via gtk_widget_size_allocate),
we have in general no control of where that height will go. The child
might be
One of the main layout features we're badly missing atm is baseline
alignment. I spent some time looking at this recently but I bumped
into some problems. I'd like to bring this up for discussion in the
hope that we might figure out a solution to my problems.
First, let me define what i mean by
On tis, 2013-02-26 at 10:58 -0500, Matthias Clasen wrote:
On Tue, Feb 26, 2013 at 9:30 AM, Alexander Larsson al...@redhat.com wrote:
Ideas wanted...
I think you basically have to split the height that is returned for
minimal or natural size into an overlength/underlength pair. Then you
On ons, 2013-02-27 at 01:18 +0900, Tristan wrote:
My thoughts are that, when performing get_preferred_height_for_width(),
you need some virtual allocation logic like such that is found in
gtkbox.c (when we are requesting in the 'uncomfortable/opposing'
orientation):
a.) Calculate how
On fre, 2013-02-15 at 22:48 -0500, Owen Taylor wrote:
On Fri, 2013-02-15 at 09:21 +0100, Alexander Larsson wrote:
In terms of using timeBeginPeriod() and timeEndPeriod(), unfortunately,
the GDK level API has no concept of a running animation, so it's not
clear when GDK would set up
On fre, 2013-02-15 at 09:21 +0100, Alexander Larsson wrote:
On tor, 2013-02-14 at 16:18 -0500, Owen Taylor wrote:
On Thu, 2013-02-14 at 15:35 -0500, Alexander Larsson wrote:
I did a bunch of research on this, see the g_get_monitonic_time() win32
implementation for it. I definately don't
Some more feedback:
Cut and paste doc bug:
* @GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS: corresponds to
GdkFrameClock::flush-events. Should not be handled by applications.
* @GDK_FRAME_CLOCK_PHASE_BEFORE_PAINT: corresponds to
GdkFrameClock::flush-events. Should not be handled by applications.
The
Did you try this on win32? The default timer resolution there is
~16msec which
is about the 60Hz frame rate, which seems like it can cause some
framerate
instability. Its possible to temporarily raise this resolution by
calling
timeBeginPeriod() although its frowned upon to always
On tis, 2013-01-08 at 12:21 -0800, Andy Tai wrote:
Hi, with gtk+ 3, is touch input supported with the HTML 5 backend,
such as when running a gtk+ app on HTML 5 in the browser?
Not currently, but it could be implemented.
___
gtk-devel-list mailing
On ons, 2012-12-12 at 19:01 +0100, Giovanni Campagna wrote:
The second option is to share just code, in some form, either as a
private shared library that would be provided by Gtk
(libgtk-internal?) and developed by both teams, or just as a copy-lib,
with a massive s/Gtk/St/. I'm not sure what
On mån, 2012-12-03 at 10:06 +0100, Jean Parpaillon wrote:
Hi all,
I've been trying gtk broadway backend and found it very interesting,
even if it still lack some features to be completly usable in the real
life :)
Is there a roadmap for it ? Was it just a proof-of-concept, or is there
On ons, 2012-10-24 at 11:34 +0530, Mohan R wrote:
On Tue, 2012-10-23 at 19:43 +0100, Emmanuele Bassi wrote:
hi;
don't use the G namespace for you code unless you plan on submitting
it for inclusion in GLib.
If you're writing a gtweet library, then the namespace ought to be
On tor, 2012-10-04 at 15:46 -0400, Owen Taylor wrote:
On Thu, 2012-10-04 at 08:09 -0400, Alexander Larsson wrote:
Are you sure that is really a problem? The x11 gdk_event_source_check()
code will never even look for a message if there is any GdkEvent queued.
And if there is nothing queued
Some open questions in my head about the frame synchronization work:
* Is GdkPaintClock the right name? It might imply that it only has to
do about painting and not about other things like layout.
GdkFrameClock would be an alternative. GdkClock is possible but
likely too generic.
I
? Implement paint throttling for the Broadway backend.
(I'm not sure what this means exactly - the default
throttling to 60fps may be OK.)
Not sure what the best thing is here. If you have a low
bandwidth connection then you would like to do a roundtrip
to the client before sending the
Not a lot of serious feedback here, but I also worry about the
implicitness about this API. Its really not well defined what it does,
and the fact that it may change over time as functions are implemented
differently or new things support reversible just seems scary.
On Tue, 2012-06-12 at 14:40 +, avijit.ma...@wipro.com wrote:
Hi,
On further debugging I could see the below behaviour:
1. _gdk_pixbuf_get_module receives the buffer header as:89PNG
2. But when it fetch the mime_type on that buffer it is getting
mime_type:application/octet-stream
On Wed, 2012-06-13 at 10:16 +, avijit.ma...@wipro.com wrote:
Do I need to export any variable also?
XDG_DATA_DIRS=$WLD/share:/usr/share
You probably also want XDG_CONFIG_DIRS, and obviously things like
LD_LIBRARY_PATH and PATH.
___
gtk-devel-list
On Thu, 2012-05-24 at 22:21 -0400, Colin Walters wrote:
On Mon, 2012-05-21 at 06:54 -0400, Russell Harmon wrote:
I'm looking to implement two things which I think would be quite
useful if included in glib.
- Ropes [1]
The basic rule is - something might go in GLib if used by 2
- Original Message -
On Tue, 03 Apr 2012 23:35:46 -0400
Colin Walters walt...@verbum.org wrote:
On Wed, 2011-11-16 at 21:05 +0100, Mikkel Kamstrup Erlandsen wrote:
Hi all,
I have been looking at gcc's cleanup attribute[1] that allows
one
to specify a callback that
gcc's constructor and destructor attributes as I understand them are
principally used in connection with the loading and unloading of
shared libraries at program start-up and close down, although I
imagine they have other uses. If you say those may require OS
support I
will believe you
On Wed, 2012-03-28 at 14:32 +0200, Maciej Marcin Piechotka wrote:
Hello,
During discussion on bug #659781[1] a user stated that he cannot use
GDataInputStream as it does not support seeks. After quick look it seems
that adding support for it is relatively easy - the basic patch for
I just landed a bunch of signal emission optimizations in gobject. It
should be transparent to everyone, although it you're using an
non-standard signal marshaller for a heavily used signal you might want
to look at setting a custom va_marshaller.
The basic idea is that for a the (common) case of
On Thu, 2012-01-19 at 11:47 +0800, jun louis wrote:
I found this BUG:
I directly run gtk-demo.exe on win7 x64, use locale=zh_CN, texts
disappear when switch page.
I use msys, use LC_ALL=C then run gtk-demo, texts works fine!
$ export LC_ALL=C
$ ./gtk-demo.exe
I use msys, use
On Wed, 2012-01-18 at 11:56 -0800, Christian Hergert wrote:
On Wed, 2012-01-18 at 09:47 +0100, Alexander Larsson wrote:
On Mon, 2012-01-16 at 13:08 +, Bastien Nocera wrote:
On Fri, 2012-01-13 at 17:34 -0800, Christian Hergert wrote:
Hopefully this isn't getting old, but I'm sort
On Wed, 2012-01-11 at 20:38 -0800, Christian Hergert wrote:
VALIDATION
Many developers in the web world have become accustom to validating
the contents of forms before submitting them. While we would often argue
against allowing invalid input in the first place, that can often
confuse users.
On Wed, 2011-12-21 at 15:07 -0800, Hub Figuière wrote:
On 21/12/11 02:47 PM, Alexander Larsson wrote:
I think this could be very useful in many places, for instance to ship
built-in
css files, gtk builder files, win32 theme images etc in a way that still
makes libraries
relocatable
On Wed, 2011-12-21 at 17:47 -0500, Alexander Larsson wrote:
I just finished a one-day hackathon to add a resource framework to glib, its
somewhat working if not very polished. Its in the resources branch in glib
git.
I think this could be very useful in many places, for instance to ship
I just finished a one-day hackathon to add a resource framework to glib, its
somewhat working if not very polished. Its in the resources branch in glib
git.
I think this could be very useful in many places, for instance to ship built-in
css files, gtk builder files, win32 theme images etc in a
On Fri, 2011-12-09 at 08:47 -0500, Ryan Lortie wrote:
On Fri, 2011-12-09 at 09:50 +0100, Alexander Larsson wrote:
Windows actually has an application menu thing. If you right-click on
the application on the panel you can get app-specific operations in the
menu. I'm not sure if the normal
On Tue, 2011-11-15 at 17:49 +0100, André Gillibert wrote:
I'm not sure this mailing list is the correct place to post
GLIB-related requests, but I didn't find a glib-devel-list.
I wrote a patch for GLIB 2.28 GIO subsystem to benefit from
dirent::d_type and be as lazy as possible on
Huge memory leak while using MS-Windows theme (gtk-demo)
663605 Fix event-state of many event types on quartz
November 10, 2011
Alexander Larsson
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk
Huge memory leak while using MS-Windows theme (gtk-demo)
663605 Fix event-state of many event types on quartz
November 10, 2011
Alexander Larsson
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Sat, 2011-11-05 at 00:06 +0800, Fan Chun-wei wrote:
So, could everyone interested in the windows support test this please.
I'd like to make a 2.24 release with this stuff in it so that we have a
final Gtk2 with good win32 support. Obviously we don't want to have any
bad regressions for
The -win32 branch is now in a pretty good state and seems to be the best
Gtk 2.x version for win32 so far, so I just merged it into gtk-2-24, and
I plan to do a release later this week.
The latest code also includes a bunch of Quartz fixes, so this will end
up being a pretty sweet cross platform
On Fri, 2011-11-04 at 16:38 +0100, Maarten Bosmans wrote:
So, could everyone interested in the windows support test this please.
I'd like to make a 2.24 release with this stuff in it so that we have a
final Gtk2 with good win32 support. Obviously we don't want to have any
bad regressions
The gtk-2-24-win32 branch is now in a pretty good state. I fixed a lot
of bugs from bugzilla and stuff from dieters testing
(https://live.gnome.org/GTK%2B/Win32/test-gtk-2-24-win32). I think this
is in a state where we might want to merge it into master. I fixed most
core issues, although I didn't
On Fri, 2011-10-21 at 10:36 +0200, Kean Johnston wrote:
Can any people interested in the win32 code please try this out and
report any issues, regressions against gtk-2-24 or just things that are
broken on windows related to windows and events.
I just updated jUXtapose to your code and
On Fri, 2011-10-21 at 10:49 +0200, Arnaud Charlet wrote:
Things to test are: everything related to menu behaviour (rich in
grabs), everything involving press-and-hold-down mouse button
behaviour,
checking that the right things prelight as you move between windows and
widgets.
On Fri, 2011-10-21 at 11:53 +0200, Arnaud Charlet wrote:
See https://bugzilla.gnome.org/show_bug.cgi?id=646930 for an
example of
a regression in 2.24 wrt grabs.
I replied to this bug, it should be fixed already on the branch.
Great, thanks for having a look!
BTW, what's your
On Thu, 2011-10-20 at 01:49 +0200, Dieter Verfaillie wrote:
On Wed, 19 Oct 2011 22:53:49 +0200, Alexander Larsson wrote:
I just pushed a bunch of changes to how grabs and crossing events
work in the win32 backend to the gtk-2-24-win32 branch, and I want to
fix any other leftover bugs from
On Thu, 2011-10-20 at 08:37 +, Andy Spencer wrote:
First off, when using the MS-Windows theme, some widgets don't render
correctly and show up as black boxes. For example, notebooks with tab
position set to GTK_POS_LEFT don't render.
This is possibly something else, but i'll have a look.
On Thu, 2011-10-20 at 18:15 +0200, Kristian Rietveld wrote:
On Oct 20, 2011, at 12:03 PM, Clemens Eisserer wrote:
I hacked together a simple sample application which compiles under
gtk2 as well as gtk3: http://93.83.133.214/gtklist.c
Just maximize it (preferable on a large screen) and
I just pushed a bunch of changes to how grabs and crossing events
work in the win32 backend to the gtk-2-24-win32 branch, and I want to
fix any other leftover bugs from the client side windows conversion.
Can any people interested in the win32 code please try this out and
report any issues,
On Mon, 2011-09-26 at 08:59 +0200, Kean Johnston wrote:
There is also a broader issue with stat. The size of struct stat can vary
according to what macros are defined when you include sys/stat.h. If you
have _FILE_OFFSET_BITS=64 defined your size fields are 64-bit, otherwise
they *can* be
On Wed, 2011-09-28 at 10:00 +0200, Kean Johnston wrote:
This means that there is an awful lot of valid existing code (including
within GLib itself) that looks like this:
{
struct stat buf;
g_stat (filename,buf);
}
which (if I understand your proposal correctly) would be
On Sun, 2011-09-18 at 10:50 -0400, Ryan Lortie wrote:
hi everyone,
I've been trying to follow the GNOME 3.1 release cycle fairly closely
with GLib 2.29. For that reason, I now consider the glib-2-30 branch to
be hard code frozen. Please do not commit anything without first asking
for an
On Sun, 2011-09-18 at 13:11 -0400, Ryan Lortie wrote:
- use a __attribute__((constructor)) approach
I have a patch here to introduce this concept as a quick hack:
http://git.gnome.org/browse/glib/commit/?h=wip/mutexesid=9f29daafeb8133611a4ea24f5013ebb8bb623d73
and two uses
On Mon, 2011-09-19 at 09:54 -0400, Morten Welinder wrote:
Unfortunately this is a pragma
Will C99's _Pragma help? That can be put in a macro.
It depends. Does all old crap compilers that forces us to use pragmas to
mark constructor functions support it? My guess is no, but it might be
worth
1 - 100 of 576 matches
Mail list logo
