Re: High-resolution scroll events
Hi, Am Mittwoch, den 17.11.2010, 16:25 +0100 schrieb Max Schwarz: > > > Do you have an idea on how to implement this? I think Qt's model is quite > > > nice, they have a 'delta' field in their event [3] which gives more > > > precise information. Of course, If you want to retain API compability > > > (which I think you do) a new event would have to be introduced that is > > > emitted in parallel. > > > > No, you don't have to. Here is a patch for the Mac OS X backend which > > implements this. (Let me check tonight whether I can find my cleaned up > > version and attach it to that bug.) So, I updated to patch to something that applies to the current master branch. > But that would mean changing the frequency of the events, correct? > For every small wheel delta a new event has to be sent. Can current software > cope with that? I'd expect that it starts scrolling wildly ;-) Not at all. Because the widgets (usually) only modify GtkAdjustment and with that patch, the modification gets scaled with delta. So, if you emit 10 times more events and let them have a delta of 0.1, you'll still have the same effect (except for broken implementations outside of GTK+, but those will be pretty obviously broken in the way that they will scroll in huge steps and it will be difficult to accurately scroll at all -- those will have to be fixed to respect delta as well). > The problem is not with large deltas (which are thrown away in the current > OSX > version, if I understand the patch correctly), but with small deltas, which > get emitted from Xorg with a pretty high frequency. No, right now we implement the current X11 logic of scrolling on Mac OS X as well. There used to be multiple GdkEvents per NSEvent (but that didn't work out properly and thus, way reverted). So, feel free to go ahead with the patch I attached and you will see that applications without custom widgets work perfectly once you adapt the X11 backend of GDK to use the delta field as well. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: High-resolution scroll events
Hi, Am Mittwoch, den 17.11.2010, 13:29 +0100 schrieb Max Schwarz: > Do you have an idea on how to implement this? I think Qt's model is quite > nice, they have a 'delta' field in their event [3] which gives more precise > information. Of course, If you want to retain API compability (which I think > you do) a new event would have to be introduced that is emitted in parallel. No, you don't have to. Here is a patch for the Mac OS X backend which implements this. (Let me check tonight whether I can find my cleaned up version and attach it to that bug.) https://bugzilla.gnome.org/show_bug.cgi?id=516725 Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk3 planning
Hi, Am Freitag, den 25.06.2010, 14:12 -0400 schrieb Colin Walters: > On Fri, Jun 25, 2010 at 12:50 PM, Matthias Clasen > wrote: > > 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."? As someone who took an in-depth look at the code, yes, the RI stuff can land in 3.x after 3.0. It would bring quite some new deprecations but in 3.0 or later it would at least not break the ABI like it did with the 2.x series. AFAIK, the MPX/MT stuff can be done as well (just like multi-display support got added during GTK+ 2.x). For the theming, Carlos said that for his work, a smooth migration would be possible as well. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is it a bug in Gio::FileMonitor?
Hi, Am Mittwoch, den 02.06.2010, 04:26 +0300 schrieb Владимир: > > On Tue, Jun 1, 2010 at 12:57 PM, Alexander Larsson > wrote: > On Mon, 2010-05-31 at 17:36 +0300, Владимир wrote: > > > There is nothing "server" about change notification > coalesceing. If any > app downloads or copies a file you'll get a change event for > every call > to write() (if you read all events). This can easily be in the > hundreds > a second for the entire duration of the download/copy. So, any > UI that > tries to handle every change will more or less lock up. > > > You're talking about gio, I wanted to see what inotify would do in > same circumstances: > > > I started inotify to listen to all the events on my desktop folder, > then I took a large zip file (about 500MB) and started copying it to > the desktop folder. There was no "hundreds a second" events, just 4 > (four) events: IN_CREATE, then IN_OPEN, then IN_CLOSE_WRITE and > finally (as the copy finished) IN_ATTRIB. > > So inotify doesn't suffer from the Armageddon you describe, also it's > fast. How come gio would be doomed/overworked in such a scenario and > it's slow at reporting even 1 file change quickly. > > Sorry I don't mean to be harsh but after these conversations I'm > really starting to like inotify a lot more and disliking gio. For one thing: Please don't try to tell people that inotify is better than GIO. GIO can use inotify as a backend [1] on GNU/Linux and _has_ to use other backends on other platforms (just like Alex already mentioned). For the other: try to run something like this in several processes (10-20) in parallel on your downloaded file (preferably on a tmpfs to make sure the hard drive won't end up being the bottleneck at some point): $ split --bytes=4 $YOUR_DOWNLOADED_FILE inotify should pretty quickly make your monitoring application cough up. [1]http://git.gnome.org/browse/glib/tree/configure.in#n1626 Regards, Sven ___ 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 Montag, den 01.03.2010, 14:57 + schrieb Bastien Nocera: > Widgets > --- > > Having often used widgets in GTK+ means that we reduce differences in > appearance and behaviour between applications and make applications > easier to maintain. > > If the APIs are carefully thought of, usability and design changes can > be made without touching the applications. > > A couple of widgets were mentioned: > - a sidebar widget (which I never followed-up on): > https://bugzilla.gnome.org/show_bug.cgi?id=307044 > - a breadcrumb navigation widget (which could be used in nautilus, the > file chooser and yelp, for example) > No bugs filed, Cody will be working on filing a bug, and start > discussions about the API soon > - Segmented bar? It's used in Rhythmbox, Banshee, the Ubuntu installer > and could probably be used in others > There's a C version in Rhythmbox now: > https://bugzilla.gnome.org/show_bug.cgi?id=558576 > - Others? Application chooser widgets (dialog, button, menu). Just think of firefox' way to choose applications (regular file chooser). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Testing for memory leaks in GTK
Hi Erik, Am Dienstag, den 05.01.2010, 23:32 +1100 schrieb Erik de Castro Lopo: > I have written a small test program that can create independent toplevel > windows based on a command line parameter. Currently these top level > windows contain nothing more than a GtkLabel widget and destroy > themselves using a g_timeout after 30 seconds. When all the toplevel > windows have been destroyed the program calls gtk_main_quit() and then > terminates. Can you please post this program, so people can proofread/reproduce what you post? Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why do constructors return GtkWidget?
Hi, Am Mittwoch, den 04.11.2009, 06:23 +0100 schrieb Javier Jardón: > The question: why is it normal for GTK widget "constructors" to return > GtkWidget and not their real type? Cody perfectly replied to that already. > PD: If there is not technical reasons, maybe we can change this for > GTK+ 3 (or 4 ;)), as I think a change like this will break the 2.x > ABI. This change wouldn't break ABI (unless applications use). But it is a serious API impact (just think of all the warnings about "wrong" types in assignments. In my opinion the GTK+ way is really nice (just compare it to GStreamers element factory, which behaves essentially the same way, just as GnomeCanvas' gnome_canvas_item_new() function). It's really nice to get those items returned as the generic type (but Cody told you already). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: test locations
Benjamin, Am Montag, den 13.07.2009, 16:52 +0200 schrieb Benjamin Otte: > On Mon, Jul 13, 2009 at 3:55 PM, Martin Nordholts wrote: > > Always building the tests ensures that they are kept up do date with changes > > in the rest of the code base. If they are not built along with the rest of > > the code base then they will eventually become out of sync and someone has > > to fix them later, possibly months after the change that introduced the > > compilation errors were made. > > > That argument has essentially no value at all to me, for lots of reasons. And your complaints have essentially no value to me. As "make all-am" is already what you are looking for (and given that it already exists, Martin's points seem to be really convincing). What's the problem in just keeping to use "make all-am" for your compile-warning-testing and before you commit, execute "make all" and be happy (unless you changes the behavior, then you want to run "make check" as well). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ problem with time-consuming threads
Am Dienstag, den 05.05.2009, 18:57 -0700 schrieb patkhor: > I provide the user with the OK button, when user click on that button, the > program will create some number of threads (more than 10) and each threads > will do time-consuming work in the background. I successfully compiled my > program, but when I click on OK button, the main window freeze (display "not > responding" message on Windows machine). > > One person on this forum suggested to me (thank you very much) that I should > make the threads unjoinable because the main thread have to wait for all > threads to finish their execution that's why the main window freeze. So I > eliminate all g_thread_join() but the problem still occur. > > Could someone please give me little sample code that provide only one > button. When that button is clicked some number of threads will do something > time-consuming in the background (something simple like multiplying numbers > 1 times in the for loop, just to give me an idea). Did you check where your threads are blocking? (Ie. did you attach a debugger and check each thread?) Regards, Sven ___ 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 Samstag, den 28.03.2009, 12:37 +0100 schrieb Christian Dywan: > Am Fri, 27 Mar 2009 17:38:12 -0700 > schrieb "Eugenia Loli-Queru" : > > 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. I don't think we should favor one site over the other, just provide links to both sites and noone will be pissed off (with a proper reason) again. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Am Montag, den 16.03.2009, 11:49 +0100 schrieb Alexander Larsson: > On Mon, 2009-03-16 at 10:23 +, Michael Meeks wrote: > > On Sun, 2009-03-15 at 10:19 +0100, Alexander Larsson wrote: > > > But there are milllions of lines of code that does the rename as > > > atomic replace and the chances that anywhere near a majority of those > > > are "fixed" is extremely slim. Therefore everyone should be aware of > > > the broken filesystems that don't give data-before-metadata-on-rename > > > guarantees so that sane people can stay away from them. > > > > Out of interest, what distributions are shipping with ext4 configured > > in this helpful "loose your data" mode ? can we not simply inject the > > "go slower" patch into these ext4 distros [ since it won't affect their > > performance quite as badly as everywhere else ], as a temporary > > workaround; and then sit back and let the default glib behaviour be to > > work well on all sane systems ? :-) > > It seems both ubuntu and F11 will backport the ext4 fixes. However, even > with these fixed there is risk for data loss on e.g. xfs, and even ext3 > if you configure it in data=writeback mode. There was also reports from > nokia about it being unsafe on the flash file system they were using. If "flash file system" is this one (they mention Nokia on the website - 2nd link): http://www.linux-mtd.infradead.org/faq/ubifs.html#L_powercut http://www.linux-mtd.infradead.org/doc/ubifs.html This might be either not noticed by the developers or not an issue with their file system. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fsync in glib/gio
Hi,
Am Donnerstag, den 12.03.2009, 21:11 +0100 schrieb Alexander Larsson:
> typedef enum {
>G_FILE_CREATE_NONE= 0,
>G_FILE_CREATE_PRIVATE = (1 << 0),
> - G_FILE_CREATE_REPLACE_DESTINATION = (1 << 1)
> + G_FILE_CREATE_REPLACE_DESTINATION = (1 << 1),
> + G_FILE_CREATE_ASYNC_WRITE = (1 << 2),
> } GFileCreateFlags;
IIRC we have commits in GNOME canvas that remove trailing commas in
enums because of some compiler compatibility issue.
Regards,
Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bulding client-side-windows branch
Hi, Am Montag, den 16.02.2009, 09:51 +0100 schrieb Alexander Larsson: > On Mon, 2009-02-09 at 18:27 -0800, C.J. Adams-Collier wrote: > > I'm having a problem building gtk from Alex's branch. Am I doing > > something wrong? I had jhbuild take care of building the deps and got > > a jhbuild shell before starting the build. I ran configure this way: > > > > ./configure --prefix=/opt/gnome --disable-gtk-doc > > > > make gives me this (truncated, of course) > > I assume you ran autogen.sh first? > > I have no idea why this is happening, with respect to the gdk-pixbuf > directory the csw branch is an identical copy to the normal gtk. This actually sounds like a simply too old glib-mkenums; maybe there should be a dependency of a newer version of glib (or it's running against the system glib-mkenums even though there is another one). Regards, Sven ___ 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 Sonntag, den 08.02.2009, 13:07 +0100 schrieb Murray Cumming:
> 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.
AFAIR, you can flip it of you create a GtkBox/GtkScale, but not if you
create a Gtk[HV]{Box,Scale}... Mitch?
Regards,
Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Patch] Cursor cache
Hi, Am Montag, den 19.01.2009, 03:08 -0500 schrieb Matthias Clasen: > On Sun, Jan 18, 2009 at 12:24 PM, Dr. David Alan Gilbert > wrote: > > * Matthias Clasen (matthias.cla...@gmail.com) wrote: > >> On Sat, Jan 17, 2009 at 8:19 PM, Dr. David Alan Gilbert > >> wrote: > >> > * Matthias Clasen (matthias.cla...@gmail.com) wrote: > > Also, before GDK_BLANK_CURSOR can be used I guess the none-x11 versions > > have to be fixed up as well - I'll need a hand with that since I just > > have Linux. > > Yes, we usually rely on the backend fairies to fill in gaps like that (Hi > Tor!). But it would still be good to have a testcase in gdk, so backend maintainers will get a failed test result when they run "make check". Regards, Sven PS: I can also try to come up with a patch for adding a test case once this is committed. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
Am Montag, den 22.12.2008, 14:27 +0100 schrieb Olav Vitters: > On Mon, Dec 22, 2008 at 03:10:13PM +0200, Eugene Gorodinsky wrote: > > >Vala is a high level language which is translated to GObject and C, so > > >you are proposing to rewrite GObject using GObject. > > > > Vala can be modified, since it is open source and all. I'm not sure if > > that's feasible though, as I'm not familiar with it. > > Vala uses gobject. If you suspect gobject is slow, changes in vala won't > affect gtk+. I think he proposed to rewrite GTK+ on top of vala and then rewrite vala to be faster than GObject (by using its own stuff, etc). So the real issue would be that we think "one can't provide the features of gobject with 50% of GObject's CPU usage". Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[Patch] Re: Howto retrieve selected font size from GtkFontButton
http://bugzilla.gnome.org/show_bug.cgi?id=562998 Regards, Sven ___ 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 Dienstag, den 02.12.2008, 14:55 +0100 schrieb Christian Dywan: > 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. Right. So, Nelson, if you want to render something with the font, just use pango_font_description_from_string() and use the font description. If you're interested in peeking certain values (family name, style, size, weight), just query these properties from the PangoFontDescription. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_utf8_validate() and NUL characters
Hi, Am Donnerstag, den 09.10.2008, 00:01 + schrieb Maciej Katafiasz: > Den Tue, 07 Oct 2008 16:55:29 -0400 skrev Behdad Esfahbod: > > coda wrote: > >> Another possibility mentioned was making more use of GString. > > > > Not a huge fan. > > Why's that? GString is a very odd animal, we have it, it works fine and > is as good a string implementation and as compatible with char* as > possible within C, yet it seems to be used exactly nowhere. What's the > reason not to use GStrings if they do just what's needed? Or why do we > have them if no-one wants to use them? Maciej, don't think of GString as the equivalent of eg. java.lang.String, it's more an equivalent of java.lang.StringBuffer. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Patch biohazard report, Sep 29th
Am Montag, den 29.09.2008, 15:34 +0200 schrieb Christian Dywan: > Low hanging fruits: Plus this one: http://bugzilla.gnome.org/show_bug.cgi?id=548666 Bug 548666 – [PATCH] Allow searching for a given item in a GSequence Patch attached; applies cleanly; documentation in there; even a test case Regards, Sven ___ 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 Mittwoch, den 24.09.2008, 18:03 +0200 schrieb Xavier Bestel: > BTW where can I find a list of 2.90/3.0-deprecations ? 2.90 and 3.0 won't deprecate anything. Your list will be the list of deprecated API shipped with 2.16.0. Regards, Sven ___ 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
Hi, Am Mittwoch, den 24.09.2008, 11:23 -0400 schrieb Morten Welinder: > > I don't think the minutes reflect what was said in the meeting here. > > My understanding was hat the H/V subclasses get deprecated as soon > > as the code to enable flipping in their parent classes is in SVN. > > If, say, gtk_hbox_new was to get deprecated and disappear in 3.x then > it would be near-impossible to write a program to compile against both > 2.x and 3.x > > Do we really, really need to impose that pain on developers? > Or am I misunderstanding what is being proposed? AFAIU, there will be a boolean property eg. on GtkBox which is automatically set to the correct value if you use the (deprecated in 2.16) GtkH/VBox containers. Being on 2.16, you can step-by-step replace each one with gtk_box_new(horiz/vert). Being API-compatible with 2.90 and 3.0, the code would just work on 3.0 without any further modifications. Regards, Sven ___ 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 Montag, den 25.08.2008, 14:12 +0200 schrieb Murray Cumming: > 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. And also, please mention that some languages don't even have proper equivalents for "yes" and "no" (IIRC, welsh [1]). [1] http://www.croeso-betws.org.uk/iaith/phrases.htm Regards, Sven ___ 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 Freitag, den 15.08.2008, 15:06 +0200 schrieb Christian Dywan: > Am Fri, 15 Aug 2008 15:45:29 +0300 > schrieb "Tor Lillqvist" <[EMAIL PROTECTED]>: > 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. Actually, g_thread_init() is part of libgthread, not libglib, so the order would be irrelevant :-) Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Late 2.14 feature request: Installing gtkhsv.h
Hi, Am Freitag, den 08.08.2008, 12:05 +0200 schrieb Michael Natterer: > The GtkHSV widget was originally ported from the GIMP "triangle" > color selector. > > Now I've finally managed to port the GIMP color selector > to the GTK widget, since it has become quite a lot better > than the GIMP thing in the meantime (it has keybindings > and antialiasing). > > However, the header is not installed, even though its symbols > are public (not prefixed with _) +1 from me; I think I have copied gtkhsv.[ch] into at least 3 pet projects or feature demos already. It would be nice to get rid of those copies, again. Regards, Sven ___ 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 Sonntag, den 27.07.2008, 15:48 -0400 schrieb Patrick Hallinan: > > I do not know why Werror would be enabled. If you cannot find the > reason, > > then when the compilation fails and you get the jhbuild options as to > > what to do, > > pick Option 4 which gives you a shell. Enter the guile directory and > > fix up what you can. > > > > 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? Well, fixing such a tiny thing in guile (probably by just dropping a line of code or marking a parameter with the unused attribute) should really be part of setting up your compilation environment. Otherwise you'd have a much harder time figuring out how to set the proper environment variables (and which ones, and to what values, etc.) Maybe you can also add this to your jhbuildrc to skip building guile: skip=['guile'] Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: libgtk3deprecated (Re: About GTK+ 3.0 and deprecated things)
Hi, Am Donnerstag, den 17.07.2008, 20:18 +0200 schrieb Tim Janik: > On Thu, 17 Jul 2008, Martin Meyer wrote: > > 2) Is it entirely possible from a gtk perspective to have all that > > code detached from gtk-core and placed in a different library? Are > > there any deprecated things that this would *not* work for? Maybe we > > can detach as many as possible and leave the rest in place for now. > > Complete deprecated widgets should be fairly easy to separarte, > single deprecated functions that some components may have can be > hard to impossible to move when the implementation requires > access to internals. But this could be worked around with a strange compile setup, right? With something like this: ~/sources/gtk+ ~/sources/gtk-deprecated and gcc -I$(top_srcdir)/../gtk+/gtk to access potential gtkwidgetpriv.h, right? Would mean "recompile with every source change to gtk+" but if some (many?) people depend on this, I think they can easily distribute the burden of maintaining a parallel version. > A closing word on the library name, since this'd be an ABI break, > such a library only makes sense for Gtk+-3.0 (or 2.99.0) and should > probably advertise that it ships deprecated Gtk+ stuff. So the best > name is probably libgtk3deprecated for this (there could possibly > be a libgtk4deprecated as well at some point). Well, so GTK+ 4.0 could be accompanied by these two: libgtk3deprecated-4.0.so libgtk4deprecated-3.0.so Right? Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Am Donnerstag, den 17.07.2008, 06:59 -0500 schrieb Travis Watkins: > On Thu, Jul 17, 2008 at 6:51 AM, Kalle Vahlman <[EMAIL PROTECTED]> wrote: > The problem is this "code cleanup release" breaks everyone's > applications for no reason. This is wrong for 2 reasons: 1. It does only breaks apps that don't compile with disable-deprecated or enable-broken; that's far from "everyone's" 2. There are reasons, they have been mentioned quite a few times (code cleanup, more possibilities for refactoring, etc.) > No one has shown a case where the current > situation makes a fix impossible and no one has proven any interesting > new features (other than whole new widgets, which we can do now) can > be added to 'gtk+ 3.0' without breaking API/ABI. We're going to get > terrible backlash from a 3.0 that has zero new features and I suspect > any of the promised shiny bits will end up having to wait until 4.0 > anyway. Wring, just read Kris' email, he's mentioning very concrete development ideas that are not possible without breaking the current API, but that would be possible if we had properly sealed from the beginning. > In the end all we get is the ability to drop some old widgets no one > spends time on anyway. Isn't that a good thing, too? Dropping unmaintained stuff so others won't use it and might be disappointed because of the bad state of it? Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Hi, Am Mittwoch, den 16.07.2008, 18:08 -0400 schrieb Paul Davis: > On Wed, 2008-07-16 at 16:51 -0400, Morten Welinder wrote: > i totally agree with those who are arguing against the current notion of > what GTK3 should be. i haven't seen any evidence that any of the > problems that our developers face with GTK are going to be easier to > address after the proposals for 3.0 are complete, with the possible > exception of themeing. it is suggested that once G_SEAL etc. is > complete, it will become easier to "fix the problems". i've mentioned > our problems before ... once again, none of the people working on GTK > have ever said to me "oh, once 3.0 is done that will be much easier to > fix". the closest might be kris' refusal to look at the treeview DnD > situation in 2.X because he has a completely new implementation of the > entire widget (family) waiting in the wings. does this need G_SEAL to > make it work? Paul, just in case this wasn't made clear enough already; the GTK+ team want to deploy a GTK+3 that will be API-compatible to the latest GTK+2 including all deprecation flags that are there (disable deprecated, multihead safe, single header include, etc.). There are these simple things you can do to get your app easily 3.0 compatible: 1. make sure your application compiles with these flags 2. if you use deprecated/considered-broken widgets/classes, copy them into your project and change the namespace from gtk to your project's namespace. After that, everything should be fine. Plus I heard rumors about some refactoring tools being developed so we (app developers) can easily get our code compatible for 3.0. The reference counting pains and the GtkArgs removal etc. were a REAL pain (compared to the points above), also adding lots of new code. But with GTK+3, there are no evil changes like this queued. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Astonishing allocation bug in glib-2.16.4 compiled with gcc 2.96
Hi Alessandro, Am Dienstag, den 15.07.2008, 17:04 +0200 schrieb Alessandro Vesely: > What would you say about that It's pretty nice, I only have two comments: * you change "only for debugging" to "always for debugging", maybe you should simply use "iff" (or the expanded version "if and only if") * you drop the section about downsides of the advanced debugging, please keep them in there Regards, Sven -- Sven Herzberg Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Astonishing allocation bug in glib-2.16.4 compiled with gcc 2.96
Am Dienstag, den 15.07.2008, 14:13 +0200 schrieb Alessandro Vesely: > I didn't mean glib's test suite. What I wanted to say is that any > client program that has its own test suite should enable debug-blocks > in it. The above page should explicitly encourage such practice, IMHO. > Overlapping variables not always result in program crashes, it can be > worse. Feel free to provide a patch for the documentation. It's all in glib's subversion repository. Regards, Sven -- Sven Herzberg Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is this a bug of GMainLoop?
Hi, Am Mittwoch, den 14.05.2008, 09:34 +0800 schrieb #YU KUAN#: > At this point G_IO_OUT is surely ok, the mainloop thread returns from > poll and sends one byte to server in callback. > > Then the program watches for G_IO_IN. mainloop thread will block. > > Then the program sleeps for a while, and watches for G_IO_OUT. > > Here, I wish the mainloop thread to return from poll with G_IO_OUT > event. > > However, mainloop will block instead of returning from poll. > > > > I think the problem is FD_WRITE will not signaled again until send > returns WSAEWOULDBLOCK on windows. > > Is this a bug of GMainLoop? Absolutely not; this is a bug in your code (more exactly a missing call to g_io_channel_set_flags()); check the documentation for proper usage of this function. Also, application development questions should be raised on gtk-app-devel-list (and think of the vast amount of gtk+ based software out there, it's quite unlikely that you hit a massive bug like this). Regards, Sven -- Sven Herzberg Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Quoting GPL 2: »However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.« Regards, Sven Am Dienstag, den 18.03.2008, 12:35 +0100 schrieb Lieven van der Heide: > Does that really apply for the code you link to? Afaik, if a GPL > program uses an LGPL library, it doesn't relicense that library under > GPL too, it merely links to it, and leaves it up to the user to make > sure the library is available. If this would be the case, than it > wouldn't be possible for GPL code to use something like the Windows > API or DirectX either. > > I think the restriction from the link you posted only apply to GPL > libraries, but not LGPL. > > On 3/17/08, Mathias Hasselmann <[EMAIL PROTECTED]> wrote: > > > > Am Montag, den 17.03.2008, 00:31 +0100 schrieb Mathias Hasselmann: > > > > > I am really wondering what's the reason for FSF claiming, that > > > programs > > > licenced GPL-2 only are not allowed to use LGPL-3 libraries. The LGPL-3 > > > allows non-free, proprietary programs to use LGPL-3 libraries, but > > > excludes free software, licensed GPL-2 only? This sounds absurd to me! > > > > > > Is the FSF spreading FUD with their license matrix? Why doesn't the > > > matrix have footnotes explaining that absurd conflict? > > > > > > Ok, it is not FUD. It seems the problem is, that LGPLv3 imposes > > additional restrictions not found in the GPLv2. So it isn't the LGPLv3 > > that forbids LGPLv3 libraries to be used by GPLv2-only programs. It is > > the GPLv2 which forbids to linking against libraries more restrictive > > than itself. > > > > See http://www.fsf.org/licensing/licenses/gpl-faq.html#v2v3Compatibility > > for details. > > > > In theory LGPLv3 allows addition of exceptions, but they have to be > > approved by all copyright holders. Doubt this will happen. So only > > chance for upgrading to a new version of the LGPL is waiting for an FSF > > approved version of the LGPL, which drops those additional restrictions > > for GPLv2-only programs. > > > > Total insanity... > > > > > > Ciao, > > Mathias > > -- > > Mathias Hasselmann <[EMAIL PROTECTED]> > > Openismus GmbH: http://www.openismus.com/ > > Personal Site: http://taschenorakel.de/ > > > > ___ > > gtk-devel-list mailing list > > gtk-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > > > > > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Hi Tommi, Am Dienstag, den 18.03.2008, 11:56 +0200 schrieb Tommi Komulainen: > On Sat, 2008-03-15 at 21:03 +0100, ext ryan lortie wrote: > > After some talk at the Hackfest about it, I'm writing the list to > > officially request that glib and GTK be moved to LGPL "version 3 or > > later". > > IANAL and all, but here are a few points for consideration based on my > experience after being exposed to Nokia legal machinery. > > 1. Changing the wording from "version 2 or later" to "version 3 or > later" will remove the "2 or later" option. To my understanding > changing the terms of the license text counts as relicensing. Not really, using "LGPL 2 or later" code unter the terms of "LGPL 3 or later" is explicitly allowed by the "or later" amendment. Replacing the "LGPL 2" part of that phrase with "LGPL 3" is completely okay. The text would only have to be changed once the first patches with "LGPL 3 or later" (no LGPL 2 anymore) start getting applied. Remember, anyone is still free to use the last release published under "LGPL 2 or later" (that's why I actually think that we should only do that with GTK+ 3.0 if we have really large/good features arriving after 3.0 which people will want to see in their applications - to make them consider relicensing). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Request for API/ABI breaks in glib/gio
Am Freitag, den 22.02.2008, 16:34 +0100 schrieb Alexander Larsson: > The first one concerns g_uri_get_scheme. The webkit developers has plans > to add a GUri object in glib, and g_uri_get_scheme (which takes a uri > string and returns the scheme part) would conflict with the g_uri_ > namespace. Current proposal is to rename it to g_uri_parse_scheme. Wouldn't g_parse_uri_scheme() keep the g_uri_ namespace completely free? We've also discussed natural language order quite excessively but if ot comes for free when trying to preserve a namespace? > The other one is g_file_contains_file(). This was deprecated in favour > of a new identical functions called g_file_has_prefix() which betted > describes what it does. We still carry a macro that defines > g_file_contains_file to g_file_has_prefix, and a symbol for binary > backwards compat. However, this has a few more users. One in evince, one > in the panel, on in libgnomeui. (The uses in gvfs and nautilus has been > changed.) IIRC, gio hasn't had any "guaranteed-stable" release, right? So you could still just drop it I guess. > Its kind of bad to have to keep this compat function forever, not being > able to e.g. reuse that name for a better purpose. However, making this > change requires changing a few other packages, which is slightly more > problematic than the above. I'm not sure what the best approach is. What > is the opinion of the release team? I'm not on the release team, but I'd say +1 (to both) as having a mostly-clean API from the beginning should be good for everyone. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Can I use gtk_widget_unref() to releasetthe object created by gtk_invisible_new()?
Am Mittwoch, den 30.01.2008, 10:54 +0200 schrieb [EMAIL PROTECTED]: > The floating references in GTK make the whole reference counting a bit messy. > The following points make life easier: > > * Always have a matching g_object_unref for each g_object_ref you have You mean, g_object_ref_sink(). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Freitag, den 21.12.2007, 11:05 +0100 schrieb Mathias Hasselmann: > Am Donnerstag, den 20.12.2007, 11:46 -0500 schrieb Havoc Pennington: > > Third, since implementing an interface requires extra boilerplate > > GObject stuff, it would be convenient for authors of a custom widget if > > GtkWidget already did the boilerplate for them. Since for newly-written > > custom widgets, the recommendation would be to always support extended > > layout. > > I don't see the boilerplate savings you talk about? As far as I > understand GObject interfaces, you always need this this single-line > boilerplate for overriding interface methods: > > G_DEFINE_TYPE_WITH_CODE (MamanBar, maman, GTK_TYPE_WIDGET, > G_IMPLEMENT_INTERFACE (GTK_TYPE_IFACE, maman_bar_iface_init)) Not if GtkWidget already implements GtkExtendedLayout->get_min_size() like this: GTK_WIDGET_GET_CLASS(instance)->get_min_size. Then you could easily override the implementation in class_init(). I think this was what Havoc meant. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GIO API review
Alexander Larsson wrote: > On Thu, 2007-12-13 at 14:50 +0100, Michael Natterer wrote: > >> Alexander Larsson wrote: >> >>> On Wed, 2007-12-12 at 16:46 +0100, Michael Natterer wrote: >>> Alexander Larsson wrote: > On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote: > >> Hey everybody, >> >> We've been doing a GIO API review in the last couple of days and >> here is the list of comments and issues we've come up with: >> >> >> General: >> >> >> It seems GIO allows individual files to be included, this should be >> avoided like gobject does it: >> >> #if !defined (__GLIB_GIO_H_INSIDE__) && !defined (GIO_COMPILATION) >> #error "Only can be included directly." >> #endif >> > Why? I know gobject does this, but I never understood why. It seems to > just make build times longer. > Because otherwise you get into the very same typedef and include mess we have in glib and gtk+. It makes it *very* hard to change anything type related in the future. Any addition of a new function that happens to use a new type which was not used in that header before might work fine for the library's build itdelf, but might break the build of applications that include whatever combination of headers. Clear structure of headers and types should never be traded for compile time, we also keep distinct things in distinct .c files. Why would we scatter our typedefs across our libraries, or keep certain includes in headers forever? >>> Ok. I guess this makes sense. I'll do this. >>> >> Thanks :-) >> >> I forgot to mention, gobject has its common header in glib/. I'm not >> quite sure about this decision and I'm also not sure if saying >> >> #include >> >> or >> >> #include >> >> is the more "natural" thing to do... Just for consideration. >> > > I'm for . It seems more inline with all our other libraries. > Only gobject does the thing. > Shouldn't be enough? This would really drop 4 letters that every gio-using developer had to type and which are really redundant. I really don't like this style because it forces developers just to type more than they IMHO should. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtester git repo (Re: GLib testing framework)
Your API has g_test_rand_bit() which should (IMO) be called g_test_rand_boolean() to match the fundamental type's name that's used for this in glib (gboolean) and also to provide consistency with g_rand_boolean(). I think a difference to the rest of the g_* API isn't really helpful in using the new test framework (imagine someone porting self-written tests to the framework and the g_rand_boolean() has to be replaced with g_test_rand_bit() - feels a little odd). Regards, Sven Am 08.11.2007 um 15:59 schrieb Tim Janik: > On Tue, 6 Nov 2007, Tim Janik wrote: > >> i've checked in Sven's and my code into a git-svn mirror of glib on >> testbit.eu. so you can browse the recent changes here: >> http://testbit.eu/gitdata?p=glib.git;a=shortlog;h=gtester >> >> e.g. todays latest version of the testing examples is here: >> http://testbit.eu/gitdata?p=glib.git;a=blob;f=glib/tests/ >> testing.c;hb=9c8ae8c0097b8f7c098970e87bf413cd9c4f6a22 > > i've created a different repo for testing framework previews now, > as cloning the above includes dozens of megabytes for all of the > GLib history. > > the new shallow repo is here: >http://git.imendio.com/?p=timj/glib-testing.git;a=summary > > the branch i'm currently pushing to is: >http://git.imendio.com/?p=timj/glib- > testing.git;a=shortlog;h=gtester1 > > i'll create gtester2, etc. everytime the branch is rebased onto > recent upstream changes. > the repo can be cloned with: >git-clone git://git.imendio.com/timj/glib-testing > > however building it might require this before autogen.sh: >mkdir -p build/win32/dirent build/win32/vs8 && > touch build/win32/vs8/Makefile.am build/win32/dirent/ > Makefile.am build/win32/Makefile.am build/Makefile.am > > --- > ciaoTJ > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
Alp Toker wrote: > Matthias Clasen wrote: > >> Well, I have certainly considered C ABI compatibility to be the main deciding >> factor when making such decisions. I'd say if C# interfaces are inflexible >> like >> that then mapping GObject interfaces directly to C# interfaces was probably >> wrong. >> > > This is totally missing the point. GObject interfaces exist to formalise > a pattern of design by contract. Even if the C compiler doesn't catch > and report incomplete interface implementations, that doesn't make it > correct to ship code that breaks the rules. > > Your argument is analogous to claiming that it's OK to change property > and signal names and parameters in an ABI-stable release because the C > compiler won't notice that anything has broken. > I think it's not about "the compiler doesn't barf". It was a design decision to be able to always extend interfaces. The only thing GTK+ (talking about the concrete additions) has to handle non-implementations gracefully, which it easily can by NULL-checking before calling into the interface implementation. Even a default implementation can be added to be called if the interface function is not explicitly implemented. This reminds me of the Microsoft API Design video that Philipp van Hoof has blogged about. The speaker even claims that MS is extending their .Net-interfaces in similar ways. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas use cases
Hey Petr, Petr Tomasek wrote: >> On related news, I've created in l.g.o a page to keep track of use >> cases, as well as a feature matrix for available canvases plus other >> reference ones, the page is at: >> >> http://live.gnome.org/ProjectRidley/CanvasOverview >> > > The matrix seems nice, but maybe some performance comparission > wouldn't be bad.. Do you have a something concrete you'd like to get implemented and measured? If you have a concrete idea, I can implement and benchmark it for libccc (and if I'm not satisfied: but some effort into improving the benchmark). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject Interface vs Pure Virtual Class
Kuang-Chun Cheng wrote: > Hi, > > I'm studying GObject system and found that I can implement both > Pure Virtual Class (by setting all member functions NULL to make the > class pure virtual) > and an Interface in GObject. > > I'm a C programmer without much C++ experiences, but according > to my understanding ... pure virtual class in C++ is Interface. Am I > correct ? > > My guess is, in GObject, provide extra API to implement an Interface > is just another easier way to implement pure virtual class. > GObject interface will add more internal check which is better > than just set the member function to NULL, but ... there are > the same stuff, am I correct ? > > Does any other good reason why GObject need an extra API set > for Interface ? > > What's the different between Pure Virtual Class and Interface > in GObject system ? GObject doesn't support multiple inheritance. So you can have only one GObject-based parent class, but implement multiple interfaces. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: goocanvas notes
Carl Worth wrote: > On Mon, 30 Apr 2007 12:52:55 -0400, Havoc Pennington wrote: > > The latest commit mentioned there talks about a 0.0.5 release, but I > don't know where a tar file for that might exist. Sven? > Yves had two small issues with my test-tarball of 0.0.5 and I'm going to fix these things until the weekend and then make a release. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
libccc (was: Re: goocanvas notes)
Havoc Pennington wrote: > If that makes sense, I'd suggest that others review and write up their > thinking on GooCanvas, perhaps reading some of the old threads, Piccolo, > HippoCanvas, etc. as background material. And also if there are other > canvas maintainers who want to put their hat in the ring, they should > probably speak up. > I'd also propose libccc as a candidate for a GtkCanvas: http://live.gnome.org/Criawips/CriaCanvas Regards, Sven PS: I'm going to release 0.0.5 this week. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Carlos Garnacho wrote: > Hello!, > > On Fri, 2007-04-20 at 17:11 +0200, Sven Herzberg wrote: > >> Marco Pesenti Gritti wrote: >> >>> There is something which bothers me though. Support for some units, >>> points for example, would require floating points measures. And I >>> suspect we don't want to do layout in floating point (instability >>> issues). Mozilla converts css units in twips (an arbitrary integer >>> unit, 1/20 of a point). That's a way to go about it I guess, though it >>> requires conversions it in the canvas items. Better ideas? >>> >> This is a very important aspect, right. Especially with the upcoming >> *resolution independence* in MacOS X, people will start requesting this >> feature in GTK+ as well. So we should really add resolution independence >> to the feature list. This would at least satisfy the request for >> increasing widget spacing if the resolution increases (so we can have >> something like "1mm" between widgets). >> > > Sadly, I see a some problems here: > > 1) We don't control the hardware our software is running on. > So, where's this a problem? > 2) Broken X servers reporting bad dpi values, relying just on > modern/non-broken servers doesn't look very attractive either... > There are also broken flatpanels that report broken sizes. But this is not a big deal if the user has got an easy way of specifying the correct resolution. > 3) I bet there's still lots of people with 800x600 (or worse) screens > So what? The resolution independence will improve the situation for them, because 1mm will be less pixels on the same display with 800x600 (compared to 1024x768). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Marco Pesenti Gritti wrote: > There is something which bothers me though. Support for some units, > points for example, would require floating points measures. And I > suspect we don't want to do layout in floating point (instability > issues). Mozilla converts css units in twips (an arbitrary integer > unit, 1/20 of a point). That's a way to go about it I guess, though it > requires conversions it in the canvas items. Better ideas? This is a very important aspect, right. Especially with the upcoming *resolution independence* in MacOS X, people will start requesting this feature in GTK+ as well. So we should really add resolution independence to the feature list. This would at least satisfy the request for increasing widget spacing if the resolution increases (so we can have something like "1mm" between widgets). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Carlos Garnacho wrote: > First of all we need to specify the feature requirements for the > canvas. The following is a list of features I think we should > consider, hope it's a good start, please add to it if there are others: > > - GTK+ suitable API. > - a11y support. > - Model/View split. > - Size negociation, height for width, width for height and natural size. > - object shapes, collision detection. > - animation framework (perhaps should be more tied to GTK+, GtkTimeLine > maybe?). > - get the offscreen rendering patch in. > - GtkPrint* integration. > - grouping/ungrouping. > - extensibility, being able to create new canvas elements with little > effort. > - DnD support. > Sounds pretty good until this point. Benjamin just mentioned in IRC that *theming* is also pretty important. We want to be able to render the same canvas item in different ways for different themes. > - Integrate tightly GTK+ and the canvas, even making GtkWidgets > specialized canvas elements drawn with a certain layout in a canvas, see > Havoc's proposal [3] > I don't think the GtkWidget API and the GtkCanvas API shouldn't be tied together too much. I would like to see the canvas approch being "the new API" and the widget API to become some legacy API (to make app porting easier). As long as we can have these two things everything should be fine: 1. A CanvasWidget: a canvas item that can serve as a GtkContainer for GtkWidgets (so you can have widgets inside the canvas) 2. A WidgetCanvas: a GtkWidget that displays a GtkCanvas You can do everything you want with this structure, so I don't think there's a large need more (but maybe I'm alone with this opinion). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Cody Russell wrote: > I'd like the canvas system to be generalized enough that we can have > multiple implementations of it, in the same way that GDK allows us to > port to Win32 or MacOSX. In particular, I think we could have an > implementation that is much like what most of the canvases are doing > today where everything is software rendered.. Well, there are actually two generations of GTK+ related canvases out there. The GnomeCanvas family (with FooCanvas), which indeed does all the rendering in software. And then there's the cairo-based generation (libccc, goocanvas, hippocanvas, …). The cairo-based generation already isn't forced to being rendered in software. > but I also think we could > do an OpenGL backend, an OpenGL|ES backend, and possibly a Direct3d > backend if there were a reason to do one. > We already have this on the cairo level. You can render by using OpenGL using the Glitz backend. You can render hw-accelerated using the Xlib backend (which uses XRender). On windows, it uses a GDI backend. IMHO one of the biggest points of a canvas as a next gen widget system is that lots of window-system-dependent stuff isn't needed in canvas items anymore (in contrast to the GnomeCanvasItem::map stuff). > I've been putting some thought into the idea of a GPU-based GTK, and > when Havoc first mentioned going the route of having a canvas-based > widget system I became instantly interested in that because I thought it > was the perfect opportunity to go the GPU route. > Well, isn't the "right" way to go the cairo path and make the communication of cairo and the GPU faster (that's "improve Xrender, the drivers etc.")? As this needs to be improved for a "GPU based GTK" anyway you won't get any advantage by adding this new level of "platform independence" to GTK (which is already available in cairo). Unfortunately I'm not completely into the current state of hardware-accelerated cairo, but that information should be easy to collect. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.12 schedule?
Murray Cumming wrote: > On Fri, 2007-03-23 at 15:25 +0100, Michael Natterer wrote: > >> On Fri, 2007-03-23 at 15:17 +0100, Murray Cumming wrote: >> >>> On Fri, 2007-03-23 at 15:01 +0100, Kristian Rietveld wrote: >>> On Fri, Mar 23, 2007 at 01:45:11PM +0100, Murray Cumming wrote: > Could we agree on a schedule for GTK+ 2.12, please? I'd really like to > Since nobody complained about the schedule we devised at FOSDEM and I mailed to the list in my minutes a few weeks ago, I guess that will be our current working schedule. > know for sure that it will be ready for GNOME 2.20. > I personally object to guaranteeing that GTK+ 2.12 will be ready in time for GNOME 2.20. Yes, we should try to stick to a schedule everybody agrees with, but I don't want to rush out a release to be ready in time for GNOME 2.20, >>> Please let's try. It would be shame to have two GNOME releases with no >>> new GTK+ features. >>> >> It would be a shame to ship a broken GTK+ just because GNOME needs it, >> just as it happened before. The goal should IMHO be to ship a GTK+ >> that is as polished as possible within reasonable time, and *not* >> to follow external release cycles that are partly driven by commercial >> issues. >> > > That seems randomly anti-commerce to me. GNOME's release cycle isn't > driven by commercial issues. It's an attempt to ship what is ready if > it's ready, and to generally coordinate with other projects. GTK+ could > use a similar strategy, I believe, though I agree that GTK+ bugs are far > more critical than gnome-games bugs. > > So trying doesn't mean that we'd have to ship a broken GTK+. But GNOME > would decide quite soon whether they think GTK+ is likely to manage it, > and I don't think you need to worry about them being too optimistic. If you agree to ship what is ready if it's ready, then why not just rely on the GTK+ 2.10 API and maybe release with GTK+ 2.12 (even if not using the new API)? Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder report
On Do, 2007-01-11 at 14:12 +0100, Paolo Maggi wrote: > > - Object References & parsing of subhierarchies > > > >Libglade allowed the user to provide a "root" argument to > >glade_xml_new(), the builder doesnt do anything like that. > > > >Is this a requirement ? > > > > We use this feature of libglade a lot in gedit. > It is very useful when you want to write a class that extends GtkDialog and > whose > content is defined in a glade file. I also use it to specify different dialogs in one glade file and only load one dialog by specifying its name in the root parameter. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: has anyone valgrind'd gtk?
On Mi, 2006-12-06 at 22:00 +0800, [EMAIL PROTECTED] wrote: > The reality is that gtk is leaking. Let's call it »Your test case is leaking« (whether or not GTK+ is the source of that needs to be checked). > g_signal_newv() from within a g_object_new() from within a gtk_window_new() > isn't freed. This sounds to me that the window is not destroyed, which would be a bug in your testcase. Can you please reply to this email with your testcase attached (I'm pretty sure we can talk about leaks more easily if we are all able to run the test case on our own). > alot of the pango stuff (mostly called from within the gtk_label stuff, or > from > within the gtk_text stuff) not being freed. Sounds like the label didn't get destroyed yet (which would make sense with my guess above). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Getting Background app into focus
Hey Kaustubh, On Mi, 2006-11-29 at 10:38 +0530, Kaustubh Atrawalkar wrote: > How to get a background running application into focus by another > application? I mean there is a gtk application running on which another > gtk application is running. Now i need to get that background > application into focus from 3rd application like application switcher. I > tried to used the gtk_window_present in that the background application > jst pops up bt the focus still remains at the 3rd application. Is there > any other API i can use? This mailing list is about the development of GTK+ itself. If you have questions about developing GTK+ applications, feel free to subscribe and ask gtk-app-devel-list@gnome.org (I have an idea on how to help you, but as mentioned before - this is the wrong forum for this discussion). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
CCC: cairo based canvas 0.0.3
What is libccc? === Libccc is a canvas library designed to be easy to use and yet provide many useful features to application developers. Features: * API is similar to Gnome Canvas (but avoids several API bugs from Gnome Canvas) * Model/View based interface * Easily extensible (you only need to derive from one class) * Available for C and Python libccc 0.0.3 * improve applications performance by limiting redraws to ~33 FPS * added python bindings from Yves Combe * improve the redraw behavior of the circle item * fix drawing of multiple paths in sequence * CcText derives from CcShape to inherit fill and border properties * Added a skeleton to become a canvas editor * Fixed the license headers to always mention LGPL * Improved view (un)registration (CcItem) * Fixed Cursor Position (CcText) * Added image rendering (CcPixbuf) * Lines disappear correctly (CcLine) * Fixed a Segmentation fault in the demo application (patch by "Mardy", closes bug 335803) * Don't round widths smaller than 1.0 to avoid disappearing of thin lines Links = Download: http://download.savannah.gnu.org/releases/criawips/ Subversion: https://www.blaubeermuffin.de/svn/libccc/trunk ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Editable GtkLabel?
On Do, 2006-07-20 at 10:04 +0200, Murray Cumming wrote: > In the GTK+ meeting at GUADEC > ( http://www.gtk.org/plan/meetings/20060625.txt ) > there was talk of making GtkLabel editable. > > For what is this needed? You can to use that in UI builders like glade to edit menu items in place. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK-Canvas
On Di, 2006-02-28 at 02:18 -0500, Behdad Esfahbod wrote: > The obvious question, any plan to merge efforts with GooCanvas? GooCanvas has taken some decisions for its API that I tried to avoid from the beginning (e.g., having two classes per item-type) to make writing custom items easier (less code, especially an advantage for application developers who prefer to write their apps in C). But, of course, some items from GooCanvas might be worth a port to libccc. In November I was told, that the GooCanvas was just a proof of concept with Damon having not enough time for maintaining a canvas; I think we can sit together and try to get the best off both worlds. Regards, Sven signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK-Canvas
Hi there, I spend the last weeks to develop a cairo based canvas for GTK+. When developing that canvas I was inspired by the GNOME canvas API. For people who have been using the GNOME canvas, it's very easy to use, there's just one bis change: Model/View split. The dependency list of that canvas is quite short: GTK+ 2.8 with cairo and all the libraries below these two. If you want to play around with it, grab it with: svn co http://www.blaubeermuffin.de/svn/repos/libccc [I needed subversion for development and I plan to move the code to the GNOME servers once they're using subversion too] If you have questions, bug reports, recommendations, feel free to send them either per email (I read the lists I sent this email to) or take the newly created Wiki Page [1] and edit it. Regards, Sven [1] http://live.gnome.org/Criawips/CriaCanvas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Sponsored Canvas (was: Re: The state of the canvas)
Hi all, On Do, 2005-11-17 at 12:47 +0100, Jean Bréfort wrote: > It seems that things do not advance a lot by now. AFAIK, no much work > have been done except Alexander Larsson's patch available at: > http://bugzilla.gnome.org/show_bug.cgi?id=318807 > > David Bellot told me he is too busy at the moment to work on the canvas > and, personally, I am not just not able to write the whole thing alone. > As GnomeCanvas does not fulfill all my needs and might be soon > deprecated, I decided to replace it for GChemPaint by a light canvas (I > do not need many items, nor an optimized canvas) starting from > libgnomecanvas code. > > At the moment, I am working on a text item (still for the Gnome Canvas) > which uses Cairo and Pango for rendering. Hopefully, this code might be > useful for GtkCanvas if it exists one day ;-) sorry for the late reply, but I have been busy on the LWE 2005 in Frankfurt the last days. I was talking with Thomas Uhl about a cairo-based canvas for GTK+ which doesn't inherit ANY of the limitations that the GNOME Canvas and the deriving ones (Foocanvas, Goocanvas, etc.) already have [2]. Good news now: Thomas is sponsoring my work on a cairo based canvas which I want to use for my presentation application and which he needs for several other projects. The contract says that I will finish my work until the middle of February. I still have 3 weeks at my former employer, so I'd like to use these three weeks for discussion of the canvas and how it should be like. I've already set up a wiki page [1] about this. Feel free to add requirement there and please provide API samples if you need special features (so I have a clear impression of what you need). [1]http://www.criawips.org/wiki/Canvas [2]These limitations are (partially) documented on my canvas wiki page. Regards, Sven signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: replacing old C++ wrapping code in some headers files of GTK+ 2.6.7
Hi, I think it would be easier for the GTK+ people if you could contribute patches. If you're working with CVS (in case you don't: you should) just edit the files you want to change ans then create a patch by executing: cvs diff -Nup > changes.patch This will create a changes.patch file which you can attach and which can be easily checked in by the GTK+ maintainers (so you spend more time on searching and fixing and order less time of the maintainers for reviewing and commiting). Regards, Sven signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Icon theme and animated icons
On Do, 2005-02-17 at 13:23 +0200, [EMAIL PROTECTED] wrote: >2) Icon theme standard does not support mng/apng. > - implementation would not match > current standard, but > would still be compatible > with it. Well, as an apng file is supposed to be read as a png file too (read: thumbnailing for free) there could be no problem (as long as noone complains) because an animated apng theme should be fully backwards compatible as a png theme (at least if I understand the apng site and some other stuff correctly). Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Canvas API proposal
Am Samstag, den 12.02.2005, 23:13 +0100 schrieb Sven Herzberg: >Result >== >I have a small implementation called CCC (criawips' cairo-based canvas) >which can be made available to the public within 24 hours. It features a >basic rectangle type and a canvas model that easily allows grouping. It >is based upon cairo and I plan to use it as a foundation for the next >rendering infrastructure for criawips. > >I used it as a demonstration for GObject code at the 21C3 [2] late >december, so it is already a working base which needs to be extended to >provide all the object types that the gnome canvas provides. I don't >know (yet) how to integrate pango into the canvas to provide the same >rendering flexibility that GTK+ provides. The next thing is that I don't >know (yet) how to provide support for some GnomeCanvasWidget-style >element. So, here you are: Tarball: http://www.blaubeermuffin.de/stuff/ccc-0.0.1.tar.gz GTK-Doc: http://www.blaubeermuffin.de/ccc Feel free to comment and discuss. Regards, Sven -- Sven Herzberg <[EMAIL PROTECTED]> GNOME Deutschland Jabber <[EMAIL PROTECTED]>  ICQ <177176642> GnuPG Criawips  GnomeGCJ signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Canvas API proposal
Hi, some time ago (~1.5 years) I have been talking to Tim Janik about several things, so I came up to think about a canvas that provides the stuff that the GnomeCanvas provides (layers, easy redrawing, hit testing, etc.) without the ugly parts of the gnomecanvas api. With that in ming I started to elaborate a list of things that I want a canvas to provide: 1. Almost the same possibilities that GnomeCanvas provides 2. MVC split 3. To be extended easily (keyword: custom canvas objects) GtkTreeModel like API = With this in mind I wanted to have an API similar to the one of the GtkTreeView, though the GtkTreeModel has some limitations so it doesn't fit as a model for this case. The problem is that a TreeView is basically a tree with some kind of an array of data (thus the tree store is modelled in some kind of column based way). This can be done as each node of the tree has the same structure. As a canvas can e.g. include a rectangle, a circle and an image we have to deal with different kinds of nodes. My resolution about this was to have a HashTable that maps strings to attributes (so we are more flexible and still have the model managed quite easily). Custom canvas objects = With most MVC based implementations one usually has to write both a model object (read: an object that contains the data) and a view element (read: an object that renders data from a model object); if you have no idea about this, take a look at criawips' CVS [1] (block, slide, backround and the corresponding renderers). This would make extending the canvas quite hard as every custom canvas item needs to be written as a data item and a display item. As we store the data in a HashTable within the model, we can easily map these values to GObject properties. So we just need to implement the display part as a GObject derived type and we have the model being already as flexible as necessary. Result == I have a small implementation called CCC (criawips' cairo-based canvas) which can be made available to the public within 24 hours. It features a basic rectangle type and a canvas model that easily allows grouping. It is based upon cairo and I plan to use it as a foundation for the next rendering infrastructure for criawips. I used it as a demonstration for GObject code at the 21C3 [2] late december, so it is already a working base which needs to be extended to provide all the object types that the gnome canvas provides. I don't know (yet) how to integrate pango into the canvas to provide the same rendering flexibility that GTK+ provides. The next thing is that I don't know (yet) how to provide support for some GnomeCanvasWidget-style element. [1]http://cvs.gnome.org/viewcvs/criawips [2]http://21c3.ccc.de/ Regards, Sven -- Sven Herzberg <[EMAIL PROTECTED]> GNOME Deutschland Jabber <[EMAIL PROTECTED]>  ICQ <177176642> GnuPG Criawips  GnomeGCJ signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
