Re: GIO performance improvements
Am 15.11.2011 17:49, schrieb André Gillibert: I'm not sure this mailing list is the correct place to post GLIB-related requests, but I didn't find a glib-devel-list. Yes it is. If you have patches, even if not yet perfect, you should file (a) bug(s) in Bugzilla. Keep in mind, patches will go into git master, not previous versions, usually. You should have a look at Benjamin's patches in Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=663570 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
Am 29.09.2011 12:24, schrieb Kean Johnston: If you are happy limiting yourself to a single platform and don't need some the magic that comes with GIO, feel free to use stat(). It's not UNIXWARE, SCO OpenServer, AIX, Solaris, MacOS X, Windows, Linux, FreeBSD, OpenBSD, NetBSD, Minix, HP-UX ... did I miss any platforms? I'll consider myself limited. How about a test case that first times stat recursively over a large folder and then the same with g_file_query_info. If you could run that on some typical hardware you're working with, I think that should be quite interesting. Personally I regularly talk to people who use my code on obscure systems I don't have, maybe never heard of. And I really need practical examples of what they are doing and how it's performing. It doesn't help to emphasize your point if there is no way for the other person to understand it. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About gsettings aborting on unkown schemas
Am Mon, 30 May 2011 21:13:16 -0400 schrieb Havoc Pennington: Hi, On Mon, May 30, 2011 at 8:37 PM, Shaun McCance sha...@gnome.org wrote: But I want to point out that my point was never that GLib should behave like a language with exceptions. Just that it should let bindings in those languages behave like they should. I agree that would be ideal if you were optimizing for non-C. But the only way to do that is to replicate the entire API currently lacking an error indicator, with a second _with_error version of every function. Some functions may happen to have some other ad hoc way to do an error (like returning NULL) but it'd just be some subset without rhyme or reason. If you aren't prepared to do the _with_error() replication of the API, then doing it here and there at random is kinda weird. Either it's needed or not, it isn't needed here and there at random. This is a great argument. There was a mistake. It made you notice the API is inconsistent, so you suddenly insist that GLib can't be improved further without rewriting all the functions I would personally prefer it if you were honest and would say that your opinion is set, instead of giving bogus arguments. Including the one about g_error. Then nobody would continue wasting time on trying to explain his point of view to deaf ears. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: OOP in C (A SIMPLE BUT EASY LIBRARY. NOT USEFUL FOR Professional APP)
Am Tue, 15 Feb 2011 20:55:13 +0800 schrieb Mike: HI, ALL. I HAVE A FRIEND. HE WIRTES A OOP LIBRARY FOR C, LOOKS NICE AND LIKE CPP (USEFUL FOR SIMPLE APP. Lack of FUNCTIONAL FOR Professional APP). URL (RAR FORMAT): http://code.google.com/p/ooc-gcc/downloads/list IF YOU CAN READ CHINESE (OR USE TRANSLATOR SUCH AS GOOGLE TRANSLATOR), YOU CAN VISIT THIS PAGE: http://pingf.is-programmer.com/posts/24088.html SORRY FOR MY POOR ENGLISH. IF YOU DON'T LIKE IT, PLEASE REPORT YOUR REASON TO GOOGLE CODE, MY FRIEND WILL THANK YOU. :-) Hey Mike, this list is about GTK+ development. GObject is already an object-oriented layer for C. Also please note that writing in all uppercase is very disturbing to read :-) -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_window_move can't move GtkWindow to negative position.
Am Fri, 21 Jan 2011 07:23:49 + (GMT) schrieb 박보람 boram1288.p...@samsung.com: Using gtk_window_move, I give negative value to GtkWindow. (e.g. gtk_window_move (GTK_WINDOW (window), -100, -100)) But it's not moving to the negative position I given. Hey Boram, I looked at your test case. I don't think it's a bug, but expected behaviour. If you create a window of type GTK_WINDOW_TOPLEVEL, ie. 0, the window manager usually ignores attempts to move it before it is visible. So nothing happens. You can either show the window first, and then move. Or you use GTK_WINDOW_POPUP instead, which gives you full control over the window and the window manager will not interfere with you. That's how popup menus work for example. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
Am Tue, 7 Dec 2010 07:16:25 -0500 schrieb Paul Davis p...@linuxaudiosystems.com: On Tue, Dec 7, 2010 at 2:44 AM, Martin Nordholts ense...@gmail.com wrote: The problem to be solved is not How do we modify GTK+ to make it as easy as possible to invoke nested menu items several times in a row in Ardour, but How can we redesign the Ardour UI so users don't have to invoke nested menu items several times in a row to use the software. This is an overly focused and specialized view of the question. The major distinction between a menu and a dialog is that menus typically *do* close after a click, whereas dialogs generally require a series of 0,.N clicks on possible action proxies, and then one or more confirmative steps to actually close the dialog. So the question is whether there is a place for menu semantics in which only an umodified left click closes the menu, and some other click still activates the item but leaves the menu open, OR whether the claim is that any interaction with a presentation of a set of multiple actions should be done via a dialog with an explicit close operation. We *could* push all the operations in the current region context menu, for example (right click on a region - Select region name - menu with 20+ items) into a dialog for that region, but it would 1 mouse motion+drag or the use ctrl-w to every single action activation for anything on that menu when you only do a single action. Space on tick or radio leaves the menu open. I think for a state change, it would be sensible to have an analogous mouse-based action. A right-click could be just that. Anything that goes beyond toggling would be a bad distortion of menu semantics in my opinion. And keep in mind this is undiscoverable, not counting accidents. You should document it if it is an important part of the common workflow. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: right click *in* a menu
Am Tue, 7 Dec 2010 09:38:55 -0500 schrieb Paul Davis p...@linuxaudiosystems.com: We *could* push all the operations in the current region context menu, for example (right click on a region - Select region name - menu with 20+ items) into a dialog for that region, but it would 1 mouse motion+drag or the use ctrl-w to every single action activation for anything on that menu when you only do a single action. Space on tick or radio leaves the menu open. I think for a state change, it would be sensible to have an analogous mouse-based action. A right-click could be just that. Anything that goes beyond toggling would be a bad distortion of menu semantics in my opinion. RiscOS didn't think so, all those years ago :) I suppose I'd need to actually try it in a situation where it is useful. I've never used RiscOS. And on all other systems I can think of a menu is distinctly floating and temporary. And keep in mind this is undiscoverable, not counting accidents. You should document it if it is an important part of the common workflow. context clicking is equally undiscoverable and has an honorable history and usage. I'm painfully aware. But it is so universally available that advanced users usually know about it even if they switched operating systems. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Questions about GTK3
Am Wed, 8 Sep 2010 07:31:58 -0400 schrieb Matthias Clasen matthias.cla...@gmail.com: On Wed, Sep 8, 2010 at 7:10 AM, Christian Dywan So a possible idea would be to turn GtkEditable into a clipboard interface, where entry specific features are removed. Which features do you consider entry-specific ? As far as I'm concerned, the editable interface could just be implemented by GtkTextView and its derivatives, as well as the other widgets you mentioned. What I mean is functions which operate on characters and positions, as opposed to GtkTextIter. I filed a bug report to implement GtkEditable in GtkTextView in any case. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib: love to have GIO::GLocalFile::canonicalize_filename in glib
Am Tue, 03 Aug 2010 18:24:33 +0900 schrieb Yasushi SHOJI ya...@atmark-techno.com: Hi, just noticed that GLocalFile have a static function to canonicalize a file name, canonicalize_filename(). the function does not depends on gio funcs at all. So, wouldn't it be nice to have in glib, say gutils.c::g_path_canonicalize() ? would you take a patch if I create it? See https://bugzilla.gnome.org/show_bug.cgi?id=111848 -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
Am Mon, 28 Jun 2010 17:59:47 +0100 schrieb Emmanuele Bassi eba...@gmail.com: On Mon, 2010-06-28 at 18:43 +0200, Christian Dywan wrote: and, again, there is this false impression that deprecation is akin to removal. [...] you can either #undef G_DISABLE_DEPRECATED for the files that use these particular data structures, or copy gcompletion.[ch] in your project; since these files haven't been really changed in a while, the maintenance burden for projects is not heavy. One has to wonder where this false impression is coming from. Is it by any chance because there are loads of bugs and wiki pages about using G_DISABLE_FOOBAR and not relying on deprecated code? it's a maintainer's choice to make your application rely on deprecated code; all the bugs and wiki pages in the world are there in an informational capacity only: I cannot get on your repository and just rip code out of your application. That is irrelevant. You expressed surprise that developers think they are highly encouraged to avoid deprecated code and do their best to keep building without it. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk3 planning
Am Fri, 25 Jun 2010 14:12:00 -0400 schrieb Colin Walters walt...@verbum.org: On Fri, Jun 25, 2010 at 12:50 PM, Matthias Clasen matthias.cla...@gmail.com wrote: Sure, we could continue to shoehorn features in to 2.x and it will increasingly get harder, and the bugs will increasingly get harder to fix. What we need to *realistically* look at is what big features that aren't going to make 3.0 now will be able to land later without ABI breaks. Luckily some of us started to plan that already months ago, otherwise we would really be in trouble now. There was never any requirement to land everything we could ever want into the very first 3.0 release. Fwiw, a big motivation for all the sealing business was to make it possible that GTK3 _can_ move faster and incorporate more new stuff without the need for disruptive ABI breaks. Can say davidz's RI stuff land post-3.0? Can Full support for MPX and multitouch devices. Can Revamp/rewrite the entire theming system.? I think the answer to all of those is no. While I know some MPX code landed, as far as I'm aware none of the widgets have been updated to possibly take advantage of it. Do we really believe that we can do that (easily) in an API compatible way? Yes. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why is GCompletion deprecated
Am Mon, 28 Jun 2010 17:28:47 +0100 schrieb Emmanuele Bassi eba...@gmail.com: On Mon, 2010-06-28 at 17:58 +0200, Salvatore De Paolis wrote: On Mon, 28 Jun 2010 14:49:48 +0100 Emmanuele Bassi eba...@gmail.com wrote: The issue isn't really about deprecating some code but instead not providing the alternative (look at QT for an idea, they always provided a compat library when it was necessary) This will be again the same picture as it has been with GTKCTree stuff: force application developers to waste time on changing something that actually just works and give room for new bugs while implementing the same functionality in a different way. and, again, there is this false impression that deprecation is akin to removal. [...] you can either #undef G_DISABLE_DEPRECATED for the files that use these particular data structures, or copy gcompletion.[ch] in your project; since these files haven't been really changed in a while, the maintenance burden for projects is not heavy. One has to wonder where this false impression is coming from. Is it by any chance because there are loads of bugs and wiki pages about using G_DISABLE_FOOBAR and not relying on deprecated code? -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New widget proposal: GtkLiveSearch
Am Sat, 12 Jun 2010 19:30:52 +0200 schrieb Xavier Claessens xclae...@gmail.com: Hello, I've been working on the HildonLiveSearch widget you can see on N900. This is the entry you see when typing on the keyboard to filter your contact list for example. Felix Kaser and I ported that widget to Empathy's main window. The code is in git master[1]. I would like to propose that widget to become GtkLiveSearch[2]. So EmpathyLiveSearch right now seems to be smart matching function + standalone inline search Regarding the smart matching, I think it is a bad idea to hardcode a particular algorithm with no way to override it. Rather it should be a function that can be used. Maybe it is also useful for, say, entry completion, that way? And as for the standalone inline search, I would personally be hesitant as long as the only real user is a tree view. New API for the same feature doesn't strike me as attractive in sight of GTK+ 3.0 with its many valid deprecations. I would suggest if somebody has a non-tree view use case it makes a lot more sense to consider it. Also to confirm that it actually is convenient to use with other widgets. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Breaking things in git master...
Am Mon, 14 Jun 2010 10:36:42 +0200 schrieb Laurent Wan dev@free.fr: In Google Reader it's as simple as clicking Add a Subscription and then just pasting http://git.gnome.org/browse/glib/log/ into the field. For other readers you probably need a ATOM/RSS URL or something technical like that - I don't know. FWIW, I think cgit has RSS/ATOM feeds somewhere, maybe it would be nice if we showed links to those much like gitweb does, e.g. http://git.kernel.org/?p=linux/hotplug/udev.git;a=summary David Thanks for your reply, As i didn't want to depend more on google software, i give a try with Thunderbird. When you are about to create the Atom feed, you juste have to enter: http://git.gnome.org/browse/glib/atom/?h=master or http://git.gnome.org/browse/glib/atom/?h=glib-2-24 if you want to track master or glib-2-24 commits. I found theses URLs in the source of http://git.gnome.org/browse/glib/log/ HTML page. I guess we could have the links you talked about by adding stuff like a class=atom_logotitle=log RSS feedhref=browse/glib/rss/?h=master view-source:http://git.kernel.org/?p=linux/hotplug/udev.git;a=rssRSS/a a class=rss_logotitle=log Atom feedhref=browse/glib/atom/?h=master view-source:http://git.kernel.org/?p=linux/hotplug/udev.git;a=rssAtom/a to the pages footers. For what I want, Midori shows a news feed icon and when I click on it, I see the URL of the feed. I expect other proper web browsers do something similar. But making it more visible with a link at the bottom of the page would seem like a good idea. Indeed news feeds are often overlooked. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ige-mac-integration: New version with Cocoa interface available.
Am Tue, 18 May 2010 08:33:45 -0700 schrieb John Ralls jra...@ceridwen.us: On May 18, 2010, at 7:34 AM, Nicolas Dufresne wrote: Le mardi 18 mai 2010 à 09:26 -0400, Matthias Clasen a écrit : Not really. Its up to you and us working together on making this happen... therefore, I'd love to hear some comments from you or other OS X developers on the GApplication branch: [...] I also think it's worthwhile to maintain the separation between GLib and Gtk with respect to graphical elements like menus. In the case of the features in GtkOSXApplication, the menu and dock manipulations belong in a GtkApplication-derived class, while bundle functions, notifications (sort of an IPC gsignal), and events (another sort of IPC gsignal) belong in a GApplication-derived class. This is what is happening right now on this very list and why it is vital that you join the discussion. Try the gapplication branch and see how well it fits your case :-) -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Deprecations for 3.x
Am Wed, 12 May 2010 09:29:29 +0200 schrieb Cody Russell brats...@gnome.org: I think it would be kind of nice to deprecate GtkStatusbar. It's one of the more useless widgets we have, imo. It basically serves two purposes: 1/ Pushing and popping text messages. This is a really terrible way to communicate information to users, imo. 2/ Corner resize grips. I want to add support for this directly to GtkWindow anyway. It just consumes precious vertical space without giving us much. / Cody I am curious, as GtkStatusbar is used in every second application, about your suggestions on how to replace it in the typical use cases. -- ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkNotebook cleanup
Am Thu, 8 Apr 2010 22:23:03 +0930 schrieb James Moschou james.mosc...@gmail.com: Hello, I'm trying my hand at the GtkNotebook cleanup bug (96834) and had a few questions. The old code had a lot of if (!notebook-focus_tab) stuff going on and I thought that since focus_tab is now synced to the current page that I could just do if (!notebook-cur_page) to achieve the same thing. But I was wondering if there were any cases where focus_tab may have been null, and cur_page not? Also I'm finding it hard to simplify the code without regressing some functionality. For instance there's a thing where middle clicking the arrow button while a tab label is focused causes the focus to move to the child widget of the page... or something. I'm finding it easier to just get rid of all this stuff than to try and rework it into this new paradigm. Is this OK? Hey James, I suggest you do this in separate patches because some applications do rely on inconsistent behaviour, short of an alternative. And if something changes behaviour, it would be better to consider that for the 2.90 branch where we could draw a clean line and say now GtkNotebook behaves differently in the following aspects. Apps need to be tested for the coming major release anyway. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Minutes of the GTK+ Team Meeting - 2010-03-23
= Minutes of the 2010-03-23 GTK+ Team Meeting = - Client-Side-Windows on Win32 needs work, but currently it is unclear who can step up to do it. Alberto Ruiz suggested he might help out. - GdkRectangle, GdkRegion, gdk_cairo_rectangle, gdk_cairo_region should be mapped to cairo_rectangle_t and cairo_region_t, in the 2.90 branch - Goals for 2.90 . Remaining accessors (GDK, GtkStyle) . Move all struct members to private structs . XInput2 . Client-Side-Decorations . (Optional features such as RI or Extended Layout) . Release around September - Create a branch for 2.22 . Cherry-pick new accessors, deprecations, bug-fixes . Will be API-compatible with 2.90 It was concluded that it would be sensible to merge 2-90 with master, effectively replacing it, as soon as Matthias decides to branch off the stable 2.20. And additionally API enhancements will be cherry-picked to the 2.22 branch. See also http://live.gnome.org/GTK+/Meetings ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: on replacing GTK_WIDGET_* with gtk_widget_get_* INSIDE gtk+
Am Wed, 17 Mar 2010 15:55:23 +0100 schrieb Christian Persch c...@gnome.org: Hi; recently there's been a flood of changes in gtk+ where *internal* uses of GTK_WIDGET_* macros accessing the widget flags were replaced by the new public accessors. Why is that? I thought the GSEAL work was intended to only seal *outside* access to the flags, while library-internal code could continue to use the shortcuts macros. These changes mean that every time I rebase my gtk tree, I have some patches that fail to apply because of this; I guess I'm not the only one that this is happening to! Regards, Christian Hey Christian, the plan is indeed to remove the old macros entirely, not just hide them. Fortunately these replacements are almost done, so you should have survived most rebasing trouble. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: on replacing GTK_WIDGET_* with gtk_widget_get_* INSIDE gtk+
Am Wed, 17 Mar 2010 17:10:02 + schrieb Emmanuele Bassi eba...@gmail.com: On Wed, 2010-03-17 at 17:49 +0100, Christian Dywan wrote: recently there's been a flood of changes in gtk+ where *internal* uses of GTK_WIDGET_* macros accessing the widget flags were replaced by the new public accessors. Why is that? I thought the GSEAL work was intended to only seal *outside* access to the flags, while library-internal code could continue to use the shortcuts macros. These changes mean that every time I rebase my gtk tree, I have some patches that fail to apply because of this; I guess I'm not the only one that this is happening to! the plan is indeed to remove the old macros entirely, not just hide them. Fortunately these replacements are almost done, so you should have survived most rebasing trouble. the obvious downside is that now every single accessor will have to go through the type check in the argument validation - and a function call. not really good, performance wise. I'll just set aside any comment on why we should have sealed the flags member, since it would be pointless - the change already happened. this might be the kick in the arse needed to get type checking down to a minimal cost, but still it might not be a good thing to dump on unsuspecting audience without a warning at least in the release notes. it would be good to get some numbers, and possibly a fallback for internal usage. or, if the numbers are that bad, reconsider sealing the flags. ciao, Emmanuele. Hey Emanuelle, it is not quite the same as externally calling a function, but you are right in terms of additional type checking. I don't know if the overhead is noticible in practise, but I agree it is worth looking into, as it came up before and shouldn't be ignored without argument. I might see if I find some time to look into it. It should be straightforward to add a private header that re-defines these functions as macros. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkNotebook scrolling usability
Am Wed, 10 Mar 2010 16:50:04 -0600 schrieb Cody Russell brats...@gnome.org: 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 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 :-) Regards, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Usability] GTK+ at the UX Hackfest
Am Mon, 8 Mar 2010 19:27:40 + schrieb Alberto Ruiz ar...@gnome.org: 2010/3/8 Matthew Barnes mbar...@redhat.com: It would also be useful in Evolution for opening attachments... Are projects like Firefox or Thunar willing to use gmenu or gnome-desktop as a dependency? I remember talking about this issue with Michael Ventnor from mozilla and he said that if such a widget was there in Gtk+ they would use it. gmenu belongs to the mixed lot called gnome-menus, which overlaps with garcon. At least Xfce wouldn't use it then. Me thinks either it should be a freedesktop.org library or in GTK+. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: When deprecating, always say what the replacement is.
Am Tue, 23 Feb 2010 23:13:51 +0100 schrieb Murray Cumming murr...@murrayc.com: On Tue, 2010-02-23 at 22:36 +0100, Michael Natterer wrote: On Tue, 2010-02-23 at 19:59 +0100, Murray Cumming wrote: No, Deprecated: 2.20: Do not use it. is not good enough. As a matter of fact, it is. There is not supposed to be any replacement for the stuff that says Do not use it. Everything that has a replacement is however documented. But Do not use it does not even make that clear. The reader has no idea whether it is something that should never have been used (and why not) or something that has a replacement. It shouldn't take much empathy to realize that, or to realize that documentation _must_ have a problem if someone says it's unclear. We can do better. The few Don't use it comments in GTK+ usually indicate that it is questionable why someone would try to use a function in the first place. In this case I don't know what someone would use flags for. If you need to test a value such as visibility or sensitivity, you normally use the specific macros. As far as I'm aware at least. Can you give an example? Then I'd say pointing that out certainly can't hurt. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
Am Thu, 26 Nov 2009 14:35:36 +0100 schrieb Alexander Larsson al...@redhat.com: This was previously discussed here, but was sort of hidden in a technical discussion so it got no replies. I'm starting over in order to reach a wider target for the discussion. I'll start with the proposal and then explain the reasons for it: Starting with next glib release: * libgobject links to libgthread * g_type_init() starts with: #ifdef G_THREADS_ENABLED if (g_thread_supported()) g_thread_init (NULL); #endif You mean this: if (!g_thread_supported ()) g_thread_init (NULL); Just to prevent confusion. Since the above snippet wouldn't work. :) ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GConverter commited
Am Tue, 24 Nov 2009 11:16:19 +0100 schrieb Alexander Larsson al...@redhat.com: On Tue, 2009-11-24 at 04:22 -0500, Behdad Esfahbod wrote: Anyway, since I was one of the people wanting this, I thought I'd share my first experiences with it. I'm curious what other people would like to do about GConverters for other compression schemes. The code is simple enough that I don't really mind keeping it in Yelp. But if other people are doing this stuff, maybe we should talk about how to share code. Yeah, sharing things like this is good, but we don't want every app to link to these libraries, and even gio plugins are not free (even when not used) since we load them once to see what extension points they support. A gmodule-level caching scheme is in order... Pango and gimp can use them too... Yeah, that would probably be a good idea. Its not a lot of code either, nor is it very complicated, so maybe cut and paste is not such a horrible idea. Well, we know where that would lead :). I'm generally pro sharing code where it makes sense. But I'm also of the opinion that there are cases where cut and pasteing code make sense. Some people dismiss cut and paste as never being the right thing, but it has several advantages that makes it sometimes useful. For instance, cut and pasting small amounts of code may be prefered to adding large library dependencies (that are otherwise unused). It also lets you untangle otherwise complex dependencies if things at different layers in the system want to share a small bit of code. However, in this particular case if we had the plugin system cache i wouldn't mind having a basic uncompression GConverter that used magic sniffing and modules for extending to new forms of compression. I have to wonder how significant the overhead can be, if you consider the huge amount of modules in GVfs which come in one big package. ;) Just my 2 cents, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Unsubscribe
Am Mon, 9 Nov 2009 03:28:57 -0800 schrieb Shashidhara B shashidhar...@mphasis.com: Hi, Kindly unsubscribe from the mailing list. Regards, Shashi Please use http://mail.gnome.org/mailman/listinfo/gtk-devel-list like everyone else to unsubscribe yourself. You managed to subscribe on your own as well, didn't you? Regards, Christian ___ 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-10-20
Am Wed, 21 Oct 2009 00:55:43 +0100 schrieb Alberto Ruiz ar...@gnome.org: 2009/10/21 Emmanuele Bassi eba...@gmail.com: = minutes for the 2009-10-20 meeting = 1. schedule post 2.20 [bratsche] - aim for 3.0 after 2.20 - list of things to deprecate, including signals and properties - figure out a diagnostic mode [discussion degenerates into pet features] - cross all items from the 3.0 readiness wiki page ACTION: decide along with the GNOME 3.0 schedule First, thanks a lot ebassi for putting the minutes together and sorry for not attending, the meeting clashed with some stuff I couldn't quit, glad you're doing another meeting next week! Regarding the list of things to deprecate, I'm wondering, if we deprecate stuff post 2.20, does that mean that we're going to carry with those deprecated symbols during the 3.0 cycle? My guess is that anything that should be deprecated have to be deprecated for 2.20, so that we can remove it? Or maybe I'm missing something here, please clarify :-) Yes, we need to deprecate in time for 2.20 if we want to remove symbols, anything that comes later will survive 2.90. So if you can think of specialized or rarely used API, please add it to the agenda and/ or file a bug report. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 2.90 branch
Am Tue, 29 Sep 2009 18:47:48 +0200 schrieb Christian Dywan christ...@lanedo.com: Am Tue, 29 Sep 2009 13:04:54 +0200 schrieb Javier Jardón javierjc1...@gmail.com: Hello, I've read here [1] about the creation of a GTK+ branch for GTK+ 2.90/3.0 development after 2.14 has been released. GTK+ 2.18 has been released and I think that no branch was created, is there any plans to create that branch soon? Best Regards [1] http://live.gnome.org/GTK%2B/3.0/Tasks#Q0 Hey Javier, I actually started to look into doing that this week. I think we have resolved all but a handful of sealing/ accessor issues at this point, and at least some of the GTK+ hackers seem to share the sentiment. So I think it's a good time. So I guess I should try to organize this a bit, and see if I can attract some bears to the honey. I started a local branch gtk-2.90, where I began to remove deprecated classes and functions which basically is #Q1. Question: do others agree, and can I push the branch to git.gnome.org so everybody can join the effort? For the record, I pushed the gtk-2.90 branch now, it almost compiles, that is I need to fix GtkInputDialog which uses deprecated functions and a few tests also still use old API. Anybody is welcome to help out, preferrably poke here or poke me in #gtk+ (kalikiana) before so we don't end up duplicating work. I rebased the branch once so far, Emanuelle offered to do that in the future. There's also http://live.gnome.org/GTK+/3.0/Tasks in the wiki. What I did so far is #Q0, creating the branch, and #Q1, removing deprecated code. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkIconView Pixbuf rendering
Am Tue, 06 Oct 2009 16:13:00 +0530 schrieb Amol Kulkarni amolgkulka...@gmail.com: Hi All, In newer versions of Gtk+[After GIcon addition] user is not able to add mixed images in IconView that is file path plus named icons. User will prefer named icons over file path to have consistent look and feel but all required icons may not be available in icon theme so he may need to use mix of these in some cases. Are such scenarios discouraged or is their any workaround available? thanks for your time. Hey Amol, can you be more specific about what you are trying to do? How are you loading pixbufs into the model? Are you manipulating cell renderers? If you have a small code example that worked in older GTK+ releases but not with 2.18 that would be great. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 2.90 branch
Am Tue, 29 Sep 2009 13:04:54 +0200 schrieb Javier Jardón javierjc1...@gmail.com: Hello, I've read here [1] about the creation of a GTK+ branch for GTK+ 2.90/3.0 development after 2.14 has been released. GTK+ 2.18 has been released and I think that no branch was created, is there any plans to create that branch soon? Best Regards [1] http://live.gnome.org/GTK%2B/3.0/Tasks#Q0 Hey Javier, I actually started to look into doing that this week. I think we have resolved all but a handful of sealing/ accessor issues at this point, and at least some of the GTK+ hackers seem to share the sentiment. So I think it's a good time. So I guess I should try to organize this a bit, and see if I can attract some bears to the honey. I started a local branch gtk-2.90, where I began to remove deprecated classes and functions which basically is #Q1. Question: do others agree, and can I push the branch to git.gnome.org so everybody can join the effort? A GTK+ meeting would probably be a good idea, to plan 2.20/ 2.90. Emmanuelle, do you want to revive the meeting? ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.18.0 released
Am Wed, 23 Sep 2009 12:32:34 +0200 schrieb Sebastian Rittau srit...@jroger.in-berlin.de: Hello, On Wed, Sep 23, 2009 at 01:17:07AM -0400, Matthias Clasen wrote: Changes in the file chooser [...] - File sizes are shown by default Could you point me to the rationale for this change? Thanks, - Sebastian Hey Sebastian, if I remember correctly, the reasoning was that switching the option is fairly hard to discover and the dialogue is usually more than wide enough to hold the column while still showing the file names. I do unfortunately not recall the bug ID, but you should be able to find it in bugzilla. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Webkit-gtk and MacOSX
Am Wed, 26 Aug 2009 10:45:00 +1000 schrieb Davyd Madeley da...@madeley.id.au: On Tue, 2009-08-25 at 21:44 +0200, Kristian Rietveld wrote: On Tue, Aug 25, 2009 at 9:35 PM, Xan Lopezx...@gnome.org wrote: WebKit is the native layer on top of WebCore offered by each port for their platform, so the answer to that is: yes, WebKitGTK provides GObject APIs which are all specific to it. Right, so another question: does the GObject API contain stuff that is not possible in the native layers for other platforms? Surely you'll want the GObject API for programming in your GObject-based toolkit. Otherwise you're effectively using a different widget and kill your portability. So surely the solution is WebKit-GTK+ on top of a system WebCore. I guess what would be attractive is to take the other existing system components used by WebKit on MacOSX and use those where possible too. WebCore has no stable API and no public symbols, it is built statically. As soon as the framework is upgraded it would break. Further more WebKitGTK exposes libsoup to the API, so things like proxy server or HTTP cookies can be accessed. This would break completely since the Mac WebKit doesn't use this. As an exception JavaScriptCore is identical in features in all ports of WebKit. If anything, you could look into making that work independent from the rest of the framework. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Webkit-gtk and MacOSX
Am Tue, 25 Aug 2009 19:40:04 -0700 schrieb Brian J. Tarricone br...@tarricone.org: On 08/25/2009 06:04 PM, John Ralls wrote: Thank you both for hashing this out for me. I'll persevere with getting Webkit-Gtk to build with quartz, then. I'm not sure I agree that it's not that big: WebKit.framework clocks in at 78M. Presumably WebKit.framework includes WebCore. Would it be possible to build WebKit-gtk against the system WebCore (instead of bundling your own), and just distribute the WebKit-gtk wrappers? WebCore has no public interface. And it evolves so fast, feature wise, that maintaining a system-webcore version of WebKitGTK+ would be more than merely plugging it in. Plus, as mention already, WebKitGTK+ is exposing libSoup to provide functionality such as HTTP cookies, authentication and proxy server support. The Mac WebCore doesn't have that because it uses different code paths for the networking. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Deprecate tab-pack child property in notebook for 2.18
Am Mon, 24 Aug 2009 17:29:18 +0200 schrieb Carlos Garnacho carl...@gnome.org: Hi! On lun, 2009-08-24 at 14:34 +0100, Alberto Ruiz wrote: Hello everyone, as you may know, the notebook implementation is a bit of a nightmare, most of its problems comes from the fact that it allows packstart/end on its notebook tabs. I don't think I've ever seen this being used in any Gtk+ app (or in any other toolkit fwiw), and for those out there using it, they deserve no mercy. So my proposal is to deprecate this child property for the 2.x series, so that we can get rid of it by 3.0, (meaning 2.18?). This would allow a long overdue cleanup in the notebook codebase and make it more manageable to include other features (tab sliding animations ala Google Chrome as an example?) I quite agree here, I remember Xan complained about the cyclomatic complexity of the notebook [1] between others, which means it's insanely hard to get anything done on the notebook layout/rendering that covers all possible cases. Other sources for this complexity are ltr/rtl and scrollable tabs, of course we can't get rid of that but IMHO tab-pack is quite senseless and deprecating it will help removing a lot of cruft in the future. [1] http://blogs.gnome.org/xan/2007/10/25/the-cyclomatic-horror-from-outer-space/ Don't forget gtk_notebook_set_tab_label_packing () and gtk_notebook_query_tab_label_packing (). For what I want, secondary tab labels in a notebook are as odd as right-aligned menu items. Go for it! ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GCancellable hints
Am Mon, 24 Aug 2009 18:14:11 +0200
schrieb Jannis Pohlmann jan...@xfce.org:
On Mon, 24 Aug 2009 17:03:02 +0100
Richard Hughes hughsi...@gmail.com wrote:
In the last few weeks I subclassed GCancellable into a
ZifCancellable object, which allowed me to complete a personal
project. I now want to do the same for PackageKit, and think
perhaps the functionality should be abstracted and pushed upstream
into Glib as it's the second time I'm doing this. I'm asking for
your opinions to see if it's the sort of thing you want in Glib.
For me, a task can often do actions that cannot be cancelled for
some time (when dealing with hardware and calling out to other
programs), so for PackageKit, the install method:
* depsolves (user can cancel)
* downloads a package (user can cancel)
* installs the package using rpm/apt/etc (user CANNOT cancel)
* updates databases (user can cancel)
And in the UI, we want to make the [Cancel] button insensitive for
some of the actions rather that letting the user click it and wait
for ages with no feedback.
The only functionality that ZifCancellable adds is two methods:
void zif_cancellable_set_hint (GCancellable *cancellable, gboolean
can_cancel); gboolean zif_cancellable_get_hint (GCancellable
*cancellable);
And added the hint-changed signal
void hint_changed_cb (GCancellable *cancellable, gboolean
can_cancel, gpointer user_data)
Better names welcome. Anyway, I would appreciate your opinions on
this and if it would be accepted upstream.
Hm, I wonder if 'hint' isn't a too generic name for this. Maybe
something like 'active' and g_cancellable_{get,set}_active() would be
better. However, I wonder if you couldn't simply use the newly added
g_cancellable_{connect,disconnect}() methods for this. Make
the UI element(s) insensitive, disconnect the job from the
GCancellable and when you want the task to become cancellable again,
reverse this.
What you did with ZifCancellable clearly is more convenient though,
I'd agree with that.
I think you should go a step further to make this more than a generic
boolean, call it g_cancellable_get_unstoppable, and let
g_cancellable_cancel return_if_fail if you try to cancel something you
shouldn't cancel.
Incidentally a signal isn't needed, notify::stoppable is all you need.
ciao,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GZip{In,Out}putStream in GIO?
Am Fri, 31 Jul 2009 15:07:10 -0700
schrieb Brian J. Tarricone bj...@cornell.edu:
On 07/31/2009 01:59 PM, Mikkel Kamstrup Erlandsen wrote:
2009/7/31 Brian J. Tarriconebj...@cornell.edu:
On 07/31/2009 05:48 AM, Mikkel Kamstrup Erlandsen wrote:
From the looks of it, it should be straight forward to write
GZip{In,Out}putStream classes based on zlib
I'd say call it GCompressed{In,Out}putStream and have it either
auto-detect the compression type, or have a param in the API to
specify from an enum (or both). People can add support for other
types of compression as time goes on.
The prime benefit of having dedicated classes over your approach is
having syntactically ensured that you are indeed working with
GZipped buffers. Personally I like that, but this is of course 100%
subjective.
Well, sure, but otherwise you can end up with classes for gzip,
bzip2, zip, 7zip, rar, etc. That alone is 10 extra classes, and I'm
sure there are other compression schemes people might want classes
for. That sounds messy to me.
Having a constructor for a generic class that takes a parameter for
the compression type would give you what you want, assuming it's set
up so it returns an error if the content you pass it doesn't appear
to be of the selected type.
I guess it doesn't really matter either way. You could even
implement GCompressedInputStream as a sort of class cluster that
returns a (private) subclass depending on the compression type, or
have all (public) classes be a subclass of a
GCompressed{In,Out}putStream class, and for all operations (except
for construction) you'd call methods on the superclass.
And I think there's a benefit to support format auto-detection if the
developer doesn't care what format the input is in. That's possibly
a little more difficult to do with explicit subclasses, though the
class-cluster method would still work and yet maintain separate
classes for each compression format.
I like the idea of a generic class and only supplying a MIME type, so
that different compression implementations can go in a separate package
just like GVfs backends today. It makes me think of gzip.GzipFile in
Python which I like because it lets you use a compressed file just like
a plain file, albeit I miss the autodetection there, so I second having
that feature in GCompressedInputStream.
Just my 2 cents,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
Am Fri, 31 Jul 2009 13:28:02 -0400
schrieb Tristan Van Berkom t...@gnome.org:
On Fri, Jul 31, 2009 at 12:47 PM, Robert
Staudingerrobert.staudin...@gmail.com wrote:
On Fri, Jul 31, 2009 at 6:19 PM, Tristan Van Berkomt...@gnome.org
wrote:
[...]
The idea of theme writers doing something to the first or last item
of a GtkBox simply based on it being a GtkBox; is a scary idea to
me, while I do recognize the value of exposing the positional data
of GtkBox to the theme code - ideally though - the theme code
should never ever do anything to the interface that the interface
didnt ask for (i.e. the theme engine
only applies CSS classes to widgets that set a tag for that class,
or possibly default to a tag, leaving programmers with expectable
results, always), unfortunately we have to include some level of
support for this in order to transition away from old broken
themes that make direct assumptions about your widget classes.
People frequently request being able to round only the outer buttons
of button boxes or treeview headers, like so:
http://www.gnome.org/~robsta/tmp/child-index-selector.png
Ofcourse, great example - the way I would suggest implementing this is
a.) we recognize the need to show itemized groups
b.) we define GTK_STOCK_STYLE_ITEM_GROUP
c.) we allow some customized containers define themselves as
itemized groups:
- Base container classes would not be itemized groups, this
would obstruct the programmer
- Classes like GtkButtonBox for instance could be an itemized
group - or GtkMenuShell
- Classes that define themselves or their children as styled
widgets are always higher level
composite widgets or special purpose widgets.
Then, the implemented CSS style for an item group would also cover
GtkBox, allowing
GtkBox to be styled as an itemized group, but not be one by nature,
allowing programmers
to implement their own treeviews and column headers for example - and
still leverage
the itemized group definitions from the theme.
[...]
I even wonder if the CSS code could be scoped and look more clear:
/* theming for large indentations */
gtk-stock-style-indent-large {
GtkBox { indent first widget by X pixels }
GtkTable { indent widget at first column/row by X pixels }
}
That wouldn't work, but in an ideal world you would get away with
something like
.gtk-stock-style-indent-large { margin-left: 12px; }
Sounds awesome.
This approach would make it more clear, that its the tables and
boxes that appear in the indent-large tag that we are theming,
the other way around makes it look like theming widgets hardcoded
by class is standard and that gtk-stock-style-main-toolbar is
some kind of special case only for toolbars (for instance, a theme
that handles toolbars might effect toolitems or even theoretically
menuitems in the main toolbar by virtue of being in the
main-toolbar tag, the fact that there is a GtkToolbar instance
in the main-toolbar area is only a detail).
A toolbar item in the main toolbar would be addressed like
.gtk-stock-style-main-toolbar GtkToolItem { ... }
Also awesome :)
A container that has no notion of position (maybe like GtkFixed)
could return -1 for each child, so the CSS subsystem would know to
ignore it and not apply any positional selectors like
:first-child and friends.
Is it important that the CSS subsystem have this data directly from
GtkContainer ?
For instance, there really is not many classes with positional data;
and the positional data can vary depending on the container type,
GtkBin doesnt have positional data - so would it represent much work
to handle the position data only for GtkBox, GtkMenuShell and
GtkToolBar instead of on the GtkContainer ?
I would also expect that the nature of what the CSS subsystem is doing
with a GtkTable is going to be all together different, and you
probably wont want a position at all (i.e. you might want to know all
the widgets that are on top, or on the left), and the position of a
page in a notebook is well, entirely different ;-)
I really have no idea how the css subsystem is implemented and I am
probably overlooking some things; only it seems to me, if only for the
sake of OO purity and api clarity; that the position property
doesnt really mean anything for the GtkContainer class itself.
I suspect the CSS will not want to special case each type of container
in GTK+, let alone third party libraries and applications. So
implementing a notion of positioning has to be at the GtkContainer
level.
ciao,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
Am Fri, 31 Jul 2009 10:33:41 +0200 schrieb Robert Staudinger robert.staudin...@gmail.com: On Thu, Jul 30, 2009 at 4:37 PM, Christian Dywanchrist...@lanedo.com wrote: [...] You are probably aware that gtk_container_get_children () does give yo the positions of children. Assuming that the lack of guarantees about order of widgets in a container is the actual problem, maybe this can be reconsidered. There was a bug I can't find right now suggesting a policy for this containers would be recommended to follow. We probably mean the same. GtkTable for example simply g_list_prepend()s in gtk_table_attach() -- thus I would just not use the word position here. That said, does it sound entirely off to gtk veterans trying to implement widget position as a read-only container child property? Sticking to the table example above -- a table child's position could easily be calculated using row (-count) and column (-count). From a quick look over the code this might not be quite as easy for box widgets, but maybe the child position could be calculated in the allocate() run and cached inside GtkBoxChild. I wonder what the API might look like. gtk_container_get_child_position (GtkContainer* container, GtkWidget*child, gint* row, gint* column); gtk_container_get_child_at (container, child, row, column); Can we assume that any container either lines up its children in one row or in 2 dimensions? Do we need or want to take into account the concept of primary and secondary children in boxes in the context? ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
Am Tue, 28 Jul 2009 08:45:26 +0200 schrieb Robert Staudinger robert.staudin...@gmail.com: On Tue, Jul 28, 2009 at 3:40 AM, Keith Rarickk...@xph.us wrote: [...] The margin property in gtk is not implemented like you assume above. Also does GtkContainer not expose information about child widget positions like you suggest using :first-child and friends. Work on those limitations would break the way for more a more comprehensive mapping of css onto gtk. Okay. I only meant that example to suggest what a theme could do in principle, even if it uses features that don't exist yet. Would you accept a patch with work toward those things, such as margin or first-child? If there way a way to get the position of a child in a GtkContainer (thus allowing for :first-child and other positional pseudo classes to be implemented) that would make quite a difference in what you can do with the css engine. I'm not in the position to make the call on gtk patches though. You are probably aware that gtk_container_get_children () does give yo the positions of children. Assuming that the lack of guarantees about order of widgets in a container is the actual problem, maybe this can be reconsidered. There was a bug I can't find right now suggesting a policy for this containers would be recommended to follow. Regards, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thoughts on GTK+ and CSS
Am Mon, 27 Jul 2009 18:40:41 -0700 schrieb Keith Rarick k...@xph.us: The margin property in gtk is not implemented like you assume above. Also does GtkContainer not expose information about child widget positions like you suggest using :first-child and friends. Work on those limitations would break the way for more a more comprehensive mapping of css onto gtk. Okay. I only meant that example to suggest what a theme could do in principle, even if it uses features that don't exist yet. Would you accept a patch with work toward those things, such as margin or first-child? Many people, including me, would like margin and padding for use in applications, you may want to consider that when looking into the theme side of it. Currently gtk_container_set_border_width, gtk_box_set_child_spacing and gtk_misc_set_padding are what comes closest to that on the application side. Regards, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
Am Sun, 12 Jul 2009 19:47:21 -0700
schrieb John Ralls jra...@ceridwen.us:
On Jul 12, 2009, at 6:18 PM, Dominic Lachowicz wrote:
Glib on Win32 has routines to solve this problem. It resolves things
relative to where the Glib DLL is installed. If your applications
use the XDG data directory functions in Glib, you might get away
with this too. Maybe you could invent something similar that used
the OSX bundle as your point of reference.
The routines only solve the problem if they're used.
Don't need to invent anything. The core foundation functions are
easy to use, and Richard Hult already abstracted it into a gobject.
But the code still has to be patched. It's not just application code,
either, but infrastructure libraries like gconf, gnome-keyring, dbus,
etc.
I set up a $PREFIX of /usr/local/gtk, built Gnucash, and ran `find /
usr/local/gtk -name *.dylib -exec strings \{\} | grep -H 'local/gtk'
\; ` and got more than 100 hits. Many of them are likely to be just
a define that isn't used for anything, but every one would have to
be examined, and a goodly number of them would require patching.
It's common enough to scan $PREFIX *and* runtime discovered paths
because the application may be installed in a non-standard place that
is not included in eg. XDG_DATADIRS, so that's not a mistake and will
yield lots of false positives.
Just my 2 cents,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib substr function
Am Fri, 26 Jun 2009 18:52:10 +0200 schrieb Daniel Elstner daniel.ki...@googlemail.com: Am Freitag, den 10.04.2009, 14:08 +0200 schrieb Christian Dywan: For the sake of demonstration, it took me 2 minutes to write a simple substring function in C that does what you want, have a look how it works. :) It doesn't. Your function allocates memory using a byte count but then uses the same value for the number of characters to copy. --Daniel Oh well, so you dug up a two and a half month old message of mine to point out that 2 minutes are enough to make a stupid mistake. :) You're right, it's not correct for UTF8 strings. I suppose it's good you pointed it out in case somebody else actually used the example as-is without noticing my mistake. Regards, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib substr function
Am Fri, 26 Jun 2009 18:52:10 +0200 schrieb Daniel Elstner daniel.ki...@googlemail.com: Am Freitag, den 10.04.2009, 14:08 +0200 schrieb Christian Dywan: For the sake of demonstration, it took me 2 minutes to write a simple substring function in C that does what you want, have a look how it works. :) It doesn't. Your function allocates memory using a byte count but then uses the same value for the number of characters to copy. --Daniel Oh well, so you dug up a two and a half month old message of mine to point out that 2 minutes are enough to make a stupid mistake. :) You're right, it's not correct for UTF8 strings. I suppose it's good you pointed it out in case somebody else actually used the example as-is without noticing my mistake. Regards, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: client side windows - request for testing and reviewing
Am Wed, 17 Jun 2009 18:52:03 +0200 schrieb Alexander Larsson al...@redhat.com: On Wed, 2009-06-17 at 18:21 +0200, Mikkel Kamstrup Erlandsen wrote: 2009/6/17 Alexander Larsson al...@redhat.com: The client side window branch is now feature complete on X11, and includes API to do offscreen window embedding (with patches for clutter-gtk availible to test this). Today I merged the latest master into the branch to make it easy for people to test it (its got the new so version). I fixed the last known (to me) bug yesterday (an obscure WM interaction issue on loading the saved session), and am running this as my default Gtk+ without issues. The win32 branch is getting some work done by Cody Russell, and the Quartz backend used to work fine but requires some minor API change updates (hopefully Richard can do this soon, CC:ed). It would be very nice if we could merge this soon. However, to do that we need more testing and people to look at the code. As things stand right now I've gotten essentially zero feedback. I don't know of anyone except the two backend porters who have built or looked at the code really. So, please, please, please, test this code. We need people who run uncommon apps to test it, and we need people to run it on apps they know really well so we can find minor changes in behaviour. Also, anyone who knows gdk or have an interest in this, please take a look at the code and give feedback. I think I need some pointers to give some constructive feedback on this. I've now compiled the client-side-windows branch, but I am unsure where to start looking and what to try out. That depends on what you want to do. Generally there is not a lot of new API in the csw branch, most of it is a total redesign of how gdk works internally. If you want to test, then just run normal apps like you normally do but with the client side window libraries, then try to find places where it differs in behaviour from the normal one. If you want to review the code, i'd recommend starting in gdkwindow.c, it has a long comment at the top describing how windows work in the new world, then go from there. The new API is mainly about doing offscreen windows: * New window type GDK_WINDOW_OFFSCREEN * gdk_window_get_offscreen_pixmap: Get the current GdkPixmap for an offscreen window * gdk_window_set/get_has_offscreen_children: enable embedding of offscreen children * gdk_window_offscreen_children_changed: Used when the geometry of the embedded offscreen windows change * a few new signals on GdkWindow to handle offscreen window embedding Although there is also a new generic function gdk_window_get_root_coords() that gets the root coordinates of any point in a window (as opposed to the old gdk_window_get_origin() which is not useful when windows may be transformed. And also - is there an easy way to run my existing apps on top of the new libs I've installed in /opt? Like some LD_LIBRARY*-magic... Yes, just install in another prefix and run with that in LD_LIBRARY_PATH there. Although this will change where gtk modules are loaded from so e.g. themes may not work with this. Define GTK_MODULES and just use your usual themes, see http://library.gnome.org/devel/gtk/unstable/gtk-running.html Cheers, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkActionEntry callback
Am Mon, 15 Jun 2009 19:54:01 +0200 schrieb Salvatore De Paolis iw...@claws-mail.org: Hi all, I'm in a context where the shortcuts should work and I have the ability to switch into another where they should be disabled because may interfere with the typical use of the new context. GtkActionEntry allows to associate a callback to an action and execute it on the activate signal. I wonder if there's a way to temporary block this signal maybe from the pre-activate one. Any hints? Hey Salvatore, try gtk_window_remove_accel_group. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable and GtkBox
Am Wed, 03 Jun 2009 16:18:17 +0800 schrieb Davyd Madeley da...@madeley.id.au: On Wed, 2009-06-03 at 10:08 +0200, Sven Neumann wrote: Hi, On Wed, 2009-06-03 at 14:25 +0800, Davyd Madeley wrote: I was experimenting with using GtkOrientable today and came across what might be an oversight when using it with GtkBox'like objects. I wanted to turn a hbox into a vbox, which is fine. However the buttons in the box are then clearly in the reverse order to the one that makes sense. What order are they? What order would you suggest makes more sense? This would be a usage-specific thing. They're in the order they were packed. When you swap the orientation of the vbox, they're still in the order they were packed, but that order might be backwards from the order you desire (i.e. if you were going to build the vbox from scratch). E.g., you might have: [1] [2] [3] Which orients to become [1] [2] [3] But for whatever reason, what you desired was: [3] [2] [1] Hey David, how is this related to GtkOrientable at all? This was always how a vertical box worked, ever since GtkVBox was there. There is nothing new with it. I'm afraid I don't see how Gtk could help you out, if what you need really is a specific packing. Anything but the current way is pretty much random and up to the application. Yours, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ print preview
Am Wed, 20 May 2009 15:17:41 +0100 schrieb Ghee Teo ghee@sun.com: Carlos Garcia Campos wrote: El mar, 19-05-2009 a las 07:46 +0200, Sven Neumann escribió: Hi, On Mon, 2009-05-18 at 15:06 +0200, Carlos Garcia Campos wrote: I've realized that print preview doesn't work as I thought, and I'm bit confused. An application open the print dialog by using GtkPrintOperation, then the user clicks on preview and a pdf file is generated to be used by a previewer. Such a file is passed to evince together with the print settings needed to print the file. The print dialog is closed, so we need to be able to print the document from the previewer. I don't understand why the previewer should be used to print the document. You may be right that this is what the authors of the GTK+ print dialog intended, but it is certainly an odd concept. I find it very confusing that the Print dialog closes when I hit the Preview button. Wouldn't it be better if it stayed open so that I can make adjustments if the preview turns out wrong and hit the Print button when I am satisfied with the preview? Yes, I agree, this was already discussed in this list before[1], though. Leaving the print dialog open, would also allow to change again the print settings if you are not happy with the preview results or just want to try other settings. Current flow is quite annoying in such cases, since you have to close the previewer and start the whole process again. Yes. If you want to do this, then evince can not be used as a previewer, since it is a different process. Why can't gtk+ provide the preview itself, I thought I read some discussion of having a Preview widget here. I also think that having a Print Preview dialog available while no printer is selected meant it is hard for create correct printer settings accordingly. I think originally the assumption was that preview in evince might be better in terms of displaying the document and usability of the preview. However apart from the work flow, the preview is also unavailable if you don't actually use evince. So I would totally agree to change that. Preview from Gtk itself would solve two problems for me. Just my 2 pfennig, Christian ___ 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
Am Fri, 15 May 2009 22:28:01 +0200 schrieb Jernej Simončič jernej.listso...@ena.si: On Fri, 15 May 2009 14:33:12 -0400 (EDT), Allin Cottrell wrote: IMO this is now pretty much of a non-issue, since the current GTK file selection dialog is sufficiently like Windows (but nicer!). For the values of nicer that match much slower, worse autocomplete behaviour than the native dialog, less useful Places list and confusing gradual display of network locations (the first time I tried opening something from my fileserver I thought some of my directories went missing because the GTK+ dialog displayed about a tenth of all folders at first, and then very slowly added the rest in about 15-second intervals; there's also the weird behaviour when you type a directory name, press Enter, see the Open button depress and jump out again - and then nothing happens, because the dialog expects a \ at the end to actually change to that directory). As unfortunate as it is, this is not a sole Win32 problem. The file chooser has started to host numerous issues and regressions some time ago. All Gtk platforms would benefit from improvements. That said, I personally hate seeing any non-Gtk file chooser on my linux machines, be it tk, qt, wine or even peculiar Gtk applications. And I know mac users who feel accordingly regarding gtk apps on their mac. Based on that assumption, I would think native file choosers on foreign systems would be very attractive. Just my 2 pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: tree model
Am Tue, 12 May 2009 08:10:11 +0200 schrieb Mikkel Kamstrup Erlandsen mikkel.kamst...@gmail.com: 2009/5/12 Matthias Clasen matthias.cla...@gmail.com: I should have been slightly more clear: I am interested in being able to provide a GtkTreeModel for those people who wish to use it without having to link to libgtk myself. So the problem with using GNode: GtkTreeView doesn't use it. I don't see why this is something we should be eager to support. Since tree models are only useful with GTK+ widgets, it doesn't seem like a big burden to link against gtk when you are providing tree models. The consumer of your model will already link against gtk anyway. I recall having issues with this... But my memory serves me badly... Is it that gtk_init() requires a connection to X? That way if I am writing mydaemon based on mylib.so then mydaemon will require X to run. Maybe gtk_init_check() can work around this, or maybe the library does not need gtk_init_* in the first place... I am hoping that I can use the same data model in the daemon and in the GUI app so that I don't have to wrap it in a GtkTreeModel when using it in the GUI app. Anyway, I just want to back Ryan up on this one. I've been wanting a GTreeModel for the exact same purpose as Ryan on more than one occasion. Hey, if the main issue is, as you describe, not having to run X11, then gtk_init_check is all you need. There is no practical problem using a GtkTreeModel without a display. It's simply that gtk_init errors out if there is no display, which is reasonable default behaviour. See the API reference for details :) Yours, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Review of gnio, round 1
Am Mon, 11 May 2009 10:49:31 -0400 schrieb Dan Winship d...@gnome.org: On 05/11/2009 10:30 AM, Stefan Kost wrote: Alexander Larsson schrieb: GResolver is already in gio, yes. NameResolver isn't really less generic than GResolver though. What else would it resolve but names? Could be GDNSResolver though. That sounds good. I was just wondering as there are other resolvers too (SATResolver, EquationResolver, ...) But are those likely to ever be in the G namespace? Also, it's an interface to libresolv, so... GResolver. But anyway, we could rename it to GDNSResolver if people wanted. Or just GDNS? I think clear naming is good, as long as it doesn't make the name thrice as long. Maybe GDomainResolver or GHostResolver? I tend to find spelled out words more readable than acronyms. Just my 2 pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Am Mon, 20 Apr 2009 17:00:41 +0200 schrieb Alexander Larsson al...@redhat.com: On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: On Sun, 19 Apr 2009, David Zeuthen wrote: I could be wrong, but just briefly looking at the code it looks like there is no default implementation of GDesktopAppInfoLookup in GIO, there's only one in GVfs (that looks up stuff in GConf under in /desktop/gnome/url-handlers/scheme) so it's no surprise things don't work if GVfs is not installed. Yes, that's right. As it's currently coded gtk_show_uri is bound to fail if GVfs is not present. But more than that: it'll fail even if GVfs _is_ present (as it is now on my system), if GVfs does not in turn incorporate GConf support. I thought I'd read that GConf was supposed to be deprecated, or on the way there? I don't understand what you propose? There is no in-use non-gconf setting for mapping default handlers for entire uri scheme. So, we lookup none which mean we then fall back to the per-mime default. Its entierly unreasonable to have a file:// uri handler, as that would open *all* types of local files, overriding your per-mime specs. What about using xdg-open if GVfs is not available OR if gconf is not available? That's a tiny script that can be easily installed anywhere, even on less modern boxes. Just my 2 pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Unplugging GtkPlug from GtkSocket
Am Wed, 15 Apr 2009 00:19:38 +0530 schrieb Ravi Kasibhatla kasibhatla.r...@gmail.com: Hi all, I am creating a plugin for a browser based on webkit, using the xembed protocol i.e. using GtkSocket GtkPlug. I have been successfully able to create the plugin show the content required on the plugin window, but I am facing problem when I try to delete the plugin. At the time of deletion of plugin, I want to delete the plug created, so as to free the resources allocated to the plug while creating plugin. Can anyone tell me how to do it, including how to do the cleanup on the GtkSocket side created in the browser? It would be of great help if anyone could let me know on this ASAP, as I am in urgent need of this information. I tried to find any resource telling more on XEmbed protocol usage and the cleanup process when using XEmbed protocol on the web, but couldn't get anything concrete help on this topic. Thanks Regards, Ravi Phaneendra K Hey Ravi, so what problem are you facing exactly? From what I understand you have an nsplugin that creates a socket and loads a plug from somewhere. Please correct me if I misunderstand the scenario. And I assume you are in charge of the socket and plug code. So both are GtkWidgets which have the usual finalize, dispose and destroy, plus the plug-removed signal on GtkSocket. I haven't used this in a while since it is somewhat messy, so it would be good if you could provide more context about what you are doing and what is not working. Yours, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant for prez!
Am Sat, 11 Apr 2009 13:55:36 -0400 schrieb Havoc Pennington havoc.penning...@gmail.com: Hi, On Sat, Apr 11, 2009 at 11:06 AM, Matthias Clasen matthias.cla...@gmail.com wrote: What David is saying (and I'm sure you understood) is that glib already comes with a type system, namely GType. Adding a completely separate one next to it in the same module is problematic, even if it is a well-loved one. I'm trying to think about this myself. Here are some thoughts. * glib serialization has been discussed in the past, e.g. http://mail.gnome.org/archives/gtk-devel-list/2006-June/msg00021.html * GVariant is basically a particular serialization format. It happens to use the same types as the dbus format. [...] Hiding the signature string format and using GType for that seems like it does not change anything semantically, it's just cosmetic in some sense. Using G_TYPE_FOO in the API is imho a lot more agreeable than any new string signature. Sure it's more to type, but at the same time it's more comprehensible. :) 2. try to use GLib types instead of having a custom value type, i.e. the dreaded GHashTable of GValue, or GArray that is a struct. This would seem to be both inconvenient, incomprehensible, and so bloated it may destroy the purpose of using mmap'd files. So some sort of serialized data value object like GVariant would appear to be needed? In short, if you have a dbus struct or dictionary, or mmap file struct or dictionary, what is the API to access that? This doesn't seem cosmetic to me. It's a fundamental question whether there's a serialized data value object and which types can go in it. I think this goes in the general direction of whether a particular GType can be serialzed and deserialized at all. For what I want, an object that for example represents an XML document, can very well be serialized. Of course that is entirely specific to the object type. Attempting to bring an object into a storable format is otherwise not a stupid idea imho. Maybe GType needs an interface so any type can implement what boils down to g_type_serialize, g_type_deserialize and g_type_can_serialize. If you think passing types to DBus that are not part of DBus will lead to problems, it might just be a matter of documenting that in Glib. * I would think of the type system of GVariant more like g_key_file_get_integer(), g_key_file_get_boolean(), g_key_file_get_integer_list() than it is like GType. The GVariant signature format is obviously far more complex than what GKeyFile supports; but *conceptually* it's equivalent to GKeyFile, right? It's pretty much an API for mmap'd files and for dbus IPC, just as keyfile is an API for .ini text files. You are asserting that something like a gint or guint is not something that can be saved to disk. Please take another look at the signature of g_key_file_get_integer. At the very least, you shouldn't compare GKeyFile with GVariant if you think one of them is broken by design, otherwise you are contradicting yourself :) That said, it is all too common, for better or worse, to work with numbers of unknown physical size, including storage to disk. It's fine with me to say it may not be a good idea, but I don't believe this is a DBus related problem at all. Granted, making it look like a GVariant specific issue is easier than trying to deprecate gint and guint. Just my 2 pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib substr function
Am Fri, 10 Apr 2009 12:45:39 +0200
schrieb b0unc3 daniele.m...@gmail.com:
Hi all,
there is any implementation of a substr function in GLib ?
I mean :
string = hello world
g_*substr*(string,2,6)
output = llo w
Hey b0unc3,
no, there isn't. Either you use a higher level language which has it or
you use low level functions in C.
For the sake of demonstration, it took me 2 minutes to write a simple
substring function in C that does what you want, have a look how it
works. :)
Yours,
Christian/* Copyright (c) 2009 Christian Dywan christ...@twotoasts.de
This code is licensed under the terms of the expat license */
/* gcc -o substr substr.c $(pkg-config --cflags --libs glib-2.0) -Wall -O1 -g */
#include glib.h
gchar *
g_substr (const gchar* string,
gint start,
gint end)
{
gsize len = (end - start + 1);
gchar *output = g_malloc0 (len + 1);
return g_utf8_strncpy (output, string[start], len);
}
int
main (intargc,
gchar* argv[])
{
const gchar *string = hello world;
gchar *output = g_substr (string, 2, 6);
g_print (input: %s, output: %s\n, string, output);
g_assert_cmpstr (output, ==, llo w);
g_free (output);
return 0;
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib substr function
Am Fri, 10 Apr 2009 16:49:43 +0200
schrieb b0unc3 daniele.m...@gmail.com:
2009/4/10 Nelson Benítez León nbenit...@gmail.com
2009/4/10 b0unc3 daniele.m...@gmail.com:
Hi all,
there is any implementation of a substr function in GLib ?
I mean :
string = hello world
g_*substr*(string,2,6)
output = llo w
Another way,
substring (GString *str, int index, int len)
{
return g_string_new_len (str-str, index, MIN (str-len - index,
len)); }
taken from http://bugzilla.gnome.org/show_bug.cgi?id=109286#c2 .
I personally would like that glib provide those small but useful
string functions (like other high level languages do), for example,
glib doesn't provide a simple function to replace strings, like this
one written by Tim in
http://bugzilla.gnome.org/show_bug.cgi?id=65987#c2 ,
gchar *
g_strreplace (const gchar *string,
const gchar *search,
const gchar *replacement)
Instead you currently have to use gregex to replace some simple
strings (where no regex are involved).
First of all thanks to everyone who replayed.
The implementation using g_srtndup looks ok.
I was wondering why not to add a so simple example in the official
docs (maybe in the g_strndup explanation).
Hey,
the reason is simple. This is entirely up to the programming language
and not at all Glib specific. If you want to learn more about C you
should look for a good C (online) book.
Regards,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ web site [PATCH]
Am Fri, 27 Mar 2009 17:38:12 -0700 schrieb Eugenia Loli-Queru el...@hotmail.com: excuse me if this wasn't intentional but I think your tone is inappropriate here. I didn't see anything wrong with my tone on my previous email! I don't understand why you saw it as hostile! [...] And if you are willing to share the source code freely, please remove any misleading hints about license costs. I updated the code/ownership bit here: http://www.gnomefiles.org/contact.php Hey, thanks for updating the ownership information :) So, what about that link? :-) Here's a patch. I'm not quite sure who decides if we can change it back, but it's ready to go. ciao, Christiandiff --git a/index.php b/index.php index 9ed0e1d..fccc644 100644 --- a/index.php +++ b/index.php @@ -56,7 +56,7 @@ GTK+. Understand who started it, the basic architecture and why we use the license we do./p pGTK+ has been involved in - many a href=http://www.gtk-apps.org/;projects/a and + many a href=http://www.gtkfiles.org/;projects/a and some big platforms. To see what people think of GTK+ and how it has been used in commercial projects, a href=commerce.htmlread the success ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ web site
Am Thu, 26 Mar 2009 04:40:34 -0700 schrieb Eugenia Loli-Queru el...@hotmail.com: Thank you for the reply. Gnomefiles is back for months now btw, and OSNews has worked on it to make sure it's up and running properly. I would appreciate it if you could put back the link in the GTK.org page! :) As for the source code of the site, if the site was to go down for some reason, I would just give the code+data away so you can host it. thanks! Eugenia Hey Eugenia, excuse me if this wasn't intentional but I think your tone is inappropriate here. As Andreas said your official statement was that Gnomefiles was dead for good. And you should also not try to play down the license issue which prevented anyone else from taking the webpage over. Stand by your mistakes instead of blaming others. If you took the webpage down and announced it, you could just as well have announced your return. And if you are willing to share the source code freely, please remove any misleading hints about license costs. That aside, Gnomefiles is a really great place, and I am happy to have it back. I found various interesting pieces of software on that webpage in the past. Yours, Christian ___ 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
Am Thu, 12 Mar 2009 18:51:33 +0200 schrieb Cody Russell brats...@gnome.org: 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? Hey Cody, I think you are pretty much giving the best reason for leaving out the GtkWidget* yourself: any use cases which do not involve actual widgets, such as XUL, WebKit, Qt theming, and so on will break soon enough if we make the same mistake as we did before, by assuming that a GtkWidget* is there. We likely would have themes which cannot be used outside of Gtk right from the start. I think considering those use cases you mention, such as inspecting the widget hierarchy, are solvable. And if a use case is missing after the first version it's not the end of the world, nothing is perfect from day one (GIO anyone? ;)). Just my 2 pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
WebKit on webkit.gtk.org
Heya, I'm one of the WebKitGtk fellows and one thing we are missing currently is a place on the web, where you can find releases, docs and whatnot. So we had the idea, webkit.gtk.org would be a good domain. We would also like to use a similar design and layout, of course with different colours and content. It's not yet clear what web space we would be using, if that is possible a bit of space for tarballs would be useful (release tarballs for WebKitGtk are not that heavy, in case somebody is worried and has the size of all of WebKit in mind). So the question is, would the Gtk maintainers like the idea of using the 'webkit.gtk.org' subdomain for WebKit? And if the above is an option, whether there's space to spare and whether we could or shouldn't use a similar design. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOrientable: Can widgets now be flipped?
Am Sun, 08 Feb 2009 13:07:34 +0100 schrieb Murray Cumming murr...@murrayc.com: The new GtkOrientable's documentation http://library.gnome.org/devel/gtk/unstable/gtk-Orientable.html#gtk-Orientable.description says: Historically, such widgets have been realized as subclasses of a common base class (e.g GtkBox/GtkHBox/GtkVBox and GtkScale/GtkHScale/GtkVScale). GtkOrientable is more flexible in that it allows the orientation to be changed at runtime, allowing the widgets to 'flip'. All those old widgets do now implement GtkOrientation: http://library.gnome.org/devel/gtk/unstable/gtk-Orientable.html#gtk-Orientable.implementations So can they actully be flipped at runtime now? The documentation seems to suggest that they can't if they still use the old common base classes. This is how the current state is to my awareness: It is meant to work so that subclasses such a GtkHFoo and GtkVFoo behave the same as they used to, and can't flip. However if you use the originally abstract base class 'orientation' works as expected, at construction as well as runtime. Note that GtkBox is still abstract in trunk although it technically supports 'orientation' because possible changes in default values of properties has to be discussed. So you can not use it. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
Am Mon, 19 Jan 2009 21:17:50 -0500 schrieb Yu Feng rainwood...@gmail.com: Hi Federico, If I can have a word on this: The big circle is wider than most characters. Compare the following 3 patterns: (10 chars, monospace) ●● •• 1234567890 When people type in a password they don't expect it to look much longer than what has been typed, right? Although the original question has been answered already, for the record, those three examples of yours have all the very same size in my font, which happens to be monospace. Beside that, the user is only ever seeing a number of occurences of a single character. So there is nothing to compare a wider or larger character to. The whole idea behind invisible characters is that they don't reflect the actual password in the first place. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
Am Mon, 22 Dec 2008 16:44:55 +0100 schrieb Alberto Garcia agar...@igalia.com: On Mon, Dec 22, 2008 at 02:44:40PM +, Ross Burton wrote: the code generated for a virtual function in C++ is as far as I understand (as I said, noob here) in principle the same as the code you have to manually write in GObject to do the same thing, it's just much more invisible. Exactly. C++ can do slightly more optimisation because the OO, casting and so on are in the compiler instead of built at runtime, but the underlying mechanics are the same. As you say, because type casts are dinamic, there's the overhead of calling g_type_check_instance_* which in languages like C++ is not needed because it's done at compilation time. I suspect that this overhead is negligible (I haven't made real tests, though). To be fair, you should consider that C++ has other overheads, and is particularly hard to parse from the perspective of a compiler. And C++ is not even the only condidate for comparison, there is also for instance Objective C, which is actually a dynamic language with properties and messages (~signals). In that regard the benefit of a hypothetical rewrite of Gtk in Vala would be about avoiding human error and added type safety, rather than making the type system faster. Much of performance problems in Glib applications come from the way it is used, and not from GObject, which is why I like the idea of integrating GObject with the language/ Vala. Just my 2 pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ on DirectFb (sample example fails with DirectFb/Fbdev Caught Signal 11)
Am Fri, 19 Dec 2008 20:52:18 +0530 schrieb Arun Patole webkit.ar...@gmail.com: Hi All, Is the latest GTK+ up to date for building with DirectFB? I tried building it but failed with some multiple definition errors. after resolving them, small demo example crashes. Do i have to apply any patches to use gtk+ successfully on directFB?? The latest Gtk+ for DirectFB is broken because nobody who uses DirectFB stepped up to bring it back in shape. I've seen countless attempts at using it but nobody who was up to fix it. What did you do to fix it, and how do you test it? ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Top-level include files
Am Wed, 17 Dec 2008 15:01:55 -0500 schrieb Morten Welinder mort...@gnome.org: Its supposed to be documented in the api docs, at the top of the synopsis for each section. Of course, the documentation may be outdated. This is a farce. Why try to enforce something that does not seem to have ever been documented? At least not correctly. [...] Humble suggestion: Hey Morten, please try to actually be humble and don't make it look more dramatic than it is. The exceptions were documented before already, arguably a more central explanation might be nice. You survived it before, the new policy doesn't change anything about those special cases. :) I would agree if you have an idea of how to document this more intuitively, please make a suggestion. Just my 2 pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Patch] Re: Howto retrieve selected font size from GtkFontButton
Am Wed, 3 Dec 2008 12:31:23 +0100 schrieb Nelson Benítez León [EMAIL PROTECTED]: 2008/12/2 Stefan Kost [EMAIL PROTECTED]: Nelson Benítez León schrieb: 2008/12/2 Sven Herzberg [EMAIL PROTECTED] http://bugzilla.gnome.org/show_bug.cgi?id=562998 Ok, thank you!, I was about to suggest that, because I thought gtk_font_button_get_font_name just returned the font name, thanks for this doc improvements, it would be easier if the online docs permited user contributed notes. Let me chime in as the gtk-doc maintainer. While that sounds like a good idea its not that simple. If someone has a complete proposal I would be willing to help doing it. Problem is to feed the comments back into the docs which are in the sources. I don't think comments need to go back to sources, comments would be in mysql indexed by the symbol name they referred to (function name, class name, signal name, etc) and there would be a php page that will combine the gtk-doc html with the comments and present that to the user. The problem with that approach is that not everyone is using the online documentation. For one, it requires a perfect network connection, which you may not have if you're traveling or somewhere without permanent broadband. Plus it is obviously slower and less convenient to search, compare to 'devhelp'. Hence I agree with Stefan's assumption that comments should be folded back into the sources. Maybe a compromise would be that there is a page that lists all user provided pieces, so that developers can easily go over the list, decide what's useful, file a documentation bug if appropriate, and also remove false information if needed. It would add a bit of maintanance but if it can be integrated with bugzilla logins/ permissions, it might be an overwieable overhead. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Howto retrieve selected font size from GtkFontButton
Am Tue, 2 Dec 2008 14:19:49 +0100 schrieb Nelson Benítez León [EMAIL PROTECTED]: 2008/12/2 Christian Dywan [EMAIL PROTECTED] Am Tue, 2 Dec 2008 14:03:01 +0100 schrieb Nelson Benítez León [EMAIL PROTECTED]: Hi, Gtkfontbutton provides api to get the name of the selected font, but not to get the selected font size, so I would appreciate if you know of some way to get the size, or if that is not possible, if you will accept a patch to provide that api.. Thank you Hey, you can convert the font string with pango_font_description_from_string and then obtain the size easily. I would however also think the font button should provide API for that. Ideally it were a GtkFontSelection but unfortunately that's not the case. And, how could I get the font string of the currently selected font in the gtkfontbutton? to pass it to pango_font_description_from_string later... gtk_font_button_get_font_name That returns the font name, as seen in the button, including styles and size. Yours, Christian ___ 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-11-25
Am Tue, 25 Nov 2008 22:50:00 +0100 schrieb BJörn Lindqvist [EMAIL PROTECTED]: 2008/11/25 Emmanuele Bassi [EMAIL PROTECTED]: = minutes for the 2008-11-25 meeting = * alexl: client-side windows branch + third iteration of the offscreen redirection support + first was an hacked up version + second was a cleaned up version + third (current) incorporates owen's feedback on gtk-devel-list - more radical approach - allow us to clean up and simplify the platform backends - pushes a lot of stuff to the common code - we can drop all 32bit coord emulation - in the typical case only the toplevel window will have its own native window - however, we want to support native windows in the hierarchy - some pending issues (native XIDs mainly) ACTION: send an update on monday to gtk-devel-list (alexl) ACTION: put a roadmap/TODO on the wiki (alexl) The last time this was discussed there was one unresolved issue with opengl windows that require their own xwindow to paint on. Did you come up with a solution for that? You would have to be more conrecte. As you can see from the notes, native windows are considered in the proposed 'radical' approach in a way that they are provided on a case by case basis. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] gtkicontheme.c: optimization
Am Sat, 22 Nov 2008 16:10:18 +0100 schrieb Kajtár Zsolt [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all! After doing some research on the gtk icon loading, I've changed a few things: [...] Hey Zsolt (is that your first name?), would you please file a bug, attach the patch there and summarize how you ran your test? Then I would be delighted to give it a go. (Feel free to mention that the patch applies perfectly on trunk) ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fuse paths with gvfs
Am Tue, 18 Nov 2008 10:56:27 +0100 schrieb Alexander Larsson [EMAIL PROTECTED]: On Sun, 2008-11-16 at 15:42 +0200, Markku Vire wrote: Hi list, I'm wondering whether gvfs-fuse-daemon is expected to support multiple mounts from the same server. I have the following kind of situation: sftp://[EMAIL PROTECTED]/some/path sftp://[EMAIL PROTECTED]/some/path When I mount these shares, I end up having: $HOME/.gvfs/sftp on server/ $HOME/.gvfs/sftp on server/ which is certainly not a good thing... Since the username doesn't appear in fuse path, both shares end up having identical paths. Should this kind of use case be OK? If yes, then GIO uri = fuse path mapping needs a fix, if not, then I would expect some kind of error message from some of the components. Yeah, this doesn't look right. If the user is specified in the uri it should be so in the sftp mountpoint too. I've fixed this on trunk, but its a string addition, so its kinda hard to fix on stable... If fixing stable is not an option, I suggest to at least print a warning pointing out the problem. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_STOCK icons vs. named spec
Am Thu, 13 Nov 2008 21:56:29 -0800 schrieb John Daiker [EMAIL PROTECTED]: Hello All, First off, apologies for the widespread distribution of this e-mail. I figure start big, and then the appropriate list can assist from there. Second, I just signed up to the list (gtk-app-devel-list), but had a specific question about using the GTK_STOCK_* naming convention versus the 'defined text'. (eg: GTK_STOCK_SAVE vs 'gtk-save' and GTK_STOCK_CLOSE vs 'gtk-close') Rhythmbox currently uses the GTK_STOCK_* convention, but it has been brought up recently (http://bugzilla.gnome.org/show_bug.cgi?id=560349#c5) that perhaps this convention is 'bad habit'. Just looking for some insight into this, and maybe to get a feel for what the community views as the 'best practice'. Hey John, if the question is whether to use a stock ID or a named icon, there are a few points to regard: - A stock ID can refer to multiple icon names - A stock icon is guaranteed to exist (exception: GTK_STOCK_DISCARD) - A stock ID can and usually does include a label - A stock icon can have an RTL variant Basically you can use an icon name wherever you need no icon, and of course you *should* use an icon name where there is no stock ID. However at the same time, your must be aware that unless you ship the icon with your application, that without a theme containing the icon name your application is basically broken. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Patch biohazard report, Nov 18th
Hello Gtk+ people, time for another Bio Hazard! Low hanging fruits: - Bug 558325 – Tutorial link in FAQ is broken * + Tiny string replacement http://bugzilla.gnome.org/show_bug.cgi?id=558325 - Bug 560189 – GtkScale doesn't allow minimum size * + Straightforward, new style properties http://bugzilla.gnome.org/show_bug.cgi?id=560189 - Bug 560671 – the client_message API doesn't work in DirectFB * + Straightforward patch http://bugzilla.gnome.org/show_bug.cgi?id=560671 - Bug 539263 – Deprecate gdk_window_get_toplevels * + Simple patch, towards multi head safe API http://bugzilla.gnome.org/show_bug.cgi?id=539263 A little decision is needed, the patches are easy: - Bug 558659 – In mousewheel event, do horizontal scroll when no vertical scroll is available in a gtkscrolledwindow * + Small patch, works fine, do we want it? http://bugzilla.gnome.org/show_bug.cgi?id=558659 - Bug 123498 – GtkFontSelection should localize style list * + Intuitive, not perfect but effective http://bugzilla.gnome.org/show_bug.cgi?id=123498 - Bug 391179 – font selection dialog needs color option * + Provisional patch, is the patch worth finishing off? http://bugzilla.gnome.org/show_bug.cgi?id=391179 - Bug 511154 – gtk statusbar frame omits the resize grip * + Revert or not to revert, that's the question http://bugzilla.gnome.org/show_bug.cgi?id=511154 Something more exciting, for the really ambitious hackers: - Bug 554407 – directfb backend does not implement GdkWindowImpl * + Do a good deed, help fixing the DirectFB backend in 2.14/ trunk http://bugzilla.gnome.org/show_bug.cgi?id=554407 - Bug 556706 – Inconsistent help arguments -h, -? * + Straightforward patch, improvement needed http://bugzilla.gnome.org/show_bug.cgi?id=556706 - Bug 406731 – Simplify multi-threaded apps using a single GUI thread * + Could use insight of a savvy hacker http://bugzilla.gnome.org/show_bug.cgi?id=406731 Today's special guest is GtkIconEntry, everyone is welcome to review the API and test it before it goes in: - Bug 85292 – add an icon to gtkentry * + Work in progress, review appreciated http://bugzilla.gnome.org/show_bug.cgi?id=85292 And for your convenience, all of the bugs in one go, powered by buglist.py[1]: http://bugzilla.gnome.org/buglist.cgi?bug_id=558325,560189,560671,539263,558659,123498,391179,511154,554407,556706,406731,85292 Go ahead, reject and accept patches, have fun. greetings [1] http://blogs.gnome.org/timj/2008/10/20/20102008-bugzilla-utility-buglistpy PD: You can see the wiki page http://live.gnome.org/GtkLove/PatchTriaging if you want to check past issues, help or just check some bugs. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Patch biohazard report, Oct 03rd
Hello Gtk+ people, time for another Bio Hazard! Low hanging fruits: - Bug 377699 – realizing gtk.Progress() causes SEGV + Make GtkProgress an abstract type, can we do that? http://bugzilla.gnome.org/show_bug.cgi?id=377699 - Bug 554567 – warning fixes (missing format specifiers and NULL vs 0) + Straightforward patch adding format specifiers to g_warning style calls http://bugzilla.gnome.org/show_bug.cgi?id=554567 - Bug 535557 – gdk_window_set_icon_name should accept NULL to unset + Small, straightforward patch http://bugzilla.gnome.org/show_bug.cgi?id=535557 - Bug 447840 – $XDG_DATA_HOME/themes is not inspected for installed themes + Straightforward patch, applies fine on trunk http://bugzilla.gnome.org/show_bug.cgi?id=447840 - Bug 558325 – Tutorial link in FAQ is broken + Easy patch, just a string replacement http://bugzilla.gnome.org/show_bug.cgi?id=558325 - Bug 442297 – Submenu placement uses stale requisition for calculations + Trivial patch, review needed, is this a good approach? http://bugzilla.gnome.org/show_bug.cgi?id=442297 A little decision is needed, the patches are easy: - Bug 144500 – When desktop_is_home_dir, file dialogs still show Desktop + Simple patch, needs a decision if it's the right approach http://bugzilla.gnome.org/show_bug.cgi?id=144500 - Bug 74291 – Feature request: gdk_pixbuf_new_from_raw_data () + Convenience function, needs an API decision http://bugzilla.gnome.org/show_bug.cgi?id=74291 - Bug 558659 – In mousewheel event, horizontal scroll when no vertical scroll available + Trivial patch, do we want this? http://bugzilla.gnome.org/show_bug.cgi?id=558659 Something more exciting, for the really ambitious hackers: - Bug 536229 – Improve themability of the notebook scrolling gap + Very much mature patch, could be done with a final review http://bugzilla.gnome.org/show_bug.cgi?id=536229 - Bug 539907 – Improve GtkHButtonBox allocation requisition behaviour + Advanced patch, with testcase, needs review http://bugzilla.gnome.org/show_bug.cgi?id=539907 And for your convenience, all of the bugs in one go, powered by buglist.py[1]: http://bugzilla.gnome.org/buglist.cgi?bug_id=74291,144500,377699,447840,535557,554567,556835,558325,536229,539907,442297,558659 Go ahead, reject and accept patches, have fun. greetings [1] http://blogs.gnome.org/timj/2008/10/20/20102008-bugzilla-utility-buglistpy PD: You can see the wiki page http://live.gnome.org/GtkLove/PatchTriaging if you want to check past issues, help or just check some bugs. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_utf8_strlcpy
Am 29 Oct 2008 10:24:09 -0400 schrieb PHILIP PAGE, BLOOMBERG/ 731 LEXIN [EMAIL PROTECTED]: I see that http://bugzilla.gnome.org/show_bug.cgi?id=520116 has been entered to develop a utf8 version of strlcpy. Has anyone done this? Below is a proposed implementation and some test cases. Philip Page Bloomberg LP Hey Philip, would you please attach your patch to bugzilla? That way someone is able to review and comment it, flag the status of the bug and the patch, and you can keep track of development much better than here on the mailing list. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Theming API hackfest: last call
Am Wed, 15 Oct 2008 13:48:47 +0200
schrieb Robert Staudinger [EMAIL PROTECTED]:
On Wed, Oct 15, 2008 at 12:03 PM, Christian Dywan
[EMAIL PROTECTED] wrote:
[...]
Sounds like it would make subclassing kind of hard, if I understand
you right. For instance people like to subclass to create all sorts
of buttons and it is only intuitive that they all look similar.
What would happen to my hypothetical ExampleSelectColorButton if
the GtkButton styles are not applied to it?
It's not so much about picking the one or the other way, but providing
both possibilities. The general case will likely be styling on the
type name, but in rare cases implicit style inheritance may not be
desired. Imagine (ok, this is somewhat contrieved) that window
decorations will be drawn by gtk itself, and designers will just style
GtkWindow to their liking. It is conceivable that this styling should
not be inherited to GtkPlug, so .GtkWindow { ... } would be the way
to go.
Relatedly I am thinking of a sane way to import styling into CSS
blocks to aid widget mimicking. Imagine you want to mimick a GtkButton
with your own wonderful implementation FooButton, but unrelated in
the GType hierarchy (not inheriting from GtkButton). Something like
this might aid to apply GtkButton styling:
FooButton {
ccss: import(GtkButton);
}
Analogously, from the GtkWindow example above, it would be possible to
apply styling from GtkWindow to GtkDialog (it would not apply
implicitly, because we want to avoid styling GtkPlug). And let's make
up some additional properties as well:
GtkDialog {
ccss: import(.GtkWindow);
minimize-button: none;
maximize-button: none;
}
All this is of course pretty premature, but I hope the idea is clear.
Hey,
thanks for the explanation. I see the idea and I agree, automatic
inheritance doesn't always make sense. However as seem to suggest to
add explicit rules to the theme's gtkrc. I think if we are taking this
route, there must be a way to do this on the implementation side of the
FooButton class. Otherwise any new widget that is supposed to render
like a button will be unusable, design/ usability wise, until each
theme is update to be aware of the new widget.
So, unless that was your intent anyway, I'd suggest we need some way to
implement that relationship of GtkButton and FooButton in the new
widget. This might be a mere style property, or it could be inside a
gtkrc or css file that the new widget is providing.
ciao,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Theming API hackfest: last call
Am Wed, 15 Oct 2008 11:30:38 +0200
schrieb Robert Staudinger [EMAIL PROTECTED]:
On Tue, Oct 14, 2008 at 11:44 PM, Behdad Esfahbod [EMAIL PROTECTED]
wrote:
[...]
Shouldn't the class-specific ones use the css class modifier? That
is, .GtkButton?
Per libccss default, the style of a type Foo is also applied to all
its derived types (contrast gtkrc, which afaik requires explicit
markup Foo for that). QT is using the class selector to apply
styling that would not be inherited [2], e.g. .GtkButton { ... }
would not affect GtkToggleButton instances and other GtkButton-derived
types. I am pondering this for the CSS engine as well.
Sounds like it would make subclassing kind of hard, if I understand you
right. For instance people like to subclass to create all sorts of
buttons and it is only intuitive that they all look similar. What would
happen to my hypothetical ExampleSelectColorButton if the GtkButton
styles are not applied to it?
ciao,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Theming API hackfest: last call
Am Tue, 14 Oct 2008 17:44:06 -0400
schrieb Behdad Esfahbod [EMAIL PROTECTED]:
Robert Staudinger wrote:
On Fri, Oct 10, 2008 at 3:36 AM, Behdad Esfahbod
[EMAIL PROTECTED] wrote:
[...]
Hi Rob,
I got to know about work you are doing by crossing over your fd.o
account request. I thought to myself: wow, this is so cool...
why didn't I hear about this stuff before? I think a good number
of GNOME/GTK+ developers are in that boat too. So, why don't you
tell us some more about what you've been doing and what your
future plans are? Here on the list I mean.
Sure.
Thanks for the overview. I have no experience in themeing so I can
just offer side bikeshedding comments.
It was some 2 years ago when I first toyed with CSS, gtk and
engines, but quickly lost interest because trying to parse
gtkrc-embedded CSS with GScanner was too much legwork. This summer
I looked at the code again but only after taking the time to read
up on libcroco usage. Basically, why did you not hear about it,
well, it took some time to get from the it kinda does something
of the early prototypes to a better understanding of the issues
involved. I am confident that the upcoming 0.3 release will be more
suited to be shown off.
The main items of experimentation have been the intersection of
primitive- and widget-theming and the libccss API.
By primitive theming I am referring to direct influence on drawing
function calls. If you write box { background: red; } in your CSS,
the visual result of gtk_paint_box() calls will be affected.
Widget-theming on the other hand is applied to gtk's type names,
like e.g. the CSS statement GtkButton { border: 1px solid
black; }.
Shouldn't the class-specific ones use the css class modifier? That
is, .GtkButton?
Another relevant idea is that sophisticated CSS matching rules may
help theming complex widgets without requiring them to expose their
internal structure. For example, .GTKTreeView.GTKButton will
match a GTKButton that has a GTKTreeView parent.
The way I read that, I think you are contridicting yourself. You are
saying 'without requiring [...] to expose their internal structure' but
at the same time suggesting themeing based on exact knowledge of the
hierarchy, which *is* in implementation detail and nothing else.
A real help would be if it was more like
.GtkTreeView .column-header { }
Or even better
.tree-view .column-header {}
Which would enable you to actually theme without knowing how the widget
is implemented, and in the second case even what particular class it
is. For the sake of the example, those identifiers could be widget
names.
I imagine there could be a straightforward table of supported widget
names as part of the reference documentation.
ciao,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Theming API hackfest: last call
Am Mon, 13 Oct 2008 12:55:08 +0200
schrieb Robert Staudinger [EMAIL PROTECTED]:
On Fri, Oct 10, 2008 at 3:36 AM, Behdad Esfahbod [EMAIL PROTECTED]
wrote:
[...]
Hi Rob,
I got to know about work you are doing by crossing over your fd.o
account request. I thought to myself: wow, this is so cool... why
didn't I hear about this stuff before? I think a good number of
GNOME/GTK+ developers are in that boat too. So, why don't you tell
us some more about what you've been doing and what your future
plans are? Here on the list I mean.
[...]
It soon became apparent that CSS drawing capability wrapped into a
simple API might be of use for other cairo-based applications as well,
so with some support from Carl Worth I spun that part off to fd.o
after the recent 0.2 release. Currently I'm focusing on the libccss
API, feedback from Intel's Robert Bragg and Thomas Wood has been very
valuable. After that I'll try to focus on the engine again, mostly the
support for composite widgets mentioned above.
I'll also be looking into setting style parameters from CSS, probably
something like GtkButton { gtk: child-displacement-x(1); } or
GtkButton { gtk-child-displacement-x: 1; }.
Finally, regarding the SVG theming efforts that are floating around
[2, 3], I think that CSS and SVG are mostly orthogonal rather than
competing with each other. SVG is great for graphics, and CSS is made
for things like expressing that the GtkButton instance inside a
GtkTreeView should be drawn as a column header.
I would think, the fact that you are actually trying to preseve
oddities like the GtkTreeView/ GtkButton relation, leaves a bit of a
bad aftertaste. I like the CSS idea, because the most of the syntax is
pretty intuitive - to someone who knows CSS anyway. But I think the
goal should - imho - involve leaving behind those tricks, whatever the
best approach may be.
Just my two pfennig,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Windows dev-* environment
Am Mon, 6 Oct 2008 18:58:16 -0400 (EDT) schrieb Allin Cottrell [EMAIL PROTECTED]: On Mon, 6 Oct 2008, 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. Yes, it's a nice idea, but it requires that all build-related files be generalized beyond the usual assumptions that are valid for *nix platforms to encompass the full weirdness and oddity of MS Windows (R). This is a heavy burden on app developers. In my experience, it's much easier (if, in the end, less satisfactory) to leave the auto* files with their *nix assumptions and write a separate makefile for Windows. I think every developer has a simple choice: Using autotools, which is not portable in the true sense of the word, so it works fine on almost all unix platforms, but you still have to invent a new build system for Win32. Using something else, be it cmake, waf, scons, whatever, that can either build on Win32 or create files for another system that does build on Win32. Maybe even autotools *and* one or multiple of the alternatives. Which is what gtk does, too, having nmake files, different visual studio files, and a few build systems that people make up on their own, that never make it into Gtk proper. I don't think anyone chooses autotools for its speed in the first place, even on unix it is not the fastest there is. If you use it, then because it's established and known to work on many platforms. Just my two pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Patch biohazard report, Sep 29th
Hello Gtk+ people, time for another Bio Hazard! Low hanging fruits: - Bug 524203 – GtkRanges should send ::change-value even if not realized + Easy patch, removing a bogus if(realized) - Patch applies fine http://bugzilla.gnome.org/show_bug.cgi?id=524203 - Bug 307963 – GtkSpinButton clamps value with the wrong maximum. + Simple patch - Patch applies perfectly http://bugzilla.gnome.org/show_bug.cgi?id=307963 - Bug 311678 – Don't bother clearing the background for GDK_NO_BG windows + Simple two line patch http://bugzilla.gnome.org/show_bug.cgi?id=311678 To document or not to document: - Bug 339205 – Widget:popup-menu and show-help signals need docs for language bindings + Clarification needed, just say Yes or No basically http://bugzilla.gnome.org/show_bug.cgi?id=339205 - Bug 323904 – GtkEditable header is slightly incorrect + Easy patch, is it okay or invalid? - Patch would need to be fixed http://bugzilla.gnome.org/show_bug.cgi?id=323904 Some fruits that are harder to reach: Need some work or word from our beloved GTK+ hackers: - Bug 155071 – wrong colors in location bar history + Fixes entry completion theming - Patch applies partly http://bugzilla.gnome.org/show_bug.cgi?id=155071 Your opinion is asked for, dedust some oldies: - Bug 446738 – api to check lockedness + Straightforward patch, do we want it, yes or no? http://bugzilla.gnome.org/show_bug.cgi?id=446738 - Bug 324899 – No easy way to clear the contents of a text GtkComboBox + Adds a function to clear the text in the combobox. - Patch applies fine The patch is simple, but needs a decision/ opinion http://bugzilla.gnome.org/show_bug.cgi?id=324899 - Bug 319608 – Enhance the GtkProgressBar widget + Different short- and long-term suggestions - Patch applies partly Needs a decision how to proceed http://bugzilla.gnome.org/show_bug.cgi?id=319608 - Bug 322194 – Proposal: undo/redo in gtk + Advanced patch available, a judgement call is badly needed - Patch applies partly http://bugzilla.gnome.org/show_bug.cgi?id=322194 Go ahead, reject and accept patches, have fun. greetings PD: You can see the wiki page http://live.gnome.org/GtkLove/PatchTriaging if you want to check past issues, help or just check some bugs. ___ 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
Am Thu, 25 Sep 2008 22:20:17 +0200 schrieb Michael Natterer [EMAIL PROTECTED]: 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. Because I would never suggest a change that will break almost every single GTK+ application's layout even though these applications have done *nothing* wrong. Some thing will break if you do that, but nowhere near as many things as with changing the default plus getting rid of hbox/vbox. I suspect it would not be that many things, because most things currently use the unaffected box packing methods. This would be an API break -- semantics changed -- but I don't think the impact would be all that big. Glade files, for example, seem to have explicit shrink/expand data. You didn't understand what I am proposing. The proposal to change the defaults is simply s side effect enabled by the deprecation of all current API to create boxes. There will be new API to create boxes, so there will be essentially a new widget, and this widget can have new defaults. If all the benefits is in changing the defaults, there is positively no reason to run around and deprecate hbox and vbox. If that part has a secret benefit (*huge* or otherwise) then weigh that against the pain for application developers. If the pain is all you care about, I suggest you grep some source codes a bit. Gnumeric has like ten HBoxes and ten VBoxes in C code and a lot of them in .glade files. The C ones take half and hour to port, the glade ones take a regex. Where is the pain? It no more pain than any other deprecation. In other words: you seem to be proposing two separate things here, only one of them has any stated benefit -- you say *huge*, I say save-the-occasional extra line. The other part no-one is even trying to defend and it is clearly going to be painful for application developers, especially for anyone targeting 2.x and 3.x at the same time. Drop that part asap. (Asap, I see... thank you for sounding so refreshingly patronizing again) I suggest instead that you drop the idea asap to target 2.x and 3.x at the same time please. This is just as insane as supporting 1.2 and 2.x at the same time. Have one branch for 2.x, have another one for 3.x. All the fiery words aside... it seems more useful to compare a tree that supports 2.12 and 2.16 right now, to one that supports 2.12 and 3.0 in the near future. And considering that there's a smooth upgrade path as opposed to 1.x to 2.x, that doesn't seem all that foolish to me. Of course it depends on the application, but it's fairly possible. ciao, Christian ___ 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
Am Thu, 25 Sep 2008 02:20:35 +0300 schrieb Vlad Grecescu [EMAIL PROTECTED]: On Wed, Sep 24, 2008 at 12:12 AM, Emmanuele Bassi [EMAIL PROTECTED] wrote: = minutes for the 2008-09-23 meeting = * Deprecate the H/V split and add orientation instead + mitch has a patch deprecating all the H/V classes + adds a constructor for base classes + defaults can be fixed + subclassing is easier + change orientation at runtime + massive deprecation at branch for 2.90 + everyone agrees Hello, Just because you can make the base class easier to subclass (e.g. Box without HBox and VBox) doesn't mean you should get rid of the two specializations. you just have to inline, for each gtk_vbox_ method the gtk_box_ one Plus, its a verbosity thing: I like having VBox and HBox around when using Flex or XUL as much I preffer having them in Gtkaml i'm making. (instead of Box orientation='horizontal') To put it in another way: don't let over-generalization stump on easyness of use. Do both:) I don't see how a box is special compared to labels, buttons, toolbars or any other widgets that can support different angles or orientation modes. It's nothing more than a flawed decision that was made a long time ago to me. Whenever you have a reason to differentiate widgets based on significant features, you can subclass them. If, for you, orientation happens to be important enough, go for it. But I personally don't think it generally benefits most people. The burden of rewriting code towards Gtk 3.0 is something else that I do see as an issue. I for one would rather locally introduce functions that emulate legacy widgets than maintaining two versions of my code for Gtk 2.0 and Gtk 3.0. It might be helpful to actually write one such compatiblity layer that projects can include, which either emulates HFoo and VFoo accessors or provides gtk_foo_new style macros that fallback to legacy widgets. In any case, I'm looking forward to switching the orientation of widgets in one line, or a handful of lines if I need recursion. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: API's removed between 2.13.5 and 2.14.1
Am Wed, 24 Sep 2008 22:43:32 +0100 schrieb Matt Keenan [EMAIL PROTECTED]: Can anyone shed some light on why the following API's were removed from Gtk between 2.13.5 and 2.24.1 : * gtk_font_selection_get_face_entry * gtk_font_selection_get_family_entry Both of these were removed in 2.13.7 * 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. * gtk_window_get_default Removed in 2.13.6 That was a misnomer, there's gtk_window_get_default_widget now. Think of gdk_screen_get_default, gdk_display_get_default, gdk_keymap_get_default, gtk_settings_get_default, etc. etc. After adding the function during the sealing it was reconsidered. I can't find any reference in the ChangeLogs WRT why they were removed. Would this be considered an break in API compatibility ? For one, all of those were introduced and removed within development versions, which are not supposed to maintain API compatibility until a major, stable version is released - and 'stable' actually does mean API is frozen in all even 2.x.0 versions. I stated above what I remember off head, I'm pretty sure bugzilla will tell you more if you ask it kindly for the according bugs. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: string return result conventions
Am Mon, 15 Sep 2008 11:20:41 +0200 (CEST) schrieb Tim Janik [EMAIL PROTECTED]: On Mon, 15 Sep 2008, Luke Kenneth Casson Leighton wrote: clearly, the best overall thing would be to actually return the unicode strings themselves rather than convert them (needlessly?) to utf-8. Strings handed out by the Gtk+ API and also strings passed in to Gtk+ API are/must be in UFT-8 format already, so there's no need for conversion here. In this case I assume Luke is not referring to strings from Gtk+, though, but rather from WebKit, which does work with UTF-16, and hence the problem of having to allocate strings dynamically. Returning anything else than UTF-8 in a Gtk+-API is not acceptable. If that were an option, this discussion would be pretty much moot. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkstyle.c: gtk_draw_slider and gtk_draw_layout not deprecated?
Am Fri, 29 Aug 2008 19:10:20 +0100 schrieb Alberto Ruiz [EMAIL PROTECTED]: Hi all messing around with gtkstyle.c I've found that most gtk_draw operations were deprecated for their gtk_paint_ equivalent. Now, gtk_draw_slider and gtk_draw_layout are undocumented and no deprecated info is attached, however they also have a gtk_paint_ equivalent. I wonder if these functions are deprecated as well. Does anyone knows? They are effectively deprecated indeed, seems like a documenation bug. Filing a bug. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkstyle.c: gtk_draw_slider and gtk_draw_layout not deprecated?
Am Fri, 29 Aug 2008 20:28:02 +0200 schrieb Christian Dywan [EMAIL PROTECTED]: Am Fri, 29 Aug 2008 19:10:20 +0100 schrieb Alberto Ruiz [EMAIL PROTECTED]: Hi all messing around with gtkstyle.c I've found that most gtk_draw operations were deprecated for their gtk_paint_ equivalent. Now, gtk_draw_slider and gtk_draw_layout are undocumented and no deprecated info is attached, however they also have a gtk_paint_ equivalent. I wonder if these functions are deprecated as well. Does anyone knows? They are effectively deprecated indeed, seems like a documenation bug. Filing a bug. Hm... hold on, gtk doc marks them as deprecated here actually. Curiously, I can't find out where they are deprecated in the docs files. Should gtk doc be smart enough to see the macros? ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}
Am Mon, 25 Aug 2008 09:00:05 +0200 schrieb Mathias Hasselmann [EMAIL PROTECTED]: Hi, The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES and GTK_STOCK_NO encourages creation of horrible user interfaces. One recent example is on Planet GNOME right now[1]. Other examples were posted on Planet GNOME in the past, and still exist in applications like OpenOffice.org. So I wonder if we should deprecated those symbols, in the hope that people obey the GNOME HIG and properly label the buttons of their message dialogs. Hey, you did find a really nasty example there indeed. Would you like to continue ignoring those warnings does not only pose a rather bad question, it also includes a small secondary icon and a secondary message that looks simply confusing. However I have doubts that deprecating these stock icons can help much here. Even if the buttons weren't there, chances are that the developer still uses Yes and No labels, or if he, say chooses Ignore and Don't ignore instead and keeps the confusing layout with mutiple messages and multiple icons, the situation isn't much different from before. Just my two euro cents, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}
Am Mon, 25 Aug 2008 14:12:38 +0200 schrieb Murray Cumming [EMAIL PROTECTED]: At the least, any Yes/No stuff in the API reference documentation should have a note saying that they are generally a bad idea, probably with a link to the GNOME HIG. If we want to keep people from doing stupid things I agree, the API reference should just point out very expressly that one shouldn't use these buttons deliberately. I wouldn't assert so strongly that Yes and No are generally a bad idea, though. I think there are appropriate use cases. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: (1) How to implement Image Buttons without gaps? (2) Can GtkImage stretch an image automatically?
Am Wed, 20 Aug 2008 17:07:00 -0700 schrieb Daniel Yek [EMAIL PROTECTED]: [I sent this gtk-app-devel-list earlier, but I suppose this list might have an answer for me. I'm just trying to figure things out...] Hi, (1) I have been looking for a way to use GtkButton to create an Image Button that is exactly of the same size as the GtkImage that it contains, so that two Image Buttons next to each others would leave no gap in between. I have some ideas in mind, but I wonder if I'm going to over-engineering them and if there is a well-known approach to solve this, supposedly, common problem. For this first issue, this is the main idea that I am considering to investigate: (1a) Subclassing GtkButton and force it to allocate the size of the GtkImage it contains and overwrite all its drawing functionalities that cause non-image area to appear around GtkImage. If focus or default lines are to be drawn, draw them on the inside edge of GtkImage or suppress them entirely if necessary. I haven't looked into GtkButton source code lately, but I think this approach can potentially boil down to reimplementing the entire button from scratch to derive from GtkWidget, if GtkButton turns out to not allow a subclass to override certain drawing function. Reimplementing a new button widget can cause deviation in functionalities in future GTK+ releases and I want to avoid if there is a better solution available. I am hoping someone would point out to me an easier way to accomplish this. If GtkButton simply is not able to function as Image Buttons without gap, I wonder if GTK+ developers considered the usage during the process of GtkButton implementation/development? I wonder if the usage model was intentionally excluded (for reasons that I am obviously not sure of -- maybe for memory efficiency reasons; or for theming reasons)? Or is it simply the case that it wasn't implemented yet? Or is this usage model really unusual? Hey Daniel, you are not the first person with such a question, I see people asking that in the IRC about once a month. Basically you should not try to use a button only to try to suppress all its functionality, and that is what you are trying to do here. A button that draws only an image but not any other features of a button can just as well be that, an image. So the solution is as simple as putting an image in an event box and connecting your signals. Unless there's a special requirement you didn't mention, that's all you need. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Translucent Scrollbars
Am Tue, 19 Aug 2008 15:17:10 +0200 schrieb Mathias Hasselmann [EMAIL PROTECTED]: When looking at some Android screen shots[1] I've realized that their scrollbars are translucent. That's a really nice idea IMHO. I wonder if we can implement this feature in GTK+. Ciao, Mathias [1] http://www.spiegel.de/fotostrecke/fotostrecke-34358-7.html#backToArticle=572913 Hey Mathias, your example, and for that matter all screenshots with scrollbars on the linked site, is particularly a web browser. Are you thinking of a web widget only or generally of any widgets in Gtk that can be embedded in scrollbars? The latter might involve non-trivial changes, looking at how isolated scrollbars normally are from their child, there are even thick borders between the child and the scrollbars in the dozen engines/ themes I have tested here when writing this. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: When to call g_thread_init(), again...
Am Fri, 15 Aug 2008 15:45:29 +0300 schrieb Tor Lillqvist [EMAIL PROTECTED]: For example, Glib have g_mem_set_vtable() that alose requires to be first. Whee, so GLib documentation is internally inconsistent then. What a mess. Current wording of the g_thread_init() documentation doesn't introduces such ambiguility at least... It doesn't? I think You must call g_thread_init() before executing any other GLib functions in a threaded GLib program. is pretty unambiguous assuming you can decide what threaded program means. Or do you interpret this as once you have created a thread (thus turning your program into a threaded one), you must call g_thread_init() ? I don't think that makes sense. I think both is rather open for missunderstandings actually, before and after the improvement of the g_thread_init documentation. g_mem_set_vtable clearly asserts that it must be called *before anything else* and so does g_thread_init. There is no ambiguity with regard to when g_thread_init should be called as I see it. At best it's paradox that one is supposed to call two functions before each other, ie. before any Glib function. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk.HTML class nonexistent [was: Re: [pygtk] Computing optimum size of gtkhtml2.View]
Am Fri, 15 Aug 2008 19:20:10 + (UTC) schrieb Luke Kenneth Casson Leighton [EMAIL PROTECTED]: folks, hi, just an update: i was advised kindly to look at pywebkitgtk - which i downloaded and compiled from source, this morning. _wow_ am i dead impressed with this project! the demo browser example ran my javascript-only web site, http://lkcl.net and it _nearly_ managed to run my javascript-only site i'm developing, http://partyliveonline.com - except it segfaulted after login. _wow_ would i have been so impressed if it had worked first time :) the concept of having a standards-compliant browser, integrateable into apps using python... _wow_ :) anyway: i added in pywebkitgtk instead of python-gtkhtml2 and was pleased to find that it worked absolutely perfectly to provide [a missing] gtk.HTML-like widget. what i was _less_ impressed with is that it suffers *exactly* the same flaw that python-gtkhtml2 has: a widget created with pywebkitgtk *cannot* tell you what its width and height is, and so, if you insert it into an app, and the app size shrinks, the HTML - even if it's one line of HTML - gets chopped off. there's no enforcement of HTML content size communicated back to the gtk.Widget container. thus, sadly, pywebkitgtk is as useless as python-gtkhtml2 for doing the simple, simple job of putting HTML as simple as bhello /b into an application. also i haven't checked yet if object_requested is supported in pywebkitgtk or its equivalent - i hope so, because it's absolutely essential functionality . qt4 has support for Rich Text - simple things like b hello /b can be detected and displayed, and the size of the box is enforced as a minimum width and height onto the application. it's _essential_ that GTK have similar such functionality. implementing these features outside of the core gtk widget set - using pygtk2 alone - registers on the awkward to literally impossible scale. Hey Luke, it's nice to see someone content with WebKit. You should like to see this bug: https://bugs.webkit.org/show_bug.cgi?id=17154 There is actually an unfinished patch. So if someone wants that feature you are welcome to look into it. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: G_DEFINE_ARRAY, G_DEFINE_LIST
Am Wed, 6 Aug 2008 14:45:08 -0400 schrieb Havoc Pennington [EMAIL PROTECTED]: Hi, 2008/8/6 Mathias Hasselmann [EMAIL PROTECTED]: The following mail is about using the chance of breaking API with glib-3.0 for improving GArray and GList. I thought 3.0 had no API breaks in it? I suspect Mathias was actually referring to the option of deprecating the current GArray/ GList interfaces now and removing them in the breaking release. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: setting up a gtk dev environment
Am Sun, 27 Jul 2008 15:48:48 -0400 schrieb Patrick Hallinan [EMAIL PROTECTED]: On Sun, 2008-07-27 at 20:27 +0100, Simos Xenitellis wrote: On Sun, Jul 27, 2008 at 7:40 PM, Patrick Hallinan [EMAIL PROTECTED] wrote: On Sun, 2008-07-27 at 14:24 -0400, Paul Davis wrote: On Sun, 2008-07-27 at 14:08 -0400, Patrick Hallinan wrote: I didn't really want to get involved in working on jhbuild if I didn't have to but if that's what everyone is using then I will. Is this the preferred way to get a development setup for gtk+? Are there other good options? One of the goals of jhbuild is to spare you to setup your build environment manually, and as a bonus it knows where to obtain dozens of packages from. Once setup properly, you can build more or less all of Gnome in the same way without even knowing why it works. An alternative way is of course to install the packages of your choice to a custom prefix and adjust the environment, ie. PKG_CONFIG_PATH, LD_LIBRARY_PATH, and PATH. In fact, if you're experienced with linux, or your respective favourite operating system, that's not even hard. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: API for putting close buttons on tabs (proposal)
What do you think about this?
I think this is mostly going too far.
It is attractive to let the notebook provide close buttons,
which leads to consistency. And of course also less dublicated code.
That's why I particularly like an api that merely toggles such buttons
on tabs.
/* Globally show|hide action areas on tabs */
void gtk_notebook_set_show_action_areas (GtkNotebook *notebook,
gboolean show);
gboolean gtk_notebook_get_show_action_areas (GtkNotebook *notebook);
/* Show|hide action area for a tab */
void gtk_notebook_set_show_action_area (GtkNotebook *notebook,
gboolean show, gint at_position);
gboolean gtk_notebook_get_show_action_area (GtkNotebook *notebook,
gint at_position);
These are redundant. If we decide for embedding arbitrary widgets in
tabs, it's totally sufficient that whatever widget was provided by the
application can be hidden or shown. The notebook wouldn't do anything
else.
/* Predefined action area types */
typedef enum
{
GTK_NOTEBOOK_ACTION_AREA_CLOSE
/* other types */
} GtkNotebookActionAreaType;
/* Set|get action area content for a tab by type */
void gtk_notebook_set_action_area_type (GtkNotebook *notebook,
GtkNotebookActionAreaType type, gint at_position);
However regarding ActionAreaType, I'm not sure what other types you
have in mind but I don't think that's very helpful. That makes only the
API rather complex for a rather limited use case.
If you have particular ideas in mind that are particularly suffering
from the problems you have with custom close buttons, go ahead. But
generalizing this doesn't seem worth the effort.
ciao,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: API for putting close buttons on tabs (proposal)
Am Thu, 26 Jun 2008 20:57:34 +0200 schrieb Dodji Seketeli [EMAIL PROTECTED]: Gossip would definitely make use of this. Like many others I suspect, we currently implement our own thing to do it. Nemiver also has its own implementation of it. I guess pretty much every single application out there that has got tabs for similar use cases has its own flavour, including Gedit, Epiphany etc ... So yes that would be pretty interesting to have in Gtk+, if anything else. I'm using a number of programs that could benefit from this, including medit, devhelp, liferea, pidgin, midori, xarchiver and vmware. Now that is only my small list. Think of other programs and then consider the amount of code involved in implementing close buttons (and icons) on tabs. ^_^ ___ 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
Am Mon, 09 Jun 2008 14:43:54 +0200 schrieb Murray Cumming [EMAIL PROTECTED]: On Mon, 2008-06-09 at 13:30 +0100, Martyn Russell wrote: Murray Cumming wrote: On Tue, 2008-06-03 at 13:34 +0200, Kristian Rietveld wrote: [snip] We should start to enforce the usage of single header includes and not make this optional. Mitch has been working on this and most is already in place in SVN trunk. [snip] What's the advantage of this? Has this been a real problem for GTK+ so far? The main advantages I can think of are: - When you add/remove/rename header files, you don't break all applications which directly included them. This seems like the only change. The rest is just about the convenience of using just gtk.h, which already exists. Forcing use of single include file does indeed seem useful for API stability, though I wonder if it's worth forcing people to include everything. Clearly not all people want to include just gtk.h, or they'd all be doing it already. Of course not everybody includes gtk.h at the moment, but that doesn't mean all of these people don't want to. There's simply no rule at the moment, so many will probably follow arbitrary code examples they find or even try out what works. This can even lead to compatibility problems if Gtk+ adds #include statements to files and suddenly a developer can get away with different #includes - which breaks builds against old Gtk+ versions. In the end, a clear policy is the only way to achieve a predictable situation. Regards, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Qt vs. Gtk+ holy war Was: Steps to get to GTK+ 3.0
Am Thu, 05 Jun 2008 12:25:02 +0200
schrieb Xavier Bestel [EMAIL PROTECTED]:
On Thu, 2008-06-05 at 08:59 +0200, Jean-Yves Lefort wrote:
Likewise, you can implement a class Foo containing an int property
bar using the GObject way:
#define G_TYPE_FOO (g_foo_get_type())
#define G_FOO(obj)
(G_TYPE_CHECK_INSTANCE_CAST((obj), G_TYPE_FOO, GFoo)) #define
G_FOO_CLASS(class) (G_TYPE_CHECK_CLASS_CAST((class),
G_TYPE_FOO, GFooClass)) #define G_IS_FOO(obj)
(G_TYPE_CHECK_INSTANE_TYPE((obj), G_TYPE_FOO)) #define
G_IS_FOO_CLASS(class) (G_TYPE_CHECK_CLASS_TYPE((class),
G_TYPE_FOO)) #define G_FOO_GET_CLASS(obj)
(G_TYPE_INSTANCE_GET_CLASS((obj), G_TYPE_FOO, GFooClass))
typedef struct
{
GObject base;
} GFoo;
typedef struct
{
GObjectClass base;
} GFooClass;
GType g_foo_get_type (void);
int g_foo_get_bar (GFoo *foo);
void g_foo_set_bar (GFoo *foo, int value);
enum {
PROP_0,
PROP_BAR
};
G_DEFINE_TYPE(GFoo, g_foo, G_TYPE_OBJECT)
static void g_foo_get_property (GObject *object,
guint prop_id,
GValue *value,
GParamSpec *pspec)
{
GFoo *foo = G_FOO(object);
switch (prop_id)
{
case PROP_BAR:
g_value_set_int(value, g_foo_get_bar(foo));
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID(object, prop_id,
pspec); break;
}
}
static void g_foo_set_property (GObject *object,
guint prop_id,
const GValue *value,
GParamSpec *pspec)
{
GFoo *foo = G_FOO(object);
switch (prop_id)
{
case PROP_BAR:
g_foo_set_bar(foo, g_value_get_int(value));
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID(object, prop_id,
pspec); break;
}
}
void g_foo_class_init (GFooClass *class)
{
GObjectClass *object_class = G_OBJECT_CLASS(foo);
object_class-get_property = g_foo_get_property;
object_class-set_property = g_foo_set_property;
g_object_class_install_property(class,
PROP_BAR,
g_param_spec_int(bar,
NULL,
NULL,
0,
G_MAXINT,
0,
G_PARAM_READWRITE));
}
void g_foo_init (GFoo *foo)
{
}
int g_foo_get_bar (GFoo *foo)
{
/* ... */
}
void g_foo_set_bar (GFoo *foo, int value)
{
/* ... */
}
or using the Qt way:
class QFoo : public QObject
{
Q_OBJECT
Q_PROPERTY(int bar READ bar WRITE setBar)
public:
void setBar (int value);
int bar () const;
};
void QFoo::setBar (int value)
{
// ...
}
int QFoo::bar ()
{
// ...
}
Which way do you prefer?
BTW here is how it would look in Vala:
using GLib;
public class Foo : Object {
public int bar { get; set; }
}
What about Genie even?
[indent=4]
uses
Glib
class Foo : Object
init
var bar = 0
Yours,
Christian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
