More patches
Hi,
here are more patches.
I could not find any related bug entry so I'm posting to the list once again.
gdk-directfb-cleanups.patch
Fixed remaining warnings, wonder why I did not see them last time.
Cleaned up a bit, e.g. removing obsolete prototypes without an
implementation
or making _gdk_directfb_draw_rectangle() static again as it's no longer
used
from outside and all other drawable methods are static, too.
gdk-directfb-copy-to-image.patch
Fixes cooperative level setting for the layer if the root window is the
one
to copy from. The exclusive level was wrong as it switches to a new
surface etc.
Usage of gdk_visual_get_system() to create the new image seemed wrong
to me to
I changed it to call gdk_drawable_get_visual() so the copy has the same
format.
Last and least, the locking afterwards only used DSLF_WRITE, but it
should have
used DSLF_READ as well, or are images specified to be write only?
gtk-add-glib-libs-to-executables.patch
This was a scary build issue. I installed glib, pango and gtk, but kept
using
my system's atk. When gtk-query-immodules-2.0 was built it failed to
link as
it missed a lot of new functions in the glib, e.g. glib_checksum_new().
I found
out that it somehow tried to link against my system's glib, though
using pkg-config
the correct new glib was returned. Not sure if it's libstuhl or just
the order
on the linker command line, but adding $(GLIB_LIBS) explicitly did the
trick.
--
Best regards,
Denis Oliver Kropp
.--.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"--"
Index: gdk/directfb/gdkdisplay-directfb.c
===
--- gdk/directfb/gdkdisplay-directfb.c (revision 19439)
+++ gdk/directfb/gdkdisplay-directfb.c (working copy)
@@ -410,9 +410,10 @@
*/
GdkGrabStatus
-gdk_directfb_keyboard_grab (GdkDisplay *display,GdkWindow *window,
-gint owner_events,
-guint32time)
+gdk_directfb_keyboard_grab (GdkDisplay *display,
+GdkWindow *window,
+gintowner_events,
+guint32 time)
{
GdkWindow *toplevel;
GdkWindowImplDirectFB *impl;
@@ -437,7 +438,8 @@
}
void
-gdk_directfb_keyboard_ungrab (GdkDisplay *display,guint32 time)
+gdk_directfb_keyboard_ungrab (GdkDisplay *display,
+ guint32 time)
{
GdkWindow *toplevel;
GdkWindowImplDirectFB *impl;
@@ -445,8 +447,7 @@
if (!_gdk_directfb_keyboard_grab_window)
return;
- toplevel =
-gdk_directfb_window_find_toplevel (_gdk_directfb_keyboard_grab_window);
+ toplevel = gdk_directfb_window_find_toplevel (_gdk_directfb_keyboard_grab_window);
impl = GDK_WINDOW_IMPL_DIRECTFB (GDK_WINDOW_OBJECT (toplevel)->impl);
if (impl->window)
@@ -477,50 +478,19 @@
*/
GdkGrabStatus
-gdk_display_keyboard_grab (GdkDisplay *display,GdkWindow *window,
- gint owner_events,
- guint32time)
+gdk_display_keyboard_grab (GdkDisplay *display,
+ GdkWindow *window,
+ gintowner_events,
+ guint32 time)
{
- GdkWindow *toplevel;
- GdkWindowImplDirectFB *impl;
-
- g_return_val_if_fail (GDK_IS_WINDOW (window), 0);
-
- if (_gdk_directfb_keyboard_grab_window)
-gdk_keyboard_ungrab (time);
-
- toplevel = gdk_directfb_window_find_toplevel (window);
- impl = GDK_WINDOW_IMPL_DIRECTFB (GDK_WINDOW_OBJECT (toplevel)->impl);
-
- if (impl->window)
-{
- if (impl->window->GrabKeyboard (impl->window) == DFB_LOCKED)
-return GDK_GRAB_ALREADY_GRABBED;
-}
-
- _gdk_directfb_keyboard_grab_window = g_object_ref (window);
- _gdk_directfb_keyboard_grab_owner_events = owner_events;
- return GDK_GRAB_SUCCESS;
+ return gdk_directfb_keyboard_grab (display, window, owner_events, time);
}
void
-gdk_display_keyboard_ungrab (GdkDisplay *display,guint32 time)
+gdk_display_keyboard_ungrab (GdkDisplay *display,
+ guint32 time)
{
- GdkWindow *toplevel;
- GdkWindowImplDirectFB *impl;
-
- if (!_gdk_directfb_keyboard_grab_window)
-return;
-
- toplevel =
-gdk_directfb_window_find_toplevel (_gdk_directfb_keyboard_grab_window);
- impl = GDK_WINDOW_IMPL_DIRECTFB (GDK_WINDOW_OBJECT (toplevel)->impl);
-
- if (impl->window)
-impl->window->UngrabKeyboard (impl->window);
-
- g_object_unref (_gdk_directfb_keyboard_grab_window);
- _gdk_directfb_keyboard_grab_window = NULL;
+ return gdk_directfb_keyboard_ungrab (display, time);
}
Index: gdk/directfb/gdkdrawable-directfb.c
=
Re: gtk.org page width
On 30/01/2008, Michael L Torrie <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Sorry to revive this again, but does anyone have a link to the > > discussion of this? My google search is failing me. > > > > It seems strange to me that GTK goes to a lot of trouble to support > > accessibility (atk and friends), but then has a homepage which breaks > > W3C accessibility guidelines. Other than this issue I really like the > > redesign, congrats to all who worked on it. > > Would not a fixed-width design meet accessibility guidelines and work on > small, mobile screens if it used a fixed width based on ems instead of > pixels? Seems to me the time of using pixels for layouts is as obsolete Yes, that's one of the solutions the W3C guidelines suggest: http://www.w3.org/WAI/WCAG20/quickref/20071211/Overview.php#qr-visual-audio-contrast-visual-presentation John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib and 64-bit Windows
On Tue, 2008-01-29 at 15:12 +0100, Tim Janik wrote:
> 2008-01-29 14:58:31 Tim Janik <[EMAIL PROTECTED]>
>
> * glib/gmem.[hc]: changed size argument type from gulong to gsize as
> discussed on gtk-devel-list:
>
> http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00062.html
> this should be ABI compatible on all platforms except win64 for which
> no ABI binding port exists yet.
>
> > There *are* platforms where gssize is an unsigned integer rather than an
> > unsigned long, but my general feeling is that just changing the gmalloc
> > prototypes is unlikely to cause problems; GMemVTable, which would be
So, changing the gmem.h prototypes actually broke compilation of
gnome-keyring. (It was passing g_realloc into a function that took a
function pointer; causing a warning, and with -Werror on, a fatal
error.)
My feeling is that this is *probably* OK (in the context of a
between-major-version releases), though if more problem start showing
up, changing the prototypes only for Win64 might be necessary.
> > more likely to cause warnings already has gsize there.
>
> i suppose you mean gsize (which is always unsigned), because gssize is
> always signed.
I'm not sure what you you are asking here. What I was saying is that
changing vtable members is more likely to break things than changing
function prototypes.
> > There are going to be other situations however, where the fix isn't so
> > obvious.
> >
> > - When 64-bit proofing the Unicode string bits of GLib (years ago)
> > I took the policy that:
> >
> >- Counts of bytes were sized as gsize
> >- Counts of "items" sized larger than a byte are longs
> >
> > because it seemed very strange to me to use size_t for non-byte
> > counts.
>
> C++ does this all the time though (also calls it's .get_number_of_elements()
> methods .size()), so you get used to it after a bit of STL fiddling.
>
> > But that means that something like the return value from
> > g_utf8_strlen() is wrong for win32. This can't be changed in a
> > source-compatible fashion.
> >
> > Probably the right thing to do for g_utf8_strlen() is to compute
> > things internally as 64-bit, then clamp the result to 32-bits
> > on return. Without the clamp:
> >
> > long size = g_utf8_strlen(str);
> > gunichar chars = g_new(gunichar, size);
> > for (char *p = str, gunichar *c = chars; *p; p = g_utf8_next_char(p)) {
> > *c = g_utf8_get_char(p);
> > }
> >
> >Is a potential buffer overflow, though a hard one to trigger.
> >(Actually, it's a potential overflow currently for 32-bits. We really
> >should make g_new0() not a g_malloc()-wrapping macro so we can protect
> >the multiplication.)
>
> if i understand you correctly, you mean to imply that we also fix the
> signatures from *long to *size as well for the following functions
> (comprehensive list of *long API in glib/glib/*.h):
>
>
> gdouble g_timer_elapsed (GTimer *timer,
>gulong *microseconds);
[...]
No, I didn't mean that, because
gdouble g_timer_elapsed (GTimer *timer,
size_t *microseconds);
gulong microseconds;
g_timer_elapsed(timer, µseconds);
Will warn in many many situations on many platforms, and MSVC will warn
about:
gsize g_utf8_strlen (const gchar *p,
gssize max);
long value = g_utf8_strlen(p, max);
even when compiling for 32 bits. So I don't consider changing out
parameters and returns from long => size_t compatible.
- Owen
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk.org page width
[EMAIL PROTECTED] wrote: > Sorry to revive this again, but does anyone have a link to the > discussion of this? My google search is failing me. > > It seems strange to me that GTK goes to a lot of trouble to support > accessibility (atk and friends), but then has a homepage which breaks > W3C accessibility guidelines. Other than this issue I really like the > redesign, congrats to all who worked on it. Would not a fixed-width design meet accessibility guidelines and work on small, mobile screens if it used a fixed width based on ems instead of pixels? Seems to me the time of using pixels for layouts is as obsolete as GTK using pixel layouts for buttons and other ui elements. Many fixed-width schemes these days actually now are in ems, so they look correct when the font size is changed or the client screen DPI is higher or lower. For example: http://www.456bereastreet.com/archive/200504/about_fluid_and_fixed_width_layouts/ > > John > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Michael Torrie Assistant CSR, System Administrator Chemistry and Biochemistry Department Brigham Young University Provo, UT 84602 +1.801.422.5771 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Patch
Sven Neumann wrote: >> Mike was asking for someone to take over the project recently, wasn't he? >> >> After seven years of more and more abandoning it, I'd be happy to have >> it back and make it something great(er) :) > > I guess you should get SVN commit access then. You have my approval for > that, but we will need someone from the core GTK+ development team to > back this. Thanks, I'd really like to commit myself :) >> Too bad noone could tell me about the simpler Quartz implementation so >> far. It seems a lot of the recursion with invalidation, clipping, lots >> of paint events etc. could be avoided. > > As far as I know the Quartz backend is not fully functional yet. Please > keep that in mind. Good to know :) Well, GTK+DirectFB is not full functional either, but probably in other or less areas. I'm mostly interested in their adaption of the rendering models, i.e. complex clipping and lots of recursion vs. simply redraw from bottom up and just keep one invalid rectangle or region per top level window. Maybe my assumptions about Quartz are wrong, but I thought it's comparable to drawing to DirectFB windows. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTKDFB Debugging Patch
Sven Neumann wrote: > Hi Dok, > > On Wed, 2008-01-30 at 03:11 +0100, Denis Oliver Kropp wrote: > >> here's another patch. >> >> It adds debug messages using DirectFB's debugging system > > I have applied this to trunk as well. Thanks a lot! -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTKDFB Debugging Patch
Hi Dok, On Wed, 2008-01-30 at 03:11 +0100, Denis Oliver Kropp wrote: > here's another patch. > > It adds debug messages using DirectFB's debugging system I have applied this to trunk as well. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Patch
Hi, On Wed, 2008-01-30 at 00:31 +0100, Denis Oliver Kropp wrote: > this is the first of more patches coming up these days. I have applied this patch to SVN on your behalf. Will look at your other patch next... > Mike was asking for someone to take over the project recently, wasn't he? > > After seven years of more and more abandoning it, I'd be happy to have > it back and make it something great(er) :) I guess you should get SVN commit access then. You have my approval for that, but we will need someone from the core GTK+ development team to back this. > Too bad noone could tell me about the simpler Quartz implementation so > far. It seems a lot of the recursion with invalidation, clipping, lots > of paint events etc. could be avoided. As far as I know the Quartz backend is not fully functional yet. Please keep that in mind. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Final Draft
On Wed, 2008-01-30 at 15:41 +, Martyn Russell wrote: > Murray Cumming wrote: > > On Mon, 2008-01-28 at 13:16 +0100, Murray Cumming wrote: > >> And I still believe that the official GNOME bindings deserve to be in > >> a > >> separate section. > > > > I see that the site is live already. Please don't just ignore this > > regression. I've mentioned it before too. > > Hi Murray, > > We are not ignoring it, it is a planned change. There are one or two and > we have had quite a few improvement requests since going live - we will > be getting to it soon. > > Currently I am contemplating: > > 1. Removing the whole table and linking to the GNOME bindings page > instead which I think jdahlin suggest to me. > > 2. Removing anything older than (including) 2.8 which is no longer > supported I think. If we do this then there is little point in having > half the languages on there since the data we have shows most are only > partially supported up to 2.4. But the data we have is probably out-of-date and will never be regularly up-to-date. If you just remove them then there's no easy way for people to find them. The original page had text about how the information is self-reported and therefore not that reliable. > Currently the bindings link is broken since it has changed since > starting the pages. I guess we should link to > > http://live.gnome.org/TwoPointTwentyone/Bindings That's really just for release management. I don't think it would be wise to make that the only list of our supported bindings. The existing page worked fairly well. > This link will have to be kept up to date, if this is the link to use, > it would be better to have a more permanent link that doesn't change > with new versions of GNOME (which we used to have). Theoretically, http://www.gnome.org/start/unstable/Bindings should do that but it doesn't seem to work for sub-pages. > 3. Putting the language bindings on a separate page (if we keep the > table of course). > > This any a bunch of other things we have had requested will be processed > in due course :) OK. Thanks. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Final Draft
Murray Cumming wrote: > On Mon, 2008-01-28 at 13:16 +0100, Murray Cumming wrote: >> And I still believe that the official GNOME bindings deserve to be in >> a >> separate section. > > I see that the site is live already. Please don't just ignore this > regression. I've mentioned it before too. Hi Murray, We are not ignoring it, it is a planned change. There are one or two and we have had quite a few improvement requests since going live - we will be getting to it soon. Currently I am contemplating: 1. Removing the whole table and linking to the GNOME bindings page instead which I think jdahlin suggest to me. 2. Removing anything older than (including) 2.8 which is no longer supported I think. If we do this then there is little point in having half the languages on there since the data we have shows most are only partially supported up to 2.4. Currently the bindings link is broken since it has changed since starting the pages. I guess we should link to http://live.gnome.org/TwoPointTwentyone/Bindings This link will have to be kept up to date, if this is the link to use, it would be better to have a more permanent link that doesn't change with new versions of GNOME (which we used to have). 3. Putting the language bindings on a separate page (if we keep the table of course). This any a bunch of other things we have had requested will be processed in due course :) -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Final Draft
On Mon, 2008-01-28 at 13:16 +0100, Murray Cumming wrote: > > And I still believe that the official GNOME bindings deserve to be in > a > separate section. I see that the site is live already. Please don't just ignore this regression. I've mentioned it before too. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Can I use gtk_widget_unref() to releasetthe object created by gtk_invisible_new()?
Am Mittwoch, den 30.01.2008, 10:54 +0200 schrieb [EMAIL PROTECTED]: > The floating references in GTK make the whole reference counting a bit messy. > The following points make life easier: > > * Always have a matching g_object_unref for each g_object_ref you have You mean, g_object_ref_sink(). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Final Draft
Andreas Nilsson wrote: > Christophe Dehais wrote: > >> Talking about the logo (which is very nice - simple and cool, like gtk >> :)), what about a page where one's could get it in different formats >> (svg, png, icon sized, etc.) ? >> >> > Hi Christophe! > Sounds like something that should probably go into the gnome wiki. > I'll upload it later today. > - Andreas http://live.gnome.org/GTKLogo Shout if you need any other formats. :) - Andreas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk.org page width
On 30/01/2008, Martyn Russell <[EMAIL PROTECTED]> wrote: > Paul Pogonyshev wrote: > > Sorry, I noticed the discussion about new gtk.org design but didn't > > follow it. The only thing I don't like in new design is fixed to > > 700px page width. I think that goes against GTK+ friendliness to > > different font size etc. :) I'd like to see sth. like 70ex or > > 40em whatever. > > This issue has been raised time and time again. > > It is a design decision and has been discussed in previous mailing > threads. So it won't be changing. Sorry to revive this again, but does anyone have a link to the discussion of this? My google search is failing me. It seems strange to me that GTK goes to a lot of trouble to support accessibility (atk and friends), but then has a homepage which breaks W3C accessibility guidelines. Other than this issue I really like the redesign, congrats to all who worked on it. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Can I use gtk_widget_unref() to releasetthe object created by gtk_invisible_new()?
Hi,
Answers to your questions:
1) Yes, the GtkInvisible is *not* floating (see the my description
earlier in this thread to find out why). Note that any toplevel
widget (GtkWindow, GtkDialog) is *not floating* either, for the same reason.
2) Yes, you need to use gtk_widget_destroy in this case, not g_object_unref.
(the reason is mentioned earlier in this thread).
The floating references in GTK make the whole reference counting a bit messy.
The following points make life easier:
* Always have a matching g_object_unref for each g_object_ref you have
* Always have a g_object_unref for each function that returns new GObject
that *doesn't use* floating references (GtkTreeModels, GtkSizeGroups)
* When creating new objects that *may be floating* (all GtkWidget based
ones, GtkInvisible being one example), don't try to use g_object_unref
(if not adding extra reference trough g_object_ref earlier). Pack them
to containers and use gtk_widget_destroy when you are done
with them. Usually you need to use g_object_ref/unref with widgets
only if you are implementing a custom container.
Hope this helps,
-Markku-
Lainaus [EMAIL PROTECTED]:
> Hi, Markku,
>
> Thanks a lot for your help.
>
> I did some further investigation on this issue. I have two questions on
> this issue:
>
> 1. The object created by gtk_invisible_new() is not "floating".
>
> Here is a snippet from gtk+-2.12.5/tests/testselection.c
>
> init_atoms();
> selection_widget = gtk_invisible_new ();
> * m = GTK_OBJECT_FLOATING(selection_widget); //***
> dialog = gtk_dialog_new ();
> gtk_widget_set_name (dialog, "Test Input");
>
> The black line (marked with "**") is added by me.
> When I run testselection, "m" is set to 0 instead of 1. Which means the
> selection_widget is not "floating".
> right or I used a wrong macro?
>
> 2. How to release an object created by gtk_invisible_new()?
> Look at following snippets:
>
>void InitWidget() {
> mWidget = gtk_invisible_new();
> *gtk_object_ref(GTK_OBJECT(mWidget)); //***
> gtk_object_sink(GTK_OBJECT(mWidget));
> gtk_widget_ensure_style(mWidget);
> mStyle = gtk_widget_get_style(mWidget);
> }
>
>nsLookAndFeel::~nsLookAndFeel()
>{
>// gtk_widget_destroy(mWidget);
>gtk_widget_unref(mWidget);
>}
>
> If I comment out the black line (marked with "**"), the mWidget
> reference count is 1 as expected,
> but when unref it in nsLookAndFeel::~nsLookAndFeel, thunderbird will
> crash.
> It looks like that I can't us gtk_widget_unref() on the object returned
> by gkt_invisible_new().
>
> So my question is how to "free" an object returned by gtk_invisible_new()?
>
> Thanks a lot
>
> Brian
>
>
> Markku Vire wrote:
> > Hi,
> >
> > The reference that is returned by gtk_invisible_new is not owned by the
> > caller. If one tries to unref it, it's an immediate memory corruption.
> >
> > When a toplevel widget is concerned, the things go like the following:
> > * New floating GtkWidget is created (not owned by anyone).
> > * GTK library takes ownership of the toplevel (calling
> >g_object_ref_sink). Floating reference is converted to normal one.
> > * Widget pointer is returned (refcount = 1, owner = gtk).
> >
> > So, in the code you attached gtk_object_ref increases the reference
> > count to 2, gtk_object_sink does nothing (since it not floating any
> > more).
> >
> > Later gtk_widget_unref decreases refcount back to 1, but there is still
> > one reference left (owned by gtk). Trying to remove it by g_object_unref
> > is a bug (as you noticed). The way to ask GTK to release the last
> > reference is to call gtk_widget_destroy.
> >
> > If you are just interested about the GtkStyle object, you could try
> > using gtk_rc_get_style_by_paths for example?
> >
> > Cheers,
> >
> > -Markku-
> >
> > On Fri, 2008-01-11 at 16:53 +0800, Brian Lu wrote:
> >
> >> Thanks a lot for your explanation. But look at following snippet from
> >> firefox latest code base:
> >> void InitWidget() {
> >> mWidget = gtk_invisible_new();
> >> gtk_object_ref(GTK_OBJECT(mWidget));
> >> gtk_object_sink(GTK_OBJECT(mWidget));
> >> gtk_widget_ensure_style(mWidget);
> >> mStyle = gtk_widget_get_style(mWidget);
> >> }
> >> see
> >>
> http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsLookAndFeel.h#77
> >> and
> >> nsLookAndFeel::~nsLookAndFeel()
> >> {
> >> // gtk_widget_destroy(mWidget);
> >> gtk_widget_unref(mWidget);
> >> }
> >> see
> >>
> http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsLookAndFeel.cpp#78
> >>
> >> I find mWidget is leaked (detected by using libumem.so provided by
> solaris).
> >>
> >> I don't understand why calling gtk_object_ref() to increase mWidget
> >> reference count.
> >> This causes mWidget's reference count to be 2 and gtk_widget_unref() in
> >> deconstructor decreases it to 1.
> >>
> >> Thanks
>
