Tables and spacing for empty rows/columns

I just noticed that GtkTable requests and allocates size for rows and columns that are empty, or that have no visible widgets in them. This leads to surprising spacings in the end. For example, say we have a 3x3 table like this, and the table has a certain row spacing. child11child12 c

Empty containers and border_width

Empty containers (well, I just checked GtkBox and GtkTable) will request a size of (2 * border_width) if the container is empty. Shouldn't the requisition be just 0 for such empty containers? Seems that this may automatically de-chubbify some stale .ui files that end up with all-empty slots in co

Re: Empty containers and border_width

On Wed, 2010-04-21 at 05:23 -0400, Tristan Van Berkom wrote: > Containers that expect to be empty at times should simply > be aware of their padding. Yeah, good points. People do use empty containers (alignments and such) to add indentation for sections in configuration dialogs. So I won't chan

Re: gtk_widget_draw()

On Mon, 2010-08-09 at 02:07 +0200, Benjamin Otte wrote: This is awesome stuff, Benjamin. > I'll start with the end goal: gtk_widget_draw(GtkWidget *widget, cairo_t *cr); One thing I'd definitely like to have is the region-to-expose. Many times people have started with "oh, I'll just paint every

Re: gtk_widget_draw()

On Tue, 2010-08-10 at 01:59 +0200, Benjamin Otte wrote: [Widgets that own multiple windows] > My current idea on how to implement it is to give the widgets a hint > as to wether they are repainting a window or wether they are painting > to something else. Something like gdk_cairo_get_current_windo

Re: gtk_widget_draw()

On Tue, 2010-08-17 at 17:28 +0200, Benjamin Otte wrote: > The biggest problem for me when reading the GdkWindow code is that I > have no idea what a window is. So I have a hard time understanding the > code and if what it does is sane. One pattern we see a lot is when widgets want to paint themsel

Re: cairo drawing commands to gdk_invalidate_region

On Tue, 2010-08-17 at 10:35 +0300, Dov Grobgeld wrote: > Assume I have a routine: > > int draw(cairo_t *cr) > > used to draw an overlay in a GdkWindow. > > In order to minimize redrawing, I would like to get the minimal (up to > some accuracy to be determined) set of GdkRegion's that encomp

Re: gtk_widget_draw()

On Tue, 2010-08-17 at 21:10 +0200, Alexander Larsson wrote: [Widgets with an InputOnly window for events] > Yeah, they do it to avoid the window resize being asynchronous with > respect to the repainting, etc, causing ugly looking resizes. Oh, I thought they did it to get the parent's background.

Re: gtk_widget_draw()

On Wed, 2010-08-18 at 07:56 -0400, Paul Davis wrote: > its quite amusing to me how what is being described is slowly > converging on something extremely close to a canvas model in many of > its most fundamental aspects. am i the only one seeing this? does it > matter? In my mind a canvas does two

Re: gtk_widget_draw()

On Wed, 2010-08-18 at 09:37 +0200, Alexander Larsson wrote: [Border around windows so you can "glow" around a widget] > There are all sorts of ways you can hack it into GtkButton or any > specific widget, I'm sure. However, its hard to do in a more generic way > for a theme. I was thinking the the

Re: gtk_widget_draw()

On Thu, 2010-08-26 at 12:35 -0400, Behdad Esfahbod wrote: > Just keep in mind that it's very normal for text ink to leak out of the > allocation area. So even if the draw-border property is removed, we should > eventually figure out how to handles these. But widgets are supposed to request a size

multiroot-filechooser ready for merging

Hi, all, I've been running Christian Hammond's multiroot-filechooser branch for about a month now, with zero ill effects. This is not surprising, as no apps actually use the multirooting functionality yet; what is nice is that those apps haven't broken yet. The past discussion is in bug #609886.

Re: Need some advice for glib developer beginer

On Thu, 2010-09-30 at 14:30 +, Alexander Kuleshov wrote: > Now i learning glib codebase and where can i find TODO or something > else for glib, maybe not complex bugs... For know how - to > write,review and submit pathes. These days the TODO list for glib is in bugzilla; all the bugs are the

Re: multiroot-filechooser ready for merging

On Wed, 2010-10-06 at 21:01 +0100, Bastien Nocera wrote: > Symbolic links? To both the filesystem itself, and to directories under > ~/.gvfs/. Are those blocked as expected? Looks like we have different expectations ;) Nope, we don't try to resolve symlinks to see if they point to allowed hierar

Re: multiroot-filechooser ready for merging

On Wed, 2010-10-06 at 22:32 +0200, Torsten Schoenfeld wrote: > Yes, I think so. It's pretty common for arguments and properties, so > most bindings will be able to deal with it. With proper annotations, > gobject-introspection can also represent it. Excellent. Where are those annotations mad

Re: multiroot-filechooser ready for merging

On Thu, 2010-10-07 at 07:09 -0400, Matthias Clasen wrote: > When "rooted to $HOME and /tmp", I > found that typing '/' would still complete all toplevel directories, > while typing '/t' comes up with no completions. I would have expected > just '/tmp' in both cases. Good catch, thanks. I'll take

Re: multiroot-filechooser ready for merging

On Thu, 2010-10-07 at 00:28 +0200, Torsten Schoenfeld wrote: > > G_TYPE_STRV properties don't need annotations, they are handled > automatically. But functions like your > gtk_file_chooser_set_root_uris > need to have annotations to tell gobject-introspection that 'char > **roots' is actually

Re: multiroot-filechooser ready for merging

On Thu, 2010-10-07 at 09:59 +0100, Bastien Nocera wrote: > > Then I would play down the security benefits of the features in the > documentation... Yeah, good point. The docs as they are just say that you can't go outside the roots, which could mean that the code tries really hard to do that.

Re: grid widget (was Re: possible removal of GtkWrapBox)

On Thu, 2010-10-07 at 09:23 -0400, Havoc Pennington wrote: > Don't know if this will make sense to anyone else but I do think it's > useful to take some real-world layouts and see how much typing they'd > require This is a very interesting exercise, and the pseudocode for those examples *is* real

Re: Writable array returned from gtk_tree_path_get_indices()

On Thu, 2010-10-07 at 09:18 -0500, Stef Walter wrote: > Is the integer array returned from gtk_tree_path_get_indices() writable > by design? Or should it be treated as readonly? It depends. Sometimes you get a GtkTreePath from the treeview API when you ask for something (e.g. gtk_icon_view_get_pa

Re: multiroot-filechooser ready for merging

On Thu, 2010-10-07 at 20:20 +0200, Torsten Schoenfeld wrote: > This is the canonical place, as far as I know: > . Perfect, thanks! Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome

Re: grid widget (was Re: possible removal of GtkWrapBox)

On Thu, 2010-10-07 at 15:05 -0400, Havoc Pennington wrote: > It's a valid point, but I don't know that Glade is always easiest. I > don't think it's a good excuse for making the actual API crappy. Oh, no, of course not. What I mean is that if few apps actually do complex layout by hand, then may

Re: Minimum height for minimum width

On Mon, 2010-10-11 at 15:41 -0400, Havoc Pennington wrote: > Uggghhh... so the h-f-w request/allocate stuff needs to be exposed to the WM > ;-) Client-side decorations! :) Then we can handle everything ourselves. (Of course it's not so trivial... then we'll want to know things like snap coordi

Grabs and completions

Hi, I'm trying to understand why bug #639842 happens. It's pretty easy to reproduce on 3.0: 1. gtk+/tests/testfilechooser --action=save 2. type "/home/" plus the first letter of your username 3. wait for the completion suggestion window to appear 4. hit Tab 5. The focus changes to the next widge

Re: GTK and ATK

On Tue, 2011-05-10 at 16:28 +0200, Benjamin Otte wrote: > The TL;DR version is this: > I think the problem is the fact that we support a separate API for > accessibility. Let me present my (very limited) understanding of how a11y works right now. This is for the benefit of gtk-devel-list; people

Re: I have a problem

On Sat, 2011-05-28 at 23:01 +0200, Benjamin Otte wrote: > And I'm somewhat lost what to do then. Should I say yes > because it's a good widget to use in general? Should I say no, because > it shouldn't be used? What are the features and behaviors I have to > look out for in those widgets so they e

Re: I have a problem

On Tue, 2011-05-31 at 01:53 +0300, Andrew W. Nosenko wrote: > 1. how I can to hover using touch screen? You may not be able to (I don't know if X on your touch screen would emit proximity events). In that case, those UIs that require hovering may indeed not be adequate for your touch screen. To

String change in gtk-3-0 branch

Dear translators, I have just merged an interesting patchset to gtk+, in the gtk-3-0 branch. This adds two or three new strings to the package; I hope that doesn't cause too much trouble for you. GTK+ hackers: this is the merge of the bgo593793-filechooser-recent-folders branch, which is describ

gtk-2-24 has new strings

Dear translators, I've just pushed some changes to the file chooser in the gtk+ module, specifically to the gtk-2-24 branch. Although right now the focus is 3.x, we will likely have another release in the 2.24.x series for GTK+. Please update your translations there :) (The idea is to have the f

Re: gtk-2-24 has new strings

On Wed, 2011-07-13 at 10:32 +0100, Bastien Nocera wrote: > But why do that in stable releases? Unless there's a very very (very > very) good reason to break the freeze, the stable branches should only > see bug fixes. Why was this pushed to stable branches? This change makes the file chooser much

Re: GTK+ team meeting at guadec

On Wed, 2011-07-27 at 14:41 -0400, Matthias Clasen wrote: > I have been slacking off and not pushing for team meetings recently, > and I haven't even looked at the guadec schedule until today. > But I guess better late than never: should we aim for a gtk team > meeting at guadec ? > If so, what da

Sharing the places sidebar between Nautilus and GTK+

Hi, everyone, There is a patch in [1], by Jon McCann, to make the shortcuts bar in GtkFileChooser be pretty much the same as the one in Nautilus. Rather than patch the wobbly edifice that is gtkfilechooserdefault.c, this sounds like the perfect time to actually pull out the shortcuts bar as a pub

Re: GTK and OSX: a call to sanity

On Wed, 2011-09-07 at 08:25 +0100, Emmanuele Bassi wrote: > Windows and Linux build issues and support are handled on gnome.org: the > Quartz backend of gtk is not in any regard special and it should not > need separate resources. One thing we have been bad at is learning to accept that sometimes

Re: regarding GIO

On Thu, 2011-10-20 at 10:27 -0400, Daniel Hernandez Bahr wrote: > The thing is the GCancellable objects provide, as I am aware of, only > the 'cancel' feature for async operations, would it be too hurtful to > implement a GControllable class providing features such as > 'pause'/'resume' as well as

Re: RFC: Model-View-Controller

On Fri, 2011-11-11 at 15:55 +0100, Benjamin Otte wrote: [Talking about GtkButton] > And it'd have those "Controllers": > (- Hover) > - Click > - Activate > (- Focus) > - KeyPress/Release I just took a quick look at ClutterClickAction and ClutterDragAction. They are certainly interesting. I wonder

File chooser recent-files (was: Re: Guidelines for stable branch changes in GLib/Gtk)

table to be presented with a recently-used list. [1] https://live.gnome.org/DocumentCentricGnome/Help%20the%20user%20choose%20a%20place%20to%20put%20a%20new%20file Federico >From dc52c6d45d05841b916c61c454666fd99cc52372 Mon Sep 17 00:00:00 2001 From: Federico Mena Quintero Date: Fri, 16 Nov

Re: Guidelines for stable branch changes in GLib/Gtk

On Sun, 2012-11-11 at 12:55 -0800, Matthew Brush wrote: > Any chance of reverting/fixing those changes? > > Here's some related bug reports I could find: [snip] Thanks for compiling this list of bugs; it's very helpful! Please see the thread I started as a reply to Ryan - the "File chooser rece

Re: File chooser recent-files (was: Re: Guidelines for stable branch changes in GLib/Gtk)

On Mon, 2012-11-19 at 17:07 +, Sam Thursfield wrote: > The biggest issue I've had with the feature is that the list of > recently used folders in the 'Save As' dialog only displays the name > of the folder, not its full path. Which of the 6 folders named 'src' > did I want to use again? Ther

Re: File chooser recent-files

On Mon, 2012-11-19 at 10:52 +, Simon McVittie wrote: > If this sort of change is important, it sounds to me as though Gtk 2 > should continue to have (short!) branches corresponding to a GNOME > release when necessary? GTK+ 2.24.x still has releases! Do you mean that they should appear in sy

Re: Sharing settings between Nautilus and Filechooser

On Wed, 2012-11-21 at 09:56 +0100, Bastien Nocera wrote: > > What do you think of "org.gnome.file-view-preferences"? > > Add a schema to GTK+: > org.gtk.file-chooser show-hidden-files Yup, this is the way to go. Currently the file chooser uses org.gtk.Settings.FileChooser and a few keys; the sou

Re: Sharing settings between Nautilus and Filechooser

On Tue, 2012-11-20 at 18:51 -0800, Timothy Arceri wrote: > There is also a bug to do with sharing the single clicking settings > however this is more complex so I thought I would see if I could get > this one fixed first. Please see https://bugzilla.gnome.org/show_bug.cgi?id=121113 for the old "s

Re: GtkWidget::visible

On Tue, 2013-01-08 at 16:04 +0100, Benjamin Otte wrote: > - containers don't know what to do > Should they skip invisible widgets when allocating? Or still reserve > space for them? Tag, you are it! :) A couple years ago I totally failed in fixing this bug in GtkTable (I just made things worse an

Some shortcomings in gtestutils

Hi, everyone, I've been writing some tests for GtkFileChooserButton and putting them in gtk+/gtk/tests/filechooser.c - this is the old test suite, resurrected and alive. So, I've been learning what gtestutils provides. It is not bad, but it seems pretty pedestrian on some counts. These are some

Re: Notebook tab not correctly drawn if tab pos = BOTTOM (gtk 3.5.4, win32)

On Tue, 2013-02-19 at 18:39 +0100, th-pitsc...@uni.de wrote: > I was putting a GtkNotebook on a main window widget (using glade) and > set the tab position to BOTTOM. This looks alright in glade. > > > However, running the application itself one sees that the tabs are not > drawn correctly (they

Re: Some shortcomings in gtestutils

On Thu, 2013-02-21 at 11:12 +, Philip Withnall wrote: > Add the following in your Makefile.am: > TESTS_ENVIRONMENT = libtool --mode=execute gdb > > Then run `make check` as normal, and magically all of your tests will be > run under gdb. > > If you just want to run a specific test b

Re: Blacklisting themes?

On Tue, 2007-06-19 at 15:08 -0400, Morten Welinder wrote: > The application programmer has no choice in the matter and cannot > really test with > all kinds of themes and all kinds of versions of them. But the > resulting crashes are > still going to be blamed on the application and poor me. So

Re: Blacklisting themes?

On Fri, 2007-06-22 at 09:20 -0400, Jody Goldberg wrote: > I don't think Morten's intent was to handle the blacklist at the > application level. A more practical approach would be a bugbuddy > extension that would compare the current theme engine and version > against a central collection of known

Re: Blacklisting themes?

On Wed, 2007-07-04 at 01:48 +0200, Milosz Derezynski wrote: > Reminds me all of http://bugzilla.gnome.org/show_bug.cgi?id=326249 > > I'm not sure this ever got a proper audit and all themes in general > could need one. Hmm, didn't that get fixed? At least for the well-known themes? > Does ther

Re: How to detect display speed in custom widget?

On Thu, 2007-09-06 at 20:47 -0700, Daniel Yek wrote: > I'm wondering if anybody is experienced in writing smart widget that > would react differently depending on whether the current display is > local/fast for graphics animation or remote/slow where all animation > should be kept to the minimu

Re: Theory of good signal/event API design?

On Sun, 2007-09-16 at 18:28 +0200, Sander Marechal wrote: > My question: How do I determine what signals/events I should send out so > that together they make for a nice module API? For now, I am simply > building modules and adding signals to the application as I need them, > but I bet there is a

Re: Abstract string properties with getter/setter functions

On Thu, 2007-09-20 at 08:34 +0200, Raffaele Sandrini wrote: > Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack > done there is somehow possible with objects it is not with strings. > > GtkWidget * > gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser) > { > GtkWidge

Re: turning g_assert* into warnings

On Fri, 2007-10-12 at 11:52 +0200, Tim Janik wrote: > i'd like to propose to turn g_assert and friends like g_assert_not_reached > into warnings instead of errors. i'll give a bit of background before the > details though. > > the main reasons we use g_return_if_fail massively throughout the glib

Re: GdkPixbuf vs. Cairo, new image library needed?

On Mon, 2007-10-15 at 09:04 -0700, Carl Worth wrote: > On Sat, 13 Oct 2007 00:51:44 +, "=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=" > wrote: > > I have played around with Cairo some more and it seems to me that it > > is not fully ready yet. :( Cairo blits and scales much slower than > > gdk-pixbuf (s

Re: let g_warn_if_fail replace g_assert

On Wed, 2007-10-17 at 11:56 +0200, Tim Janik wrote: > - extend the g_assert() docs to note that: >1) programmers are more likely to want to use g_warn_if_fail instead > (particularly for libraries, allthough the destabilizing effects > of g_assert are also worth avoiding in applicai

Vertical position of text in under-allocated labels

Hi, We have a problem in gnome-main-menu which is (understandably) a corner case in GtkLabel ( https://bugzilla.novell.com/show_bug.cgi?id=310710 ) First, please see no-focus.png (attached). That is main-menu's "Computer" button and a button from the task list applet. You'll see that the labels

Re: Vertical position of text in under-allocated labels

.. And here is a patch which fixes the problem in main-menu. Federico 2007-12-17 Federico Mena Quintero <[EMAIL PROTECTED]> * gtk/gtklabel.c (get_layout_location): For single-line labels, align the requisition to the allocation unconditionally, even if we are under-allocated. For

g_format_file_size_for_display()

Should this be called generically g_format_size_for_display()? You could use it for more than file sizes (free RAM in gnome-system-monitor, etc.). Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinf

Re: g_format_file_size_for_display()

On Tue, 2007-12-18 at 16:45 -0500, David Zeuthen wrote: > char *g_format_file_size_for_display (goffset size); > > Ideally this one needs to take another parameter indicating whether you > want 1kb = 1000 bytes or 1kb = 1024 bytes. No, because then you'll have applications using either, and the

Re: g_format_file_size_for_display()

On Wed, 2007-12-19 at 10:12 +0100, Alexander Larsson wrote: > Sure, that makes sense to me, I'll change it. Awesome, thanks :) > Now, if we had a locale flag for getting MiB that would be ok with me I > guess, but I really think we should be showing the traditional sizes by > default. Fully agr

Moving "Open with" to the platform

Hi, Right now, the "Open with another application" dialog lives in nautilus/libnautilus-private/nautilus-open-with-dialog.[ch]. This dialog uses the machinery in GIO's GAppInfo to figure out which apps can be used to open a file of a certain MIME-type. There's a long-standing annoyance in Firefo

Re: visibility-notify-event query

On Sun, 2008-03-16 at 21:06 -0700, iluvlinux wrote: > i have a question regarding visibility-notify-event > If i add widgets to a container than i get the signal > visibility-notify-event, whenever visibility changes > but if i add widgets to a scrolledwindow i donot get visibility-notify-event >

Re: Integrating optional file chooser implementations into GTK+

On Thu, 2008-05-01 at 13:23 +0100, Ross Burton wrote: > Would there be any interest in us cleaning the patch up as a standalone > file chooser implementation, adding it to the GTK+ sources, and then > letting GtkFileChooser use a configurable (at configure time) > implementation (defaulting to the

Re: proposal: substantial change to keyboard-driven action handling

On Tue, 2008-05-06 at 10:47 -0400, Paul Davis wrote: > Any given GtkWidget has zero or more maps that connect a key event > tuple to a closure. When a key event is received by a GtkWindow, the > window first allows the focus widget to look up an event in its > map(s) of tuples/closures. If the eve

Re: problem finding the position of a button in the gtk dialog ( sample code inside )

On Wed, 2008-05-07 at 11:33 +0530, chirag juneja wrote: > approach i am using is : > i will find the distance of the button from its parent, and then its > parent's distance form its parent .. and so on, till i get toplevel > window. > then i am adding the decoration's height, border's width and d

Re: Gdk patch review request

On Wed, 2008-05-14 at 15:31 +0200, Danny Baumann wrote: > since a couple of weeks, I have two patches pending in Bugzilla that fix > problems which seemingly are bugs in Compiz, but actually are Gdk > problems. As we (== Compiz people) are getting quite some bug reports > about both issues, I want

Re: Late 2.14 feature request: Installing gtkhsv.h

On Fri, 2008-08-08 at 12:05 +0200, Michael Natterer wrote: > The GtkHSV widget was originally ported from the GIMP "triangle" > color selector. Huh, really? I have fond memories of fun with barycentric coordinates for the HSV wheel during Linux World in North Carolina, way back when :) (May

Bikeshedding the invisible-char

Fedora has a (currently unapplied?) patch in its gtk2 package which changes GtkEntry's invisible-char defualt from "*" to "•" (Unicode 0x2022 BULLET). openSUSE has a patch that changes the invisible-char to "●" (Unicode 0x25CF BLACK CIRCLE). I'm arguing for committing openSUSE's patch based on th

Re: Bikeshedding the invisible-char

On Tue, 2009-01-20 at 04:14 +0200, Xan Lopez wrote: > How is this different from bug > http://bugzilla.gnome.org/show_bug.cgi?id=83935 that was committed > some months ago? It even uses your favorite character! Argh, I'm an idiot. As usual, Garnacho created the perfect patch. What happened is t

Re: fsync in glib/gio

On Fri, 2009-03-13 at 09:15 -0400, Morten Welinder wrote: > F*** "POSIX allows this"! A program that does open-write-close- > rename should not be left with an empty file in case something > goes wrong. The old file, or the new file. Anything else is insane > and by extension the kernel develop

Re: fsync in glib/gio

On Fri, 2009-03-13 at 22:16 +0100, Alexander Larsson wrote: > Its well explained in the various discussions about this. Essentially, > the metadata for the rename is written to disk, but the data in the file > is not (yet, due to delayed allocation) and then the system crashes. On > fsck we discov

Re: GtkPlug not chaining up to GtkWindow's keys_changed handler?

On Sat, 2009-04-18 at 17:22 -0400, Yu Feng wrote: > In GTK 2.14.4, GtkPlug does not chain up to GtkWindow's keys_changed > handler. (gtkplug.c:1043 and gtkwindow.c:7937) > > The effect is that the key hash in the 'gtk-window-key-hash' data member > of the window is not updated whenever the mnemon

Re: Gtk+ merges

On Mon, 2009-05-25 at 13:20 +0200, Alexander Larsson wrote: > I see some commits in git master, like > 4134c346f9e68367e515345c0ded07aa2b857a1a that looks kinda weird. > Federico, did you really mean to merge all of the stable branch into the > unstable branch, or did you just want to cherry-pick t

Re: Gtk+ merges

On Wed, 2009-06-03 at 22:16 -0400, Matthias Clasen wrote: > As a data point, I've also preferred to go with cherry-picking from > master so far. It just seems closer to the way I'm working with our > branches. OK, no big deal... I'll cherry-pick in the future. Federico

Re: A tale of waiting

On Tue, 2009-06-23 at 22:16 +0200, Benjamin Otte wrote: > I have been on a quest to improve performance of the file chooser First, thanks for taking on this work. "Kill GtkFileSystem" is a very worthwhile goal. > * The sort function was called way too often. So I added the option > to freeze an

Re: [patch] batch scanlines when loading JPEG...

On Fri, 2009-08-28 at 16:12 +0100, Daniel J Blueman wrote: > I've written and tested a small patch that increases efficiency > (particularly in small-cache systems) of loading JPEG images: override > the recommended lines with what we've already allocated; increase > batch size from 4 to 8 lines.

filesystemmodel branch - initial testing

Humans from Earth, I'm finally testing Company's filesystemmodel branch. IT IS SO FAST! Really, it makes the file chooser much snappier. And the code is a pleasure to read. I haven't had crashes yet, although I haven't tested all the features in the file chooser. I guess I'll keep testing it f

Re: filesystemmodel branch - initial testing

On Thu, 2009-10-01 at 01:48 +0100, Bastien Nocera wrote: > Not having looked at the code since the original patches, have all the > concerns about the possible regressions and incremental changes been > addressed? I did a *very* careful review of the code, and it seems sane. If you look at the "

Re: filesystemmodel branch - initial testing

On Thu, 2009-10-01 at 11:20 -0400, Matthias Clasen wrote: > If the improvements are as impressive as Federico makes them sound, > then I think getting them into 2.18 (and thus out to users) would be a > nice thing, imo. Basically, before the filesystemmodel branch, I dreaded using the file choose

[Fwd: gtk+ wrong code in JPEG loading module]

This landed in my inbox - has anyone played with new versions of libjpeg to see if this works? Federico --- Begin Message --- Hello all This is a report to the authors mentioned in the gdk-pixbuf/io-jpeg.c module of the current gtk+ 2.18.0 package, from Guido Vollbeding, organizer Independent J

Re: Global motion events

On Sat, 2005-05-14 at 13:49 +1000, Russell Shaw wrote: > Why doesn't every widget have an X window? Read this: http://primates.ximian.com/~federico/misc/gtk-drawing-model/ It explains this and other things. Federico ___ gtk-devel-list mailing list

Re: Recently Used Files Proposal

On Thu, 2005-06-02 at 10:19 +0200, Emmanuele Bassi wrote: > I've spoken with Federico at GUADEC about the recently used files > handling, and we came up with some ideas for improving the current > situation. I must say that the huge delay at the crappy restaurant in front of the conference center

Re: Recently Used Files Proposal

On Thu, 2005-06-02 at 10:19 +0200, Emmanuele Bassi wrote: > I've attached a prototype API for GtkRecentItem and GtkRecentManager > (already set to live in libegg, for the time being). Let me know what > you think of it. Oh, BTW... to see what other systems do already, I looked at the Win32 API an

Re: gtk regression test suite

On Mon, 2005-06-13 at 09:48 +0100, Jon Dowland wrote: > I was wondering if there was any interest amongst the GTK+ hackers to > investigate creating a regression test suite. The right way to do this is through LDTP: http://gnomebangalore.org/ldtp/index.php/Main_Page The testing scripts are wri

New string in gtk+ gtk-2-6 branch

Dear translators, To fix a bug in the gtk-2-6 branch of the gtk+ module, I've had to add a new string in gtk+/gtk/gtkfilechooserdefault.c. We want to do a 2.6.8 release this week, so it would be great if you could update your translations. Thanks, Federico ___

Re: Language bindings and popup_menu and show_help signals

On Fri, 2005-07-22 at 15:35 +0200, Murray Cumming wrote: > 1. The GtkWidget::popup_menu signal is a G_SIGNAL_ACTION signal (used > only for keybindings), and we were told not to wrap these in language > bindings because the API could change, as did some TreeView signals > between 2.0 and 2.2. The

Re: Language bindings and popup_menu and show_help signals

On Fri, 2005-07-22 at 20:22 +0200, Murray Cumming wrote: > > The API cannot change, by definition :) > > What definition? If some G_SIGNAL_ACTION signals should be wrapped, how > can I know which ones should be and which ones should not be wrapped? We cannot change the public APIs once they are r

Documenting the new features in the devel platform

Hi, Pointed by Murray's and Davyd's list of user features in GNOME 2.12 [1], I started a wiki page with the new features in the *developer* platform: http://live.gnome.org/ReleasesNotes2p12Items_2fDeveloperPlatform It's far from finished. It would be great if library maintainers could take a li

Re: Distinguish column header from normal button

On Tue, 2005-09-13 at 23:45 +0200, Richard Stellingwerff wrote: > To distinguish Column headers from normal buttons, I check if its > parent is a GtkTreeView or a GtkCList. A horrible way, but afaik the > only way. > In order to properly distinguish a column header from a normal button, > I was th

Re: Distinguish column header from normal button

On Wed, 2005-09-14 at 09:29 +0200, Richard Stellingwerff wrote: > By "hint," do you actually mean the 'detail' parameter that gets > passed on to gtk_paint_*()? Simply changing that would break a lot of > themes that currently don't know how to handle the new 'detail'. Yes, I meant the "detail" p

Re: Distinguish column header from normal button

On Wed, 2005-09-14 at 02:01 -0700, Todd Berman wrote: > The current hacks that 3rd party developers have to go through when they > want to render something that looks like a themed native treeview header > are bad enough (creating a fake treeview, adding a column, and passing a > widget somewhat d

Tests for GtkCellRendererText

Hi, I just committed a new gtk+/tests/testcellrenderertext.c. The program creates a treeview that displays several rows, and each row uses different values for GtkCellRendererText's many attributes. Load the program, maximize the window, and resize the "Test" column to be much wider than the tex

Re: Proposal for making the GtkFileChooser code asynchronous

On Tue, 2005-11-15 at 13:46 +0100, [EMAIL PROTECTED] wrote: > > The functions > gtk_file_folder_list_children() and gtk_file_folder_get_info() > > will > not be changed. > > Are these ones going to be blocking calls, or do they > return a partial result? The idea is to remove gtk_file_fol

Re: Call-return interface for file choosers? (and: security using powerboxes)

On Sat, 2005-11-19 at 12:57 +, Mark Seaborn wrote: > Obviously the interface wasn't designed with this in mind. It is a > shame that Gtk doesn't also provide a simpler file chooser interface > that omits control over the dialog box while it is open. (Contrast > this with Qt and Windows, which

Re: Proposal for making the GtkFileChooser code asynchronous

On Tue, 2005-11-22 at 12:07 +0100, Kristian Rietveld wrote: > We are indeed going to add a toplevel gtk_file_system_get_info(), I was > not thinking of removing gtk_file_folder_get_info() though. Does it > make sense to remove it? I don't think leaving it were it is now will > hurt anything. Tak

Re: glib and pango 2.10 in GNOME 2.14?

On Thu, 2005-12-01 at 15:55 -0500, Matthias Clasen wrote: > The implementation of the major new api in GLib, the slice allocator, > just landed in cvs. So I don't expect big problems with freezing the > GLib API before the year ends. I'd like to have at least a "relocation" API in place. This i

Re: Additions to GInterfaces

On Thu, 2005-12-01 at 09:55 -0600, Mike Kestner wrote: > When auditing the new API in 2.8 for Gtk#, I noticed that a property and > signal were added to the FileChooser interface. Adding anything to an > interface is a non-compatible change, because any class implementing the > interface must be u

Re: g_list_prepend() does not call g_list_first()

On Fri, 2005-12-02 at 01:50 +, Paul LeoNerd Evans wrote: > That said, by specifically not moving to the head of the list, this makes > it into an equivalent of g_list_insert_before(), when passed the same > GList* as both arguments. Is this intended / desirable / noticed? Could you please subm

Re: Deprecate GdkGC?

On Thu, 2005-12-01 at 22:50 +0100, milosz derezynski wrote: > I agree but it doesn't sound really easy as GtkStyle holds a number of > GdkGCs for the style colors. ... and apps still do this: gdk_gc_set_clip_rectangle (widget->style->black_gc, &my_rect); gdk_draw_pixbuf (widget->window,

More about tooltips

Hi, I haven't (re)read the proposed new API for tooltips, but this is pretty interesting: http://blogs.msdn.com/jensenh/archive/2005/12/02/499371.aspx Basically, the new version of MS Office will have tooltips that are way more useful than a few short words. We should be able to do that with th

Re: Deprecate GdkGC?

On Fri, 2005-12-02 at 09:43 +0100, milosz derezynski wrote: > Well, i volunteer for this. I have used cairo extensively for coding > bmpx and i'm going to get to a very good point in documenting at least > all the equivalents of gdk_draw_*() > > Federico: In which format should i write this, anyth

  1   2   3   >