Re: A GTK+ roadmap update
Hi Matthias, Thanks for posting this roadmap, and sorry for responding to it a month late. One thing I don't see on that roadmap that I was hoping to see is some mention of new drag-and-drop API. I recall seeing Benjamin talking about it on irc at some point, but I haven't followed up since then. I see one of the items on the list is cross-platform story, and on Windows the selection and drag-and-drop pieces have long been pretty broken. And the APIs are pretty difficult to even understand (at least for me), so that's made it difficult to improve. I have a branch of gtk-2-24 locally that I did a lot of hacking to in an effort to get dnd working better on Win32 using OLE2 and removing the old codepaths (there are like 3 completely different dnd codepaths in the Win32 backend, which makes it even more difficult to understand at first). I got it working for some things but wasn't able to figure out how to get everything working perfectly. The selection and dnd parts of gdk are one of the more awkward parts of the API (or maybe I'm just not smart enough to understand them all well enough). I don't remember exactly what I was blocked on anymore, but if anyone wants it I could clean it up and push the branch to git. If a new drag-and-drop API is still in the stars at some point, I would like to help by implementing the Win32 side of it from the start. Maybe this would help in ironing out the gtk API too. / Cody On Tue, May 6, 2014, at 05:52 AM, Matthias Clasen wrote: Its been on my todo list for a while to write an update for the GTK+ roadmap. While I couldn't make it to the Developer experience hackfest in Berlin myself, the GTK+ team was present there and had a pretty extensive roadmap discussion. Thankfully, they took great notes [1]. I encourage everybody who is interested in what is planned for the next year of GTK+ development to read them, they pretty much cover it all. I have now transcribed them into the more task-oriented form of our main roadmap page [2]. The big themes on the agenda are 1. Closing gaps for modern applications (widgets missing for GNOME HIG compliant or Elementary apps) 2. Improving our cross-platform story 3. Touch support 4. Scene graph 5. Better developer documentation 6. Closer ties with glade 7. Cleanups, preparation for 4.0 For 3.14, we're aiming to achieve the following: - Merge the gesture branch - Add a gtkparasite-lookalike debugging module - Make Adwaita the default theme There are many more details in the notes and on the roadmap page, including areas where your help could make a difference. So check it out! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: additional gdk_pixbuf function: gdk_pixbuf_list_options
Hi Oliver,
It's always great to get patches from new developers. Typically you should
either create a new bug on bugzilla.gnome.org or you should email one of the
mailing lists. I'm adding gtk-devel-list@gnome.org to this email so someone
there can try to help you with your patch.
If you don't have an account on Bugzilla yet, I'd recommend creating one and
posting your patch as a feature request to the GTK+ module.
Thanks,
Cody
On Fri, Oct 7, 2011 at 5:16 PM, olivergran...@gmx.de
olivergran...@gmx.dewrote:
Dear Cody Russell,
I have written a small additional function for the gdk_pixbuf library (see
below).
The library provides two functions gdk_pixbuf_set_option and
gdk_pixbuf_get_option to set/get key value pairs, but if you don't know the
names of the keys available you can not access the values. This new function
returns a list of all key attached to the gdk_pixbuf.
The function should be added into the gdk-pixbuf/gdk-pixbuf.c file
(approximately at line 715).
Hope with your help the function could enter the gdk_pixbuf source tree.
Thank you very much
Oliver Granert
-
/**
* gdk_pixbuf_list_options:
* @pixbuf: a #GdkPixbuf
*
* Returns a list with all keys in the list of options that may have been
attached
* to the @pixbuf when it was loaded, or that may have been attached by
another
* function using gdk_pixbuf_set_option().
* Use gdk_pixbuf_get_option() to get the values for each key in the
returned list.
*
* For instance, the ANI loader provides Title and Artist options.
* The ICO, XBM, and XPM loaders provide x_hot and y_hot hot-spot
* options for cursor definitions. The PNG loader provides the tEXt
ancillary
* chunk key/value pairs as options. Since 2.12, the TIFF and JPEG loaders
* return an orientation option string that corresponds to the embedded
* TIFF/Exif orientation tag (if present).
*
* Return value: A newly-allocated NULL-terminated array of key strings.
* Use g_strfreev() to free it.
*
* Since: 2.25
**/
gchar **
gdk_pixbuf_list_options (GdkPixbuf *pixbuf)
{
gchar **options;
gchar **keys=NULL;
g_return_val_if_fail (GDK_IS_PIXBUF (pixbuf), NULL);
options = g_object_get_qdata (G_OBJECT (pixbuf),
g_quark_from_static_string
(gdk_pixbuf_options));
if (options) {
gint length,i;
for (length = 0; options[2*length]; length++); /* determine
list length */
keys = g_new (gchar*, length + 1);
keys[length-1] = NULL; /* mark last entry */
if(keys!=NULL) {
for (i = 0; ilength; i++){
keys[i]=g_strdup(options[2*i])**;
}
}
}
return keys;
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup
On Thu, Jul 22, 2010 at 4:54 AM, Benjamin Otte o...@gnome.org wrote: The work is done and the code runs now. Well, at least testgtk and gtk3-demo do. On X11. I'd be happy if others could take it for a spin and find issues with it or even have a go at Quartz and Win32 code. Hey Benjamin, This is awesome! As I said on irc yesterday, I'll take a stab at getting this working in Win32 next week. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecations for 3.x
On Wed, May 12, 2010 at 11:44 AM, Christian Dywan christ...@lanedo.comwrote: I am curious, as GtkStatusbar is used in every second application, about your suggestions on how to replace it in the typical use cases. I don't actually have thoughts on this yet.. most of the apps I can think of that use statusbars don't really seem to be communicating useful information in statusbars using the push/pop API. xchat-gnome wastes precious pixels to show network lag, although apparently you can disable this in recent versions but it still seems completely pointless. gedit seems to do nice things in the statusbar, but by packing other widgets in.. not sure if they're using the text message push/pop API. Maybe apps should just be patched to remove useless statusbars, but I still wouldn't mind thinking about if there could be more useful APIs for this widget. The message pushing/popping really doesn't seem to be very useful IMO. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecations for 3.x
On Wed, May 12, 2010 at 4:24 PM, Shaun McCance sha...@gnome.org wrote: On Wed, 2010-05-12 at 09:29 +0200, Cody Russell wrote: 2/ Corner resize grips. I want to add support for this directly to GtkWindow anyway. Is anybody actively working on this? Are there ways of doing this that don't a) require vertical padding a'la GtkStatusBar, or b) unilaterally cover up whatever is in the bottom right corner? A lot of document-viewing applications have a GtkScrolledWindow that hit the bottom right. If both the vertical and horizontal scrollbars are visible, there's some really nice dead space there. Yeah, I've got some code for this. I've got some I was working on as part of client-side-decorations, and I've also got some that's independent of that branch. I'm doing some merging and cleaning up of csd code, I'll get some new stuff pushed up into git soon. I'm in Belgium right now, but I'm planning to do this ASAP when I get home next week. For most Gnome and GTK apps, developers are encouraged to use a certain amount of padding, so the grips don't get in the way. But as you point out, scrolled windows are an exception to that and usually go straight up to the window border. My corner-grip branch (without csd) I think does something kind of ugly, and the scrollbar checks the toplevel GtkWindow to find out if it's got a corner resize grip and positions/sizes itself accordingly. It feels slightly hackish, but it looks and behaves find imo. There may be some other situations where something similar needs to be done though. But yeah, if an app fails to set some padding and has, for example, a text editor widget then the corner resize grip would draw over it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: application class thoughts
On Mon, 2010-04-05 at 11:16 -0400, Colin Walters wrote: There are a lot of secondary goals, like ensuring app-uniqueness, improving remote scriptability, better lifecycle support (when how to save state), etc., but they're less important I think than the menu. I'm not sure if this relates to the Actions section of the wiki page or if it should be done lower-level than this application class, but it would be nice to try to get better toolkit-level support for allowing global/application menubars to be managed outside the window, for cases like MacOSX and such. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: application class thoughts
On Mon, 2010-04-05 at 10:15 -0700, John Ralls wrote: Menubars are an interesting problem. The Gtk+ paradigm is that each window has its own menubar, and there is no requirement that different windows' menubars should have the same contents. OSX, on the other hand, normally uses a single menubar for an application. Fortunately, both Cocoa and Carbon allow this menu to be switched at will, so it's easy to follow the Gtk+ paradigm with a focus signal handler. Carbon has a problem with the App menu because there's only one, so one can't just use the usual emit the GtkMenuItem action signal approach; the GtkMenuItem goes away when the window is destroyed. Fortunately, Cocoa has a separate App menu for each mainMenu, so that particular problem goes away. But Carbon is deprecated anyway, right? So if one were to try to design support for all this into gtk 3.0, would it hurt to just ignore Carbon and design for Cocoa? / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gthread: how many cores do I have?
On Mon, 2010-03-15 at 21:14 +, jcup...@gmail.com wrote: Yes, libdispatch is a nice mechanism. If anyone's not come across it, it provides dynamically resizeable threadpools with a central manager which adjusts pools globally to keep the system from bogging down (and a few other bells and whistles, or that's my understanding anyway). But it seems to me that we have a more immediate need: gthread has a threadpools, but no way to pick a reasonable size for a pool. I guess existing cross-platform applications and libraries which use threadpools must all have some duplicated code to pick a default pool size*. If we centralise this, we could perhaps add some standard mechanisms, like a --g-threadpool-size=N argument, or a G_THREADPOOL_SIZE environment variable. Not sure if you've seen this, but Christian Hergert has an interesting library called iris that includes thread and task scheduling. http://git.dronelabs.com/iris / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkNotebook scrolling usability
On Thu, 2010-03-11 at 10:16 +0100, Christian Dywan wrote: Using the mouse wheel that way in a web browser or text editor is a very convenient feature. It is much quicker than having to move the pointer to one of the sides only to switch tabs. Please don't break it just because you never used it :-) I did use it, but it was by accident (when I was scrolling in a web browser) and then I was a little bit confused for a moment. This is usually a pretty good indication to me that there may be a usability flaw. ;) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkNotebook scrolling usability
On Thu, 2010-03-11 at 09:20 +, Alberto Ruiz wrote: If there ends up being a bug report about this, please share the bug number. And hopefully we can get some usability nerds involved in this decision. I agree with Sandy here, I would leave this decision up to the usability guys. That's kind of why I was bringing it up on the mailing lists. Is there a better list to post on to get usability people respond? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkNotebook scrolling usability
So, right now GtkNotebook allows you to change tabs by using the mouse wheel. Once I noticed this and the more I thought about it, it really seems like a terrible feature and one that may be detrimental to usability. I talked to Matthias briefly on irc, and he seemed to agree. He suggested that maybe there's a use for it in the case that you have a ton of notebook tabs open, but I'm not quite convinced. Just wanted to post on the lists and see if people have thoughts on this, otherwise I'm probably going to file a patch to either rip the feature out or at the very least make it so we can disable it. :) / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Last call for missing accessors
On Fri, 2010-02-26 at 16:26 +0100, Christian Dywan wrote: I'd also like to try to get RGBA and decorations stuff into 3.0 if possible. This is about 2.20/2.90, the last API compatible release, not to be confused with 3.0, which would be the fancy feature release according to the plan. Oops, my mistake. I'm aiming for 3.0 for my stuff. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Last call for missing accessors
On Fri, 2010-02-19 at 22:59 -0500, Matthias Clasen wrote: Now, this still leaves us with the question of how to reach a plausible GTK3 release in the fall. I personally want to achieve a few things: - Merge the xi2 work of Carlos - Finish the gdbus work of David - If there is time left, look at the RI stuff I'd also like to try to get RGBA and decorations stuff into 3.0 if possible. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes of the GTK+ Team Meeting - 2009-11-27
On Wed, 2009-11-25 at 17:52 -0500, Matthias Clasen wrote: 7. menu export over D-Bus [bratsche] - useful for ubuntu's application indicators - Quartz backend - menu reflowing - bratsche is working on a general purpose menu proxy - 3.0 material Is this based on proxying actions over dbus, or widgets ? Uh, well both I guess. The original idea was to create a menu proxy interface that's implemented via a GTypeModule, so that module could implement OSX-specific functionality on Mac or it could implement something using dbus. This would modify GtkMenuShell or something so that if it has a proxy module loaded then it would be able to push items to the proxy and listen to events from them. I've got the code for this bootstrapped already, but need to flesh it out some more still. Then I thought this could also be useful for dealing with menubar overflow, so that the menubar could dump additional menus/menuitems into the overflow area and get events on them without having to reparent anything. This shouldn't depend on any system-level features like Quartz or dbus though, so I probably need to generalize the code I've got a little more to make it useful for this case as well. But anyway, since I don't yet have some good code for this that I'm confident enough in to share, and since 2.20 is coming pretty soon, I wasn't planning to try to push for this in the next release. I've still got some work to do for c-s-d/rgba. But after those items are finished my plan was to work on this next and post it for review once I get it further along. General comments right now are of course welcome though (which is why I even brought it up in the meeting). :) / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote: Qt can already link GLib for the main-loop, provide Gtk+ filechoosers, thus moving forward to full VFS support seems natural. Perhaps QtVFS could be thin bindings for GIO, designing another VFS API from grounds up doesn't sound like a good idea, and i guess GIO is portable to the same OSs like Qt. My understanding was that they will link to GLib, but not to GObject. And since GIO depends upon GObject, what you're suggesting doesn't sound very likely to happen. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why do constructors return GtkWidget?
On Wed, 2009-11-04 at 06:23 +0100, Javier Jardón wrote: The question: why is it normal for GTK widget constructors to return GtkWidget and not their real type? For instance I would expect: gtk_menu_item_new () To return GtkMenuItem*. But it doesn't, it returns GtkWidget*. IMHO is much clear that constructors return their real type, instead GtkWidget. But maybe there is a technical reason for this. Almost invariably you're going to be doing something with the return value as a GtkWidget, such as calling gtk_widget_show() on it or packing it into a container. If that method above returned GtkMenuItem* then that guarantees a cast, whereas if it returns a GtkWidget* then it may just get packed into a container and that's the end of it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Status of extended layout branch
On Thu, 2009-10-22 at 21:19 +0200, Maarten Bosmans wrote: On the roadmap [1] the extended layout work is listed as a possibility to go in 2.20. I would really like for that to happen. Especially with the natural size stuff, I would be able to throw out some custom widget code I needed to add in an application of mine to get that behaviour. It seems that there is a really strong use case for this kind of layout. From my understanding of the discussion in the last meeting, it appeared that this will not be targeted at 2.20, but would hopefully make it into 3.0. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Are Out-of-Tree Widgets Second-Class Citizens?
On Fri, 2009-10-02 at 15:27 -0400, Paul Davis wrote:
Sure they do... Cody said apps will have to use public APIs instead
of
accessing struct members directly. I just pointed out that some
things
don't have accessor functions yet, which is a known issue, judging
by
other replies in the thread.
I'm not buying it. One of responses indicated that GTK could use
struct members directly. Clearly, its not intended for apps to do
this. The grey zone are out-of-tree widgets ... are these GTK or
apps? they are surely neither, and the two descriptions conflict here.
hopefully either there is NO direct struct access, even for in-tree
widgets, or some mechanism for out-of-tree-widgets to break the seal,
so to speak.
Widgets will use direct struct access only to their own private structs.
Applications and other widgets (either gtk widgets or otherwise) will
need to use public API.
For example, consider this:
struct _GtkWindow {
GtkBin parent_object;
gchar *GSEAL (title);
...
};
For the moment, anything in gtk+ can access window-title. When 3.0
arrives that will not be possible because the struct will look like:
struct _GtkWindow {
GtkBin parent_object;
};
And inside gtkwindow.c there already exists the following struct:
struct _GtkWindowPrivate
{
...
};
GSEAL'd members such as title will be moved into these private
structures. Anything inside gtkwindow.c has direct access to this
struct, but anywhere else in GTK+ will obviously need to use
gtk_window_set_title()/gtk_window_get_title() since the public member is
gone.
I hope this helps clarify some things.
/ Cody
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Are Out-of-Tree Widgets Second-Class Citizens?
On Mon, 2009-09-28 at 15:12 -0400, Morten Welinder wrote: This is a consequence of the halfway G_SEALing that was done. Insofar G_SEAL is a good idea, it should apply to GTK+ itself, i.e., GtkLabel has no business messing with the internals of GtkWidget, although obviously it should have access to its own internals. (Doing so would also send some of the conversion pain back to people who inflict it on others. That might discourage the habit of breaking APIs and ABIs without good reason.) This is part of the plan for 3.0. I think the original idea was that 2.18 or 2.90 would GSEAL everything, and 3.0 would actually remove those struct members. This obviously means that it won't have access to those members anymore and it will have to use either the public APIs or the members of private structs. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [OSX]Simple Patch
On Fri, 2009-09-18 at 19:46 -0700, John Ralls wrote: I've opened https://bugzilla.gnome.org/show_bug.cgi?id=595641, a very trivial bug and patch which unfortunately breaks the build on OS-X. Could someone with git write privs please apply the patch ASAP? I went ahead and committed this. Normally it's not necessary to email gtk-devel-list when you file bugs though, as people receive emails from Bugzilla. Thanks for the patch. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [patch] constify g_simple_async_result_set_from_error
On Wed, 2009-09-02 at 14:28 -0400, David Zeuthen wrote: Unfortunately there's a lot of const incorrectness in the GLib and GTK + stack - maybe we should fix this in GLib3/GTK3 since it's going to be a new ABI. Just a very minor correction, but at the moment there are no plans for GLib 3. Only GTK 3. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Notes and thoughts on the GTK+ meeting at GUADEC
On Tue, 2009-08-18 at 15:27 -0700, Christian Hergert wrote: One of the items I haven't seen discussed is input validation. Web frameworks such as Rails and Django spent a great deal of time making these easy to work with and I think that it should be considered for gtk+ 3.0. I only took a really brief peek, but this is something I've thought about in the past as well inspired somewhat by the validators that Medsphere had (I can try to dig up the code if you're interested in it, but yours seems to be pretty similar in some ways already). I'll play around with it and look at it in more detail soon. The most obvious thing I see just from peeking at the API is that true/false is not enough information about the result of a validation.. you probably need some way for widgets to be able to provide custom error messages when they fail. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Widget states for 3.0 (and 2.18?)
On Sun, Aug 16, 2009 at 4:35 PM, Thomas Wood t...@gnome.org wrote: I think the current GTK+ states are correct as an enum. They are single user or application activatable states of which the widget cannot be in more than one state at once (normal, insensitive, active, prelight). But then we get workarounds for things like toggle/check/radio buttons because we can't support active and prelight at the same time. Not all combinations of states make sense for different widgets, but I think it's still a more sensible way to store the information. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Widget states for 3.0 (and 2.18?)
On Mon, Aug 17, 2009 at 9:11 AM, Thomas Wood t...@gnome.org wrote: On Mon, 2009-08-17 at 15:01 +0100, Neil Jagdish Patel wrote: Sounds like the checkbox is active (checked), and the user is hovering over it, hence prelight. Not sure that's how it currently works, though. This is not how it works in GTK+. The checked state is indicated by the GtkShadowType passed to the drawing function (gtk_paint_check), where: Right, but I guess that's part of the point of all this. Wouldn't it make more sense if we try to move this type of information into a single location instead of having these kind of work-arounds? I'm not suggesting we change how things work in 2.18, but in 3.0. But I'm bringing it up now because we're adding gtk_widget_get_state() to take over for the GSEAL'd widget-state member. If we avoid this and introduce APIs for each widget state instead then we have time to revise how it works internally for 3.0 without breaking a newly-introduced API. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Widget states for 3.0 (and 2.18?)
In 2.18 there is new API for dealing with widget states:
gtk_widget_get_state
gtk_widget_{get,set}_visible
gtk_widget_{get,set}_has_window
etc..
In the Dublin hackfest, one idea that came up for 3.0 was to switch from
an enumerated GtkStateType to a bitflag type so it's possible to support
multiple states at a time. One of the main reasons for this was related
to state-changing animations, but in general it just seems to make sense
that we can support multiple states on a widget at a time.
So now I'm questioning whether it makes sense to have
gtk_widget_get_state() at all, and perhaps we should only have the
individual get/set methods for each state bit. Then in 3.0 we could
make a switch to a bitflag state system instead of a flat enum.
Any thoughts?
/ Cody
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Widget states for 3.0 (and 2.18?)
On Sun, 2009-08-16 at 22:08 +0200, Kristian Rietveld wrote: As soon as the number of states is extended, I can see that it might start making sense to support multiple states at a time. How would state-changing animations work? From a bitfield I cannot really make up from which to which state to change? Garnacho had done something like this in style-context branch (which isn't in git.gnome.org yet, but which is in github in my and garnacho's repos and which I am trying to get back to work on now).. so the style context stores the widget state and paint_box() pulls the state from the style context rather than passing GtkStateType as a parameter. But so the style context knows how to draw the widget when it's fading between states A and B, it stores it as a bitflag. So the only question remaining is whether or not to have gtk_widget_get_state(). The comment about get/set methods for state bits must be specific to the widget flags ;) I would say that for 3.0 we *need* an accessor for state, and I cannot see a different way to implement it than doing a gtk_widget_get_state() with an enum return value. Later on, it will most probably be deprecated and re-implemented as a transform from the new bitfield to the deprecated enum. So, the current style-context branch has: GtkWidgetState gtk_widget_get_state_flags (GtkWidget *widget); while the current git master has: GtkStateType gtk_widget_get_state (GtkWidget *widget) So, I guess my concern was that I'd like to progress with the style-context branch soon (and I can spell out my related ideas with this in another email soon), but I hate to add gtk_widget_get_state() in 2.18 and then ask to remove it in 3.0 and switch state flags. So the part I wrote about widget flags I actually meant something along the lines of proposing to do: gboolean gtk_widget_state_is_normal(GtkWidget *widget) gboolean gtk_widget_state_is_active(GtkWidget *widget) gboolean gtk_widget_state_is_prelight(GtkWidget *widget) etc.. If we use this type of API instead of gtk_widget_get_state(), then it's compatible with 2.x style flat enums so we could use it in 2.18 (instead of gtk_widget_get_state) and it's compatible with bitflag style storage that I'm proposing we use in 3.0. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: the 2.18 endgame
On Fri, 2009-07-10 at 10:45 -0400, Matthias Clasen wrote: GTK+ 2.90: - Outstanding GSEAL issues have not been resolved. bratsche spent some time on it, but gave up for lack of feedback Here is my proposal: - If people still want to do a 2.90 release in parallel with 2.18, now is the time to step forward and finish the GSEAL work Mitch said he has almost gotten GIMP compiling with GSEAL, minus about ~10 missing functions. So this is actually not quite as far off as it seemed before. The big missing thing at the moment is new API for widget-allocation and widget-requisition, which I will try to push for resolution on soon. The issue with these two was whether the getter should return by value or return by reference. So my plan for this is: 1/ fix up a couple issues in the code rewriter 2/ create new API patches for get-by-ref and get-by-value and get BOTH reviewed by whoever (mitch offered to review) 3/ Use the code rewriter to generate two different patches for gtk+, one for each API style 4/ Post them both and let the bloodbath commence :-) Unless whoever will be making the decision wants to come forward and say which version of the API we're using, then that would save some time. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: how to compile GTK+ from source code in windows
On Thu, 2009-06-25 at 08:45 +0600, Aditi Barua wrote: for last few days i am trying to compile GTK+ source code from Windows. i have trying run GTK+ from my MinGW and msys tools. I issued command ./configure , make and make install, but it shows dependency error. When I glib from source code it shows that pkg-config is not found, but i have a pkg-config directory in my MInGW installation directory. and when I want to install GTK+ it canot detect the previous version of pango, cairo and ATK , it is looking for perticular version of each dependencies library. How can I solve this problem? http://live.gnome.org/Cross%20compiling%20GTK%2B%20for%20Win32 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libsexy and project ridley
Project Giggity! :) On Tue, Jun 2, 2009 at 11:39 AM, Javi javierjc1...@gmail.com wrote: Hello all, I'm new here, so if this list is not the correct place to propose this, please tell me. I'd like to propose consolidate libsexy library [1] into GTK+ in the context of the project Ridley [2]. What currently exist: - A replace for SexyIconEntry by GtkEntry icon functionality (available in GTK+ 2.16) - A replace for SexyUrlLabel by GtkLabel URL functionality (available in GTK+ 2.17) Also, some work is already done on this GnomeGoal [3]. If you agree, I can update the project Ridley page with the new changes. Best regards [1] http://www.chipx86.com/w/index.php/Libsexy [2] http://live.gnome.org/ProjectRidley [3] http://live.gnome.org/GnomeGoals/DropLibsexy -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: global menubars in GTK+
I'm recently working on adding support for client-side window decorations, and this should make it easier to add arbitrary widgets into the window frame area. I've got a branch up, but I was intending to wait until it's further along before I post much about it and ask for review. But just figured I'd chime in and let you know there's some work going on for this. / Cody On Mon, May 25, 2009 at 11:20 AM, chuchi jbarb...@quiter.com wrote: Only one question: Why don't we use the window header for the application menu? IMO the window border has not sense, only a lot of space without any useful feature (only close and, sometimes, the title) It is only another option... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Hackfest around Boston Summit
Do you have any specific things you want to focus on? The main two things I'm interested in working on for Win32 now are: 1/ finishing up csw for Win32 (hey Alex, I'll be working on this when I get back from UDS!) 2/ multithreading support on Win32 gdk backend #1 should be done sooner than that. Sorry for not finishing sooner. #2 is too much to do in a hackfest. :) If you have any other suggestions, let me know. However to be honest, the thing I'd be more interested in focusing on is 3.0 related stuff while we have a bunch of people in one place. On Thu, May 21, 2009 at 1:48 PM, Alberto Ruiz ar...@gnome.org wrote: 2009/5/20 Cody Russell brats...@gnome.org: I'll definitely attend, and I'd like to join a hackfest if one happens. I think I can arrange it to attend as long as enough theming or win32 people are around :-) On Tue, May 19, 2009 at 11:06 PM, Behdad Esfahbod besfa...@redhat.com wrote: Hi everyone, Since the last attempt to organize a GTK+ hackfest failed and not many GTK+ people seems to be going to GUADEC, I wonder whether there's interest to organize a hackfest around Boston Summit. That would make mclasen, ssp, and davidz readily available. What do the rest of the team think? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Hackfest around Boston Summit
I'll definitely attend, and I'd like to join a hackfest if one happens. On Tue, May 19, 2009 at 11:06 PM, Behdad Esfahbod besfa...@redhat.comwrote: Hi everyone, Since the last attempt to organize a GTK+ hackfest failed and not many GTK+ people seems to be going to GUADEC, I wonder whether there's interest to organize a hackfest around Boston Summit. That would make mclasen, ssp, and davidz readily available. What do the rest of the team think? behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib and Symbian?
On Mon, 2009-05-18 at 01:07 +0200, Wim Vander Schelden wrote: A few months back someone reported on this list hat he had ported GLib to Symbian. Has this port been merged, or is there somewhere I can get the branch of the Symbian version? It has not been merged in. The problem was that static globals are not allowed in Symbian, and are used in quite a number of places. Tor posted a possible solution for that [1], but it would require a lot of changes to be made. If Tim or Matthias can comment and mention whether this solution would be acceptable, I'd be willing to try to adapt the gtk rewriter to try to automatically convert the global statics to use Tor's macro. [1]. http://mail.gnome.org/archives/gtk-devel-list/2008-September/msg00029.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Native file chooser dialog on Windows
On Thu, 2009-05-14 at 22:46 -0400, David Cantin wrote: is there a plan or any activities regarding using the native file chooser on the Windows platform ? Like the print dialog does. My feeling is that for such dialogs we should perhaps implement a dialog that looks like the native one (widget/layout-wise), but using gtk+ widgets rather than using the actual native Win32 dialog. I also thought this should be done for the print dialog, and stop using the native one because it sucks. However, I never got around to doing this either. Patches are always welcome (unless tml disagrees with me on this ;) / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Native file chooser dialog on Windows
On Fri, 2009-05-15 at 13:51 -0400, David Cantin wrote: I don't known about this, but from an usability point of view, using native dialog should help applications users because they can use skills they have learned while they were using others applications.. Those details are always sensibles when using a foreign gui toolkit. I will look into what Tim Evans have said. If you implement a dialog using gtk+ widgets that is laid out like the native dialog, has the same accelerators, etc.. then users can take advantage of these skills as you describe and we can use features of gtk and it will look absolutely natural in the application. Unless there are major technical reasons why it's not possible (as it sounds like it was with the print dialog--unfortunate, but makes sense), I think using gtk+ widgets and dialogs instead of native ones is preferable. If the existing gtk dialog is really out of place on Win32, I would prefer a new dialog implemented (with gtk+ widgets) for that platform over invoking the native dialog. That's still not a very ideal solution though, since it means there are two file selection dialogs in gtk+ tree to maintain. But the user experience can be emulated very well already, so I think degrading the developer's experience for zero real user experience advantage is something to be avoided as much as possible. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
3.0-related deprecations
Hi all, gtk+ currently does not build with GSEAL enabled, and I want to remedy this so we can make progress on 3.0. I'm planning to post a large series of patches unless someone has a suggestion for how better to do proceed with this. Right now I was thinking to break this up by widget in order to make it somewhat manageable in terms of review. Does this seem like a good idea, or should I just do all the work in one enormous branch and post for review? I've posted the first patch[1] and it's about 105k, although it shouldn't really be a big burden to review.. it adds 5 new API functions for public struct members that didn't previously have API, otherwise there's not much of interest in it. I used the code rewriter to generate parts of it, but had to insert all the GtkPrivate *priv = GTK_WINDOW_GET_PRIVATE (window) type stuff somewhat manually. Last thing is what to do with this stuff. Assuming someone is able and willing to review it, should it go in git HEAD or should we make another branch for it? My preference is to just put it in git HEAD probably. Thanks, Cody [1]. http://bugzilla.gnome.org/show_bug.cgi?id=582018 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Using By-Value Compound Getters (Re: gtk_widget_get_allocation)
On Wed, 2009-04-22 at 11:37 +0200, Steve Frécinaux wrote: Can't such big repetitive changes be addressed through some user script the way 2to3.py does for python2 - python3 constructs for, say, the planned 3.0 ABI breakage ? Yes, I talked about this in my last email. There's a rewriter that will attempt to fix up C code for the transition. http://github.com/bratsche/clang/tree/gtkrewriter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Using By-Value Compound Getters (Re: gtk_widget_get_allocation)
On Tue, 2009-04-21 at 20:00 +0200, Tim Janik wrote: To sum up our getter options: a) /* force adding lots of helper variables into user code */ void gtk_widget_get_allocation (GtkWidget *widget, GtkAllocation *allocation); b) /* convenient access, no garbage collection problem */ GtkAllocation gtk_widget_get_allocation (GtkWidget *widget); c) /* tie ourselves into always keeping the handed out GtkAllocation * allocated in the widget, which can be different from the * actual widget-allocation. */ const GtkAllocation* gtk_widget_get_allocation (GtkWidget *widget); d) /* force caller to free returned allocation, most often forces * an extra GtkAllocation *helper; variable. */ GtkAllocation* /*freeme*/ gtk_widget_get_allocation (GtkWidget *widget); Thanks Tim, I don't have a strong opinion on this between options A and B. But I am trying to push forward with getting things in shape for a 3.0 branch, and this is a blocker so I'm hoping this thread can lead to a decision. Whichever option is chosen, I can prepare a patch that includes it as well as fixing all instances of foo-allocation to use the new style API. Same applies to GtkRequisition, so once some consensus can be made then I'll prepare branches to fix up all of gtk+ to use the new API. fwiw, I'm not a fan of options C or D. In the past few days I've been doing some work on enhancing Richard Hult's code rewriter. It was capable of rewriting code using option B already, and I've since improved it so that if option A is chosen it can work with that by injecting new variables to the top of the function and calling the get-by-reference accessor. As I go through more of the GSEAL deprecations I can continue to improve the code rewriter to fit new patterns in the API. Right now there are still issues with nested macros, and after an email with Richard he says he believes this is fixable using the latest llvm/clang (which I'm using now, I just need to figure out how to fix this issue using it). So far I've held off really blogging about my improvements to the rewriter until I can solve the nested macro issues, but for anyone interested I have posted my repo to github [1]. I believe we'll also need a gtk_widget_set_allocation() to be used in size_allocate() implementations; I guess the two options are a: set_allocation(GtkWidget*, GtkAllocation*) or b: set_allocation(GtkWidget*, GtkAllocation) So while we're discussing the get method, please consider the set method as well. Thanks everyone, Cody [1]. http://github.com/bratsche/clang/tree/gtkrewriter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_widget_get_allocation
On Thu, 2008-09-25 at 02:02 +0200, Christian Dywan wrote:
* gtk_widget_get_allocation
Removed in 2.14.1
The prototype of this function was not agreed upon among the core
developers. So the decision was deferred to the next Gtk version.
It had to be removed before final API freeze, otherwise it could not
have been changed anymore.
This is rather old, but it never came up again after this so I'd like to
see what thoughts are about how to implement this in C. It was in 2.13
but removed before 2.14 because of disagreement, but I can't find any
public record of the disagreement in gtk-devel-list. Can anyone comment
on what was not liked, or how a better implementation could be made?
For reference, this is the previous implementation:
GtkAllocation
gtk_widget_get_allocation (GtkWidget *widget)
{
static GtkAllocation allocation = { 0 };
g_return_val_if_fail (GTK_IS_WIDGET (widget), allocation);
return widget-allocation;
}
/ Cody
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Deprecation and GSEAL
Hi, I experimented today with using gcc attributes instead of struct member renaming, and wanted to open a discussion of this. I changed GSEAL so that it looks like this: #ifndef GSEAL /* introduce GSEAL() here for all of Gdk and Gtk+ without the need to modify GLib */ # ifdef GSEAL_ENABLE #if __GNUC__ 2 #define GSEAL(ident) __attribute__ ((deprecated)) ident #else #define GSEAL(ident) _g_sealed__ ## ident #endif # else #define GSEAL(ident) ident # endif #endif /* !GSEAL */ I'm not sure if __GNUC__ 2 is the right thing to check for, if anyone knows when the deprecated attribute was introduced then this can be changed. So using this, instead of breaking the build entirely I get a warning such as this: gtkcalendar.c: In function ‘calendar_arrow_rectangle’: gtkcalendar.c:1176: warning: ‘allocation’ is deprecated (declared at ../gtk/gtkwidget.h:219) I think this can make it easier to continue working toward gtk+ 3.0. Would anyone mind if I introduce something like this? Also, for deprecations that are not struct members, we can consider using something like __attribute__ ((section (DEPRECATED))) on gcc (I believe MSVC supports something like this as well, not sure about other compilers). If I understand this correctly, this could allow us to move deprecated functions and structs to other sections and would give some possible performance benefit for applications that don't use them. Is this correct? / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ 3 Roadmap Draft
On Thu, 2009-04-09 at 08:06 -0400, Dr. Michael J. Chudobiak wrote: I'd like to see a gdk-pixbuf that can support something other than 8 bits per pixel. Can arbitrary bpp (or at least 1-32) be made a goal for gtk+ 3, to provide decent support for things like modern raw digital camera files? At this stage, I would say this is not going to make it for GTK 3.0 unless there is some additional manpower to devote to it (read: patches welcome). I think this feature could be implemented without API changes though, so there's no particular reason that it -must- be a 3.0 feature. If someone does the work, it can probably go in at any time. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ 3 Roadmap Draft
On Thu, 2009-04-09 at 01:55 +0200, Tim Janik wrote: Hello Gtk+ Development Community. The need for a Gtk+ 3.0 roadmap has been discussed during several Gtk+ team IRC meetings, at conferences and on other opportunities. So a few months ago, we've set down to collect the input from so many people who have contributed feature requests, ideas, improvment suggestions and procedure suggestions to this. An initial draft was then sent to the core team for initial comments. Hey Everyone, I'm glad we've got this out here now, big thanks Tim! I do plan to get this information organized into the wiki soon, with links to Bugzilla and mailing list threads, who's working on what, what the condition is of various pieces, etc. I should be able to do this very soon, either later this week or during the weekend. Right now I'm preoccupied with the upcoming Jaunty release, but once that is done I think I can devote some time to trying to help get 3.0 on track. I'll post again soon with a progress report. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK 2.90 branch schedule
On Tue, 2009-03-24 at 01:43 -0400, Matthias Clasen wrote: Our plans from last year were aiming for a parallel 2.90 release at the same time. Since I haven't heard an update from the 3.0 drivers, I can't say if that is still realistic at this point. I'll try to ping people from Lanedo and see if there's any way we can get a status update on this. I know they're busy with other things, but maybe someone can be convinced to comment on what is left to be done before 2.90 can be branched. If that information is at least documented somewhere (even just an email to the list) then other hackers can help do some of the work on that. I'd be happy to try to help with this however I can. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ 3.0 Theming API Hackfest Minutes
On Tue, Feb 24, 2009 at 12:30 AM, Alberto Ruiz ar...@gnome.org wrote: * All drawing funcitions to use a cario context and hide GtkWidget and GdkWindow (Strong request from 3rd party toolkits) After thinking some more about this, I'm not convinced that getting rid of the GtkWidget* pointer is a good idea. We should not pass a GdkWindow* handle, and we should pass the cairo context.. but if we don't pass the GtkWidget* pointer then we will potentially lose a lot of things that can be exposed to a theme engine won't we? For example, what if you want to know what is the type of the parent container? We can dump it into the StyleContext under the parent key. But what if we want to know the grandparent container? What if we want to know next/previous widget in the parent container? It's hard to forsee what's useful. On the other hand, what if the widget is NULL? I think the point of removing the GtkWidget* pointer was so someone like Firefox can pass all the useful information through the style context without needing to have an instance of a widget. But I don't think we should bend over backwards to suit their interests if it means restricting our own possibilities and cutting out obvious use cases. Any thoughts? / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk_window_set_skip_taskbar_hint issue
I can test this patch sometime this week, or this weekend. In
particular, we need to verify that this doesn't break the transient
window stuff.
On Wed, 2009-03-04 at 12:49 -0300, Rodrigo Miguel wrote:
Not unless you have a patch to offer?
Well that was working fine until 2.12.x version when somone introduced
the code below:
// ### TODO: Need to figure out what to do here.
return;
and a #if 0 as well
;)
Rodrigo
void
gdk_window_set_skip_taskbar_hint (GdkWindow *window,
gboolean skips_taskbar)
{
static GdkWindow *owner = NULL;
GdkWindowAttr wa;
g_return_if_fail (GDK_IS_WINDOW (window));
GDK_NOTE (MISC, g_print (gdk_window_set_skip_taskbar_hint: %p: %s,
doing nothing\n,
GDK_WINDOW_HWND (window),
skips_taskbar ? YES : NO));
// ### TODO: Need to figure out what to do here.
return;
if (skips_taskbar)
{
if (owner == NULL)
{
wa.window_type = GDK_WINDOW_TEMP;
wa.wclass = GDK_INPUT_OUTPUT;
wa.width = wa.height = 1;
wa.event_mask = 0;
owner = gdk_window_new_internal (NULL, wa, 0, TRUE);
}
SetWindowLongPtr (GDK_WINDOW_HWND (window), GWLP_HWNDPARENT,
(LONG_PTR) GDK_WINDOW_HWND (owner));
#if 0 /* Should we also turn off the minimize and maximize buttons? */
SetWindowLong (GDK_WINDOW_HWND (window), GWL_STYLE,
GetWindowLong (GDK_WINDOW_HWND (window), GWL_STYLE)
~(WS_MINIMIZEBOX|WS_MAXIMIZEBOX|WS_SYSMENU));
SetWindowPos (GDK_WINDOW_HWND (window), NULL,
0, 0, 0, 0,
SWP_FRAMECHANGED | SWP_NOACTIVATE | SWP_NOMOVE |
SWP_NOREPOSITION | SWP_NOSIZE | SWP_NOZORDER);
#endif
}
else
{
SetWindowLongPtr (GDK_WINDOW_HWND (window), GWLP_HWNDPARENT, 0);
}
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Windows dev-* environment
This coming weekend in Boston Summit I was planning to put in the last work needed to get GTK+ WiX installer sources into shape and push them upstream into svn. The idea being to start releasing official gtk.org MSM/MSI installer files in future releases of GTK+. I'm not familiar with the mingw/msys installer stuff at all. Would this be at all useful towards that end? / Cody On Mon, 2008-10-06 at 21:48 +0300, Vlad Grecescu wrote: Hello Gtk developers/users, I was wondering if, now that gtk.org maintains a list of up-to-date Windows packages (binaries, dev-binaries and sources) it would be possible to make an installation kit out of them. Something integrated with an mingw/msys installer, for the developers. The problem is that there should be some kind of textual descriptions of the latest versions/latest URLs for both the binaries and the sources, on-line. Something like http://gtk.org/gtk.ini [latest] glib 2.18.1-2 http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.18/glib_2.18.1-2_win32.zip; http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.18/glib-dev_2.18.1-2_win32.zip; http://ftp.gnome.org/pub/gnome/sources/glib/2.18/glib-2.18.1.tar.bz2; gtk 2.14.3 http://...; http://...; http://...; etc.. So the name of the package, the version, the URLs for binary/dev/sources. (have a look at http://www.mingw.org/mingw.ini for the inspiration) This would allow an installer to: automatically install runtime or developement files, *and automatically upgrade everything*. It would also allow 64-bit compiling in the future:D Well, what do you think? I can start myself an nsis project with this if we agree. Thanks, Vlad Grecescu ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Windows dev-* environment
On Mon, 2008-10-06 at 23:37 +0300, Vlad Grecescu wrote: I suppose MSM/MSI installers would be great I suppose for Visual Studio users! But would they install the pkg-config files, and the other libs for linking with mingw-gcc too? Yes. For the moment the binaries would be mingw-compiled dlls, and the installers would include all headers and .pc files. The MSM/MSI projects will be useful to people compiling with mingw. At such time that we can easily and consistently build with Microsoft compiler, we'll sit down and figure out what our options are. I don't know if we need separate installers, or just have the MSMs include both mingw and VS binaries. That's a problem for another day though. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Windows dev-* environment
On Mon, 2008-10-06 at 23:47 +0300, Vlad Grecescu wrote: I think most of the people that use Gtk+ on Windows also use autoconf/automake (think Inkscape, Geany, Pidgin). Unfortunately they also use parralel Makefiles for win32.. having the opportunity to compile unmodified (vanilla) Gtk+ software in msys/mingw seems like a good idea to me. Also, Visual Studio for new projects is another target, but I think the difference is weather you're mainly developing on WIndows and regulary checking if it works on Linux/*nix etc. or the other way around. I'm not thinking in terms of the people that use Gtk+ on Windows right now. They do what they do because there aren't many options, or because they're developing Linux applications primarily but want to build them on Windows. Building applications using autoconf/automake/make on Windows is extremely slow and painful, so in my opinion it makes for a very sub-optimal development environment, but if you're primarily developing on Linux it is tolerable for just building Windows binaries. But when I compile the Gtk+ stack, I cross-compile with mingw on Linux because it is probably 10 times faster (no, I didn't actually measure the time I'm just taking a wild guess). I think once the MSM/MSI projects are upstream, they'll be useful for people developing on Windows with mingw. But mostly I think they'll be useful for distributing GTK-based applications. The problem, as I see it right now, is that there are a lot of applications that each bundle GTK in their own way; they each have to figure out how to make installers to distribute their apps. You end up with five copies of Gtk all over your system, all different versions. I hear rumors that some apps do some custom patching of Gtk on Windows, but I'm not sure how true that is. I think (and hope) that by encouraging an official installer we can minimize that type of behavior, and encourage bug reports into Bugzilla, etc. Also people can stop focusing on the distribution problems so much and just focus on writing awesome applications with Gtk+. (if you want to grab my current MSI build, I've posted it at http://bzr.medsphere.com/~cody/installers/ - let me know if it's working okay for you with mingw and stuff if you like.. it's not the latest version of Gtk+ yet.. I'll update it this weekend in Boston). The Visual Studio support that we want to add later is really about trying to make Gtk+ more appealing to developers who want to think about cross-platform applications. I think we want to increase the appeal of Gtk+ to people outside the ones you listed above. It's awesome that Pidgin, Evolution, GIMP, etc all run on Windows. But when new developers come along and think, I want to write an application.. I'm a Windows user, but some of my friends use MacOS X and/or Linux so I might as well try to write something in a portable UI toolkit. This is the type of developer that I think we can begin to attract if we provide Visual Studio support. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes of the GTK+ Team Meeting - 2008-09-23
On Thu, 2008-09-25 at 15:07 -0400, Morten Welinder wrote: If all you really want is to change the defaults for box packing, then why isn't that all you are proposing? It would be a simple 1-line patch to gtk_box_pack_start_defaults, if I understand things right. If all you do is change the defaults then you risk breaking some applications silently. It seems that this would be -vastly- more difficult for application developers to track down and fix than if they have the benefit of compile-time warnings or errors, even though there are relatively few places people are using default box-packing probably. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes of the GTK+ Team Meeting - 2008-09-23
On Tue, 2008-09-23 at 18:31 -0400, Morten Welinder wrote: + massive deprecation at branch for 2.90 + everyone agrees ACTION: mitch files bugs with the various patches This late-cycle deprecation will make it hard to write code that is kosher in both the old and the new world. That is really a bad idea, even compared to the regular deprecation pain. What do you mean by late-cycle? My understanding was that this was intended for the upcoming 2.90 branch. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: subwindow-less Gtk+ and offscreen windows
On Sat, 2008-08-02 at 21:35 +0200, Alexander Larsson wrote: * Some operations require an X window id, for example: + glXMakeCurrent() so that you can draw into a window with opengl. You can still draw to the toplevel window, but you can't have GdkOffscreenWindow automatically clip the opengl drawing calls (i think). Would it work if there were a new GL widget that took care of glXMakeCurrent() using the toplevel X window and did glViewport() internally using the widget's coordinates or something? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: subwindow-less Gtk+ and offscreen windows
On Mon, 2008-08-04 at 23:57 +0200, Lieven van der Heide wrote: I don't think that will work, since the user of the gl widget may want to change the viewport as well, and the coordinates in glViewport are always absolute, not relative to the current one. Yeah, I thought about that after I posted it. Too bad. I do agree with Alexander that it would make things a lot more flexible. I only wouldn't know if it's possible without braking API/ABI Well, since breaking API/ABI is already expected for 3.0 then it's not such a big deal. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: subwindow-less Gtk+ and offscreen windows
On Mon, 2008-08-04 at 18:02 -0400, Paul Davis wrote: I do agree with Alexander that it would make things a lot more flexible. I only wouldn't know if it's possible without braking API/ABI Not only flexible, but anything that moves us away from XMoveWindow for GtkLayout and GtkScrolledWindow is a Guaranteed Good Thing. i wish i could say i was in a position to put 26hrs a day into implementing Alexander's proposal, because i love it. note that there cannot be *that* far to go - the quartz backend doesn't use child windows at all (Quartz/Cocoa has no such concept). I would love to hack on something like this, but I think I'm not yet familiar enough with some of these low-level things to do it very effectively. I'll take a look at the Quartz backend and see how it is working. I've been wanting to do so anyway. ;) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: subwindow-less Gtk+ and offscreen windows
Yeah, you can render your scene to an FBO.. but then you're back to the original problem, aren't you? You have to display it to your window at the widget's position and clipped by the widget's dimensions. Or am I missing something obvious? On Tue, 2008-08-05 at 02:17 +0200, Lieven van der Heide wrote: For OpenGL, something we could do is let the OpenGL widget's user render to an offscreen buffer, and when he's done, blit the whole result to the target window. This way, all the stuff like overlapping windows will still work with opengl widgets, like with any other widget. It may have a slight performance impact, but I think it will be really minimal if the blitting is done by the hardware (so no cpu reading back from video mem). Of course we'll have to do a performance test before we implement something like this, but I think it might work. On Mon, Aug 4, 2008 at 11:57 PM, Lieven van der Heide [EMAIL PROTECTED] wrote: I don't think that will work, since the user of the gl widget may want to change the viewport as well, and the coordinates in glViewport are always absolute, not relative to the current one. But anyway, would it really be a problem to just have an X window, only for widgets that really need it, and let normal GTK widgets, like text fields and event boxes do their own clipping? I do agree with Alexander that it would make things a lot more flexible. I only wouldn't know if it's possible without braking API/ABI On Mon, Aug 4, 2008 at 11:33 PM, Cody Russell [EMAIL PROTECTED] wrote: On Sat, 2008-08-02 at 21:35 +0200, Alexander Larsson wrote: * Some operations require an X window id, for example: + glXMakeCurrent() so that you can draw into a window with opengl. You can still draw to the toplevel window, but you can't have GdkOffscreenWindow automatically clip the opengl drawing calls (i think). Would it work if there were a new GL widget that took care of glXMakeCurrent() using the toplevel X window and did glViewport() internally using the widget's coordinates or something? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gtk+-win32] Repainting problem
On Mon, 2008-06-16 at 17:06 -0700, Sohail Somani wrote: Using GTK+-2.10 on Windows XP, I noticed a repainting bug in one of my gtk apps and reproduced it with gtk-demo.exe of gtk 2.10. I've attached the screenshot of the problem. It happens when I move the window overlapping the gtk app around, in this case mspaint. Note that the mspaint titlebar is still visible where it overlapped previously. Resizing or forcing Windows to invalidate the demo app's window fixes the problem. I'd like to know why this is happening and more importantly how to fix it or work around it. I think I know why it happens but I'd like to be wrong. Yeah, we're aware of some kind of repainting problems on the Win32 backend. This is probably the same one that's in Bugzilla [1]. Is it happening when you drag one window over another, or how are you reproducing it? [1]. http://bugzilla.gnome.org/show_bug.cgi?id=153567 / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Steps to get to GTK+ 3.0
On Wed, 2008-06-04 at 19:15 +0200, Jean-Yves Lefort wrote: I thought that GObject was meant as a general-purpose object system for C, rather than as a GTK+-specific utility library. I suppose I misunderstood. I fail to see how any of this discussion should change your perception of GObject. This is a discussion about GTK's usage of GObject, but your own objects can continue to use it in whatever way makes the most sense to you. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Print preview widget
I was thinking that it would be nice if there was an integrated print preview widget in GTK+, that would be available cross-platform and wanted to check with people here before I commit much time to this. Right now we're spawning another process to do this, and I think an integrated widget would be much nicer. Thoughts? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
On Wed, 2008-04-16 at 19:54 +0200, Mathias Hasselmann wrote: Am Mittwoch, den 16.04.2008, 12:46 -0500 schrieb Cody Russell: I was thinking that it would be nice if there was an integrated print preview widget in GTK+, that would be available cross-platform and wanted to check with people here before I commit much time to this. Right now we're spawning another process to do this, and I think an integrated widget would be much nicer. I fully agree with you. I talked to pbor on irc briefly.. he wrote the print preview widget for gedit, and he seemed to think there would not be any problem with relicensing that code so that it could be ported into gtk+. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
The way I'm thinking of this, using the integrated print preview widget would be up to the application.. if the developer wants to continue using an external process (e.g., evince or Preview.app) or maybe wants to use their own print preview widget, they should be able to. On Wed, 2008-04-16 at 14:19 -0400, Yu Feng wrote: Hmm, What about embedding different PDF viewers into the widget, on different platform? Or else will it be a lot of redundant work? On Wed, 2008-04-16 at 12:46 -0500, Cody Russell wrote: I was thinking that it would be nice if there was an integrated print preview widget in GTK+, that would be available cross-platform and wanted to check with people here before I commit much time to this. Right now we're spawning another process to do this, and I think an integrated widget would be much nicer. Thoughts? ___ 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
While you guys are talking about website stuff again, on a side note I want to mention the information about IRC stuff on the webpage: http://www.gtk.org/development.html This page mentions #gtk-devel as a place where team meetings occur, but there has been a lot of traffic to this channel recently by people looking for help with general gtk+ stuff. I wasn't sure where to file a 'bug' about this, so I posted to Bugzilla here: http://bugzilla.gnome.org/show_bug.cgi?id=523725 Today Kris gave me ops so I could at least change the /topic to point people to #gtk+ but we really should make some mention of #gtk+ on the webpage somewhere so that people just know the right place to go from the beginning. Can I commit this patch to gtk-web, or should it be changed some first, or should I just let you guys take care of it? / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Release download locations
The gtk.org website's download section links to ftp://ftp.gtk.org/pub/gtk/2.12/ and it appears that Matthias posts the releases to http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.12/ Going by the website, the latest release shown on the front page is 2.12.3, and the latest release on ftp.gtk.org is 2.12.6. So, two things: Should the download URL just be switched to ftp.gnome.org? And do we need someone to update the news on the front page when releases are made? I don't mind volunteering for this for now if it's something that needs doing. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Merging libsexy widgets
On Fri, 2008-01-11 at 14:38 +, Bastien Nocera wrote: I don't think we need to discuss libsexy in a meeting, let alone a hackfest. Libsexy IIUC is a staging area for widgets, similar to libegg. If that's the case, it cannot be merged at once and needs to be done for each widget/functionality separately. That kind of development is already happening and has a natural home: bugzilla and this list. What needs to be done is for someone to open a bug about merging their favorite libsexy widget into Gtk+, prepare a patch, reply to maintainer concerns, refine it, repeat until merged. I think, to start with, we should see which widgets are available in there, which ones are obsoleted by features in GTK+ itself (such as tooltips for single lines in treeviews), and file bugs for those we'd want to merge. I also got comments on my blog post about merging libsexy, and I responded with about the same thing that Behdad said, which is that it should be evaluated on a per-widget basis. So as you suggested I'm filing bug reports for widgets that seem merge-worthy: http://bugzilla.gnome.org/show_bug.cgi?id=508809 http://bugzilla.gnome.org/show_bug.cgi?id=508810 Other widgets are SexySpellEntry, but that would involve new dependencies that I think gtk+ doesn't want, SexyTooltip, and SexyTreeView. As you said, I think those are no longer necessary. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I'd like to contribute
On Fri, 2007-12-28 at 18:35 -0800, Bobby Walters wrote: I would like to contribute a little to the project. Is there anything I could do? Let me know how to get started, and who to talk to please. Hey Bobby, Welcome! Maybe start off by letting us know more of what kind of work you're interested in doing. If you're interested in programming, the best thing to do is to start off by searching through Bugzilla [1] for bugs to work on fixing. Or better yet, you might look at the GtkLove bug list [2] for starting places. You could also work on documentation or test/demo programs. Maybe someone else can give a better idea of where to get involved with that. [1]. http://bugzilla.gnome.org/buglist.cgi?query=product%3Agtk%2B [2]. http://live.gnome.org/GtkLove Cheers, Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: nmake build fixes for glib.
On Wed, 2007-12-12 at 17:43 +0100, Lieven van der Heide wrote: Hi, I made some fixes for the nmake makefiles and the win32-fixup.pl script. glib, gmodule, gthread and gobject build fine now. gio and tests don't build yet, but I don't think that's related to the makefiles. Also, right now (in svn), it assume that libiconv and gettext are in a folder called ../get-text-0.40.10 and ../libiconv-1.7 These versions don't seem to be outdated anyway, but instead of changing it to the current version, I just changed it to plain ../gettext and ../libiconv, because I don't think there's really one specific version you want to link to, just as long as it isn't too old (I assume they try to stay API and ABI compatible with older version). This is really awesome! I'll test it out hopefully later today. In the mean time, would you mind opening a Bugzilla bug for this and attaching your patches to it? CC me on the bug, or email me the bug# too. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Wed, 2007-11-14 at 22:01 +0100, Alexander Larsson wrote: I think this is similar to a problem we have in gtkmm. When a GTK+ widget implements an extra GInterface, we can't just add a base class to our existing C++ class, because that would break ABI in C++. So we just don't wrap it, and tell people to use the C API when they need to use that part of the API. It doesn't happen much, luckily. Wow. Combine this no new interfaces with the C# no new methods in interfaces and its clearly obvious that we can't make all bindings happy and still make progress. Yeah, but C++ doesn't have a real notion of interfaces to begin with so it seems like any implementation is going to feel non-native to that language. So if you have to pick one of the above options, it seems like it would be a huge benefit to languages like Java and C# to go with the no new methods in interfaces option, and let bindings for languages without native interfaces deal with it in whatever way they can. If GObject supported multiple inheritance, it wouldn't make much sense to enforce a pattern of using that feature according to constraints set by C# or Java bindings. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Logo (was Re: GTK+ Website Review)
On Wed, 2007-10-10 at 09:25 +0100, Martyn Russell wrote: Mathias Hasselmann wrote: Am Montag, den 08.10.2007, 11:36 +0200 schrieb Kristian Rietveld: On Sun, Oct 07, 2007 at 04:22:09PM +0100, Alberto Ruiz wrote: Have anyone seen this[0] one? I think it's a great improvement over the original one. And as Xan said, we avoid the aqua-and-rounded-corners-mac-and-web20-like look and feel :) [0] http://en.wikipedia.org/wiki/Image:GTK.svg Vectorized the old logo and tried to apply Tango colors and gradients to it. Not satisfied with the result - seems I've lost any art-foo I probably never had. For what's worth I am attaching the result nevertheless. Guess we should get one of the real Tango wizards to work on the logo. Hi Mathias, Yea I really like this icon. Does anyone have any objections? If not, I will consider using it on the website. I actually really like the one on Wikipedia better. I think the main thing is the text color.. I like the black text much better than the white. But this is also out of the context of where it will be seen, so perhaps on the website it would be better looking with white letters, I don't know. Just my $0.02. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Logo (was Re: GTK+ Website Review)
On Sun, 2007-10-07 at 13:30 +0200, Christophe Dehais wrote: ok guys, one more cube here. again, no color, just to see how the shapes look like. feel free to bash the idea. I think the shapes look very nice. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Status of the GTK+ 2.12.0 release
I think that Matthias is still on vacation. On Fri, 2007-09-07 at 17:31 +0200, Vincent Untz wrote: Some of the release team members are a bit worried that GTK+ 2.12.0 is still not out. We're three days away from the GNOME hard code freeze, and it would have been great to have at least another unstable release for the GNOME RC of this week (we're guilty there too, since we should have mailed you about it). What are the current plans for the release? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib build fixes for visual c++
Hi Lieven, Look under build/win32/dirent/ in the glib source, there is a dirent there. / Cody On Thu, 2007-07-26 at 23:11 +0200, Lieven van der Heide wrote: Hi, I made some buildfixes for glib under visual studio. It's mostly related to gdir.c, which required the dirent.h file, which did seem to be present in the win32 versions of gcc, but not in visual c++. I used the code from http://www.softagalleria.net/dirent/index.en.html, and modified it a bit so that it works with utf-8. I think it's a good idea to just keep this file in the glib repository. Greets, Lieven van der Heide ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ configure can't find cairo-pdf
On Sat, 2007-06-09 at 11:51 -0400, Owen Taylor wrote: The ^A is actually a bash problem on Windows (or maybe specifically with the msys version). It was a couple of years ago that I ran into it, so I don't remember the details, but it was something involving the newline stripping behavior of backticks (``) when run on the output of pkg-config. I also don't remember how I worked around it ... I think I wrote a wrapper script around pgk-config that either added or removed a newline. You might want to check that you have the newest versions of msys and mingw as a first step. Try this script and save it as pkg-config.sh: #!/bin/sh if pkg-config $@ /dev/null 21 ; then res=true else res=false fi pkg-config $@ | tr -d \\r $res Then set an environment var PKG_CONFIG=/path/to/pkg-config.sh ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
On Tue, 2007-05-29 at 00:08 +0100, Martyn Russell wrote: I agree. I did look into frames, etc to get around this, but that causes more problems than it solves. The main problem here is that the FAQ is generated, so we would need some post-docbook fix up script to do something here. It is not insurmountable, adding just the line to use the CSS formatting makes quite a difference. The other option, was to have the FAQ only on the website and not have an SGML document - it really depends on how necessary it is to be able to create the FAQ in PDF, HTML, and other formats with the docbook tools. If possible I would rather it was just online. Yes, I agree. When I am looking for a FAQ, the first place I look is on the website. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK Win32 scripts
On Fri, 2007-05-11 at 12:48 +0100, Alberto Ruiz wrote: Cody, may I put there my jhbuildrc and moduleset for automated cross compiling with mingw32? The reason I asked tml for his scripts is to improve them so we can have a transparent and automated way to release the windows builds using the current tools (jhbuild) without having to retrieve scripts and binaries for several places and having to follow a large list of instructions with tweaking and configure options. This is almost done. Also, I'm looking forward to research on ways to release .msi and .msm packages for Windows, which is something lots of people are asking for for several reasons. The main one is taht .msi files can handle versioning issues. If anyone has experience and/or suggestions on this issues, I encourage you to take a look at the jhbuildrc and the moduleset here: http://osl.ulpgc.es/~arc/gnome/gtk/ Yeah dude, that's awesome! Feel free to put your stuff up on the wiki. It sounds like a big improvement over mine. I'm excited by all the GTK-Win32 related activity recently. :) / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
Lieven, thanks very much for your work on that patch. It is greatly appreciated! On Fri, 2007-04-27 at 10:58 +0200, Lieven van der Heide wrote: thx:) On 4/27/07, Cody Russell [EMAIL PROTECTED] wrote: Yeah, I committed to svn a couple days ago. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Fri, 2007-04-20 at 12:02 +0200, Sven Herzberg wrote: Well, isn't the right way to go the cairo path and make the communication of cairo and the GPU faster (that's improve Xrender, the drivers etc.)? As this needs to be improved for a GPU based GTK anyway you won't get any advantage by adding this new level of platform independence to GTK (which is already available in cairo). What I was envisioning is more along the lines of having the widget system drawn as texture-mapped vertices in the GL, with the textures being drawn by Cairo and such. Some textures are repeatable, which means once it is rendered one time then even upon configure events you never need to render it again (except maybe for widget state changes). Also, it could be theoretically possible to implement layout managers as vertex shader programs. These are just some ideas. I'm not sure how this compares to doing the current system + Glitz surfaces. When you use Glitz, how is it drawing the surfaces? If you have 20 different Glitz surfaces in your window, does each one get rendered with a separate GL pass? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Thu, 2007-04-19 at 18:51 +0200, Carlos Garnacho wrote: There have been several discussions about getting a canvas into GTK+, being the last one in the GTK+ meeting at Fosdem [2], where one of the conclusions was that we needed to gather the candidates on one side and the desired feature set for a GtkCanvas on another. - Integrate tightly GTK+ and the canvas, even making GtkWidgets specialized canvas elements drawn with a certain layout in a canvas, see Havoc's proposal [3] Thoughts? Opinions? This is awesome. I want to propose another thing, which I think is especially worth considering if we move in the direction of implementing widgets and layouts using the canvas: I'd like the canvas system to be generalized enough that we can have multiple implementations of it, in the same way that GDK allows us to port to Win32 or MacOSX. In particular, I think we could have an implementation that is much like what most of the canvases are doing today where everything is software rendered.. but I also think we could do an OpenGL backend, an OpenGL|ES backend, and possibly a Direct3d backend if there were a reason to do one. I've been putting some thought into the idea of a GPU-based GTK, and when Havoc first mentioned going the route of having a canvas-based widget system I became instantly interested in that because I thought it was the perfect opportunity to go the GPU route. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
On Sun, 2007-04-01 at 21:46 +0200, Lieven van der Heide wrote: I made a new version which should work with tabs at any side, and also, the stretched packing seems to work fine now. My patch is still against revision 17429. Maybe someone can test it, and if it works I can merge it with cody's changes (It will probably conflict if I do an update right now). On my computer, GPS looks fine aswell. If you still have those problems, could you make a screenshot of it? I will have a look at the notebook source to see how the rectangle is calculated, and try to match it in the theming code. Sorry, I overlooked this message until now and just found your latest patch. I will review this patch really soon, and if it looks okay I'll get it committed to svn. Thanks a lot! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
On Sun, 2007-04-01 at 11:03 +0200, Arnaud Charlet wrote:
When the tabs are on the left, right, or bottom then the results are
worse.
Right, that's the main issue with this patch. Strange that I get not so
good results even with top tabs.
The bug #399253 is, I think, a separate issue.. that happens
when the notebook receives expose events or something. As it is right
now (without your patch), the tabs look pretty decent when they're first
drawn or when the entire widget exposes.. but when it receives partial
expose events it gets really screwed up. I tried looking into that, but
didn't put much time into it.
In the mean time, I've reverted the draw_extension function in msw_style.c
to what it was in Gtk+ 2.8.20 to avoid this very annoying (to us) glitch,
seems to be good enough for now, and certainly better than having bad redraws.
Arno,
Instead of doing that, can you test this patch and see if it solves
these problems for you? Let me know if you have any problems. If not
I'll try to commit this to svn soon.
/ Cody
Index: msw_style.c
===
--- msw_style.c (revision 17574)
+++ msw_style.c (working copy)
@@ -2466,18 +2466,12 @@
}
else if (real_gap_side == GTK_POS_BOTTOM)
{
- x2 = x;
- y2 = y + (state_type == GTK_STATE_NORMAL ? 0 : notebook-tab_vborder);
+ x2 = 0;
+ y2 = 0;
w2 = width;
h2 = height - (state_type == GTK_STATE_NORMAL ? 0 : notebook-tab_vborder * 2);
- target = window;
-
- /* If we are currently drawing the right-most tab (any state)... */
- if (widget-allocation.x + widget-allocation.width - border_width == x + width)
- {
- x2--;
- w2--;
- }
+ pixmap = gdk_pixmap_new (window, w2, h2, -1);
+ target = pixmap;
}
if (xp_theme_draw (target, tab_part, style, x2, y2, w2, h2, state_type, NULL /*area*/))
@@ -2526,6 +2520,19 @@
h2--;
}
}
+ else if (real_gap_side == GTK_POS_BOTTOM)
+ {
+x2 = x;
+y2 = y + (state_type == GTK_STATE_NORMAL ? 0 : notebook-tab_vborder);
+w2 = width;
+h2 = height - (state_type == GTK_STATE_NORMAL ? 0 : notebook-tab_vborder * 2);
+/* If we are currently drawing the right-most tab (any state)... */
+if (widget-allocation.x + widget-allocation.width - border_width == x + width)
+ {
+x2--;
+w2--;
+ }
+ }
gdk_draw_pixbuf (window, NULL, pixbuf, 0, 0, x2, y2, w2, h2, GDK_RGB_DITHER_NONE, 0, 0);
Index: xp_theme.c
===
--- xp_theme.c (revision 17574)
+++ xp_theme.c (working copy)
@@ -746,6 +746,7 @@
case XP_THEME_ELEMENT_LINE_H:
switch (state)
{
+ default:
/* LHS_FLAT, LHS_RAISED, LHS_SUNKEN */
ret = LHS_RAISED;
break;
@@ -755,6 +756,7 @@
case XP_THEME_ELEMENT_LINE_V:
switch (state)
{
+ default:
/* LVS_FLAT, LVS_RAISED, LVS_SUNKEN */
ret = LVS_RAISED;
break;
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
On Sun, 2007-04-01 at 11:20 -0500, Cody Russell wrote:
On Sun, 2007-04-01 at 11:03 +0200, Arnaud Charlet wrote:
When the tabs are on the left, right, or bottom then the results are
worse.
Right, that's the main issue with this patch. Strange that I get not so
good results even with top tabs.
The bug #399253 is, I think, a separate issue.. that happens
when the notebook receives expose events or something. As it is right
now (without your patch), the tabs look pretty decent when they're first
drawn or when the entire widget exposes.. but when it receives partial
expose events it gets really screwed up. I tried looking into that, but
didn't put much time into it.
In the mean time, I've reverted the draw_extension function in msw_style.c
to what it was in Gtk+ 2.8.20 to avoid this very annoying (to us) glitch,
seems to be good enough for now, and certainly better than having bad
redraws.
Sorry, here's a better version of that patch. The last one leaked a
pixmap.
/ Cody
Index: msw_style.c
===
--- msw_style.c (revision 17574)
+++ msw_style.c (working copy)
@@ -2466,18 +2466,12 @@
}
else if (real_gap_side == GTK_POS_BOTTOM)
{
- x2 = x;
- y2 = y + (state_type == GTK_STATE_NORMAL ? 0 : notebook-tab_vborder);
+ x2 = 0;
+ y2 = 0;
w2 = width;
h2 = height - (state_type == GTK_STATE_NORMAL ? 0 : notebook-tab_vborder * 2);
- target = window;
-
- /* If we are currently drawing the right-most tab (any state)... */
- if (widget-allocation.x + widget-allocation.width - border_width == x + width)
- {
- x2--;
- w2--;
- }
+ pixmap = gdk_pixmap_new (window, w2, h2, -1);
+ target = pixmap;
}
if (xp_theme_draw (target, tab_part, style, x2, y2, w2, h2, state_type, NULL /*area*/))
@@ -2526,10 +2520,23 @@
h2--;
}
}
+ else if (real_gap_side == GTK_POS_BOTTOM)
+ {
+x2 = x;
+y2 = y + (state_type == GTK_STATE_NORMAL ? 0 : notebook-tab_vborder);
+w2 = width;
+h2 = height - (state_type == GTK_STATE_NORMAL ? 0 : notebook-tab_vborder * 2);
+/* If we are currently drawing the right-most tab (any state)... */
+if (widget-allocation.x + widget-allocation.width - border_width == x + width)
+ {
+x2--;
+w2--;
+ }
+ }
gdk_draw_pixbuf (window, NULL, pixbuf, 0, 0, x2, y2, w2, h2, GDK_RGB_DITHER_NONE, 0, 0);
- if (real_gap_side == GTK_POS_LEFT || real_gap_side == GTK_POS_RIGHT)
+ if (real_gap_side == GTK_POS_LEFT || real_gap_side == GTK_POS_RIGHT || real_gap_side == GTK_POS_BOTTOM)
{
g_object_unref (pixmap);
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
On Sun, 2007-04-01 at 18:44 +0200, Arnaud Charlet wrote: Instead of doing that, can you test this patch and see if it solves these problems for you? Sure. Let me know if you have any problems. If not I'll try to commit this to svn soon. This indeed solves the issue nicely for me as well, and is clearly better than reverting to the 2.8.20 implementation (the tabs are properly highlighted for instance). Awesome, thanks! I'll get Dom to review it as soon as he has time then I'll commit it to svn for the next release. Maybe we can get Lieven's patch working for all cases as well, because I liked the end result he got for top-oriented tabs. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
On Sat, 2007-03-31 at 21:29 +0200, Lieven van der Heide wrote: I made a patch for the windows theme engine, that adjusts the clip rectangle of the notebook buttons a bit. Now it resambles the native windows look more closely, and it fixes the gap between the left edge of the page and the left edge of the button, when the leftmost page is selected. Hi Lievan, I'm glad someone is finishing this up! The results look pretty good when it's at the top. I know Arnaud said he didn't get the same results as your screenshots, but I do get the same results (when the tabs are at the top). When the tabs are on the left, right, or bottom then the results are worse. The bug #399253 is, I think, a separate issue.. that happens when the notebook receives expose events or something. As it is right now (without your patch), the tabs look pretty decent when they're first drawn or when the entire widget exposes.. but when it receives partial expose events it gets really screwed up. I tried looking into that, but didn't put much time into it. I've got a binary that I used to test notebook tab rendering when I was working on the last patch, but I'm not sure where I put the source code for it. I'll post the .exe to the following URL: http://www.gnome.org/~bratsche/notebooktest.exe / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Sudden Tango changes in trunk
On Wed, 2007-03-28 at 20:00 +0100, Alex Jones wrote: This wouldn't work too well. MS Windows just doesn't have much of an icon style to begin with. Microsoft seem to rework their icons for each new Windows release, causing a lot of visual disparity among all the applications targeted towards the platform. In short, creating special MS-Windows icon theme wouldn't do much good. Microsoft have pretty decent style guidelines for every release... better than GNOME's and Gtk's! Where is this magical style guide of theirs, and why don't they follow it themselves? They have a long history of releasing products that don't visually fit into the Windows environment: - Office 2000, XP, 2003 - IE7 - Visual Studio.NET, 2003, 2005 - Windows Media Player 9, 10 I realize I'm getting way off the topic of icons here, but I think stylistically GTK does a better job trying to fit into its environment than most of Microsoft's software does already. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Smooth Scrolling
http://bugzilla.gnome.org/show_bug.cgi?id=103811 On Tue, 2007-03-27 at 07:37 +0100, Alex Jones wrote: A few years ago there used to be a distributor patch in Gentoo to enable this, and it was sweet. What happened, here? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Dragging the text in a text entry issue
On Thu, 2007-03-15 at 16:57 +, Ross Burton wrote: On Thu, 2007-03-15 at 11:37 -0500, Cody Russell wrote: On Wed, 2007-03-14 at 16:32 +0200, Itai Bar-Haim wrote: Hi. I was looking through the API, but I couldn't find a way to disable dragging of the text. Is it possible at all? Look at the gtk_drag_???() functions. For example, to disable an entry from receiving text drags you would do gtk_drag_dest_unset (widget). There is the question of why you want to disable dragging of text. If I was using your application and wanted to drag text but couldn't, I wouldn't be happy. I actually had to do it the other day at work. It's sort of hard to describe.. but I had an entry over a treeview, and the entry was used basically just for searching the treeview. Dropping of text into the entry was not useful, and was ending up causing problems so I just disabled it. It was a sort of unusual situation I think, and usually there's not a good reason to disable drag-and-drop. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: directx gdk backend?
On Sat, 2007-02-10 at 15:15 +0200, Tor Lillqvist wrote: Is it a lot of work? Since MS is putting all of its efforts into DirectX now, would it make sense to move to that for drawing? Maybe. Are you volunteering? Prior to DirectX 10 (that is, everything before Vista) all DirectX calls are happening over COM interfaces and are relatively slow. Unless you batch everything together, you'd most likely end up slowing things down on Windows 2000/XP for most users. I'm very interested in exploring the possibilities of using a GPU for accelerating GTK, but I think this is the wrong way to do it. If you're going to make the effort to do it at all, it should be done on a larger scale than just the Win32 backend. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
