RE: Question about the default title of a GTK window
> Hey pals, I am a new comer on GTK things. > I have some questions about it, would any one have time taking me over it? > Here is it: > 1, What is the default title of a GTK window? I mean, if there is no string > was assigned to title of a GTK window, what will be exposed in the title bar > of said window? I got curious so I looked. All three implementation Win32, X11, and my favorite Quartz (Next Step, just cause that's what I'm working on now) implements gdk_window_new based on the underlying platform and are somewhat different. From what I can gather this is the part that gets the title and use the implementation specific library functions to set the actual title, with the text coming from this tidbit of code based on glib: in gdk_window_new_internal(){ (implementation specific code) if (attributes_mask & GDK_WA_TITLE) title = attributes->title; else title = get_default_title (); (implementation specific code).. } with the function get_default_title defined as: static const gchar * get_default_title (void) { const char *title; title = g_get_application_name (); if (!title) title = g_get_prgname (); return title; } in all implementation, thus the answer being, the executable name. > 2, Whether there is another interface for developers on setting title on GTK > window except gtk_window_set_title? I suppose you could use g_set_prgname() look at http://library.gnome.org/devel/glib/unstable/glib-Miscellaneous-Utility-Functions.html > 3, More specifications, will GTK framework take application name from > anywhere and set it as title into any untitled window in the application? > That all. Thanks alot. Take application name from anywhere? Huh? I can't say the function below is straight forward, I can only imaging its convolution is do the WIN32, but from what I can gather g_prgname is a global variable within the file, and as as mentioned initialized in gdk_init. Actually it comes from g_option_context_parse() in goption.c. Basically the function (very compiler depended) finds the program name and sets it, which intern becomes your very changeable window title. ** * g_get_prgname: * * Gets the name of the program. This name should not * be localized, contrast with g_get_application_name(). * (If you are using GDK or GTK+ the program name is set in gdk_init(), * which is called by gtk_init(). The program name is found by taking * the last component of argv[0].) * * Returns: the name of the program. The returned string belongs * to GLib and must not be modified or freed. */ gchar* g_get_prgname (void) { gchar* retval; G_LOCK (g_prgname); #ifdef G_OS_WIN32 if (g_prgname == NULL) { static gboolean beenhere = FALSE; if (!beenhere) { gchar *utf8_buf = NULL; wchar_t buf[MAX_PATH+1]; beenhere = TRUE; if (GetModuleFileNameW (GetModuleHandle (NULL), buf, G_N_ELEMENTS (buf)) > 0) utf8_buf = g_utf16_to_utf8 (buf, -1, NULL, NULL, NULL); if (utf8_buf) { g_prgname = g_path_get_basename (utf8_buf); g_free (utf8_buf); } } } #endif retval = g_prgname; G_UNLOCK (g_prgname); return retval; } I hope this answers your question. It sure helped me to answer it :) EMAILING FOR THE GREATER GOOD Join me > Date: Mon, 19 Oct 2009 08:30:56 -0700 > From: zheng.easy...@gmail.com > To: gtk-devel-list@gnome.org > Subject: Question about the default title of a GTK window > > > Hey pals, I am a new comer on GTK things. > I have some questions about it, would any one have time taking me over it? > Here is it: > 1, What is the default title of a GTK window? I mean, if there is no string > was assigned to title of a GTK window, what will be exposed in the title bar > of said window? > 2, Whether there is another interface for developers on setting title on GTK > window except gtk_window_set_title? > 3, More specifications, will GTK framework take application name from > anywhere and set it as title into any untitled window in the application? > That all. Thanks alot. > -- > View this message in context: > http://www.nabble.com/Question-about-the-default-title-of-a-GTK-window-tp25960347p25960347.html > Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. > > ___ > 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: Thumbnailing service project; opinions, suggestions?
On Wed, Oct 21, 2009 at 1:39 AM, Andrew Cowie wrote: > Mark, > > On Mon, 2009-10-19 at 16:32 +0200, Mark wrote: >> on school i study ... >> So this project, described in depth below... > > Keep in mind that contribution to an open source project doesn't have to > be bounded by school projects or an institution's academic calendar; you > are welcome to continue participating in the evolution of GTK long into > the future; indeed, people are going to be happier to work with you if > they think that you're going to be around for a while, thereby making > their investment in helping you more likely to have a long term impact. I know. I did contribute patched to gnome and am around here for years but just recently (as in the last few months) became capable of "understanding" parts of glib and making patches for things that are broken, have bugs or can be better (like: https://bugzilla.gnome.org/show_bug.cgi?id=594918) > > GTK is, of course, a very mature project (which in practise means it is > a core piece of the infrastructure of a huge number of production [in > use] systems), and it is worked on by people with a broad cross section > of interests and needs. In the end my project might be a pixbuf alternative ^_- . i might have added that blink but that thought did cross my mind more then once and if i optimize it the way i want (with opencl and such) then it might just get close to a new proposal to replace gdk-pixbuf with "Aldebaran" (the name of the project: http://en.wikipedia.org/wiki/Aldebaran .. i kinda like star names) with it's repo here: http://gitorious.org/aldebaran Other then that there is no GTK coding involved in it. only Glib. > > Which is why you've noticed considerable discussion from your original > message, and people adding other aspects to be considered, especially as > the specific thing you proposed intersects with ongoing FreeDesktop and > GNOME work. This may well take it out of the scope of something you can > do in your available school time, but that's the reality of something > that is as critical a player in the desktop as GTK. Regardless, I hope > you will choose to participate in the broader development of the > platform. This project will, if i not keep it tightly in bounds, go out of scope. So, there will probably be a future for this project but probably not as a thumbnailing service. In the end (and now i speak of one year from now) this project will either be dead or will be a image (scaling) library which Tumbler might even use ;). Note. this is all just guessing. it might end completely different > > Finally, I would observe that proposing ideas is important (including > for helping find people who might mentor you), but the best way to show > the quality of your idea is to write code implementing it and then > submit a patch for consideration. That is conflicting with others (although not said here). I used to hear things like: make a design, make a proposal, see how that works and then, if it's considered interesting write code. And that is exactly how this is going. What you propose is what would have me preference. > > AfC > Sydney Andrew, thank you for your nice post. It did give me some thought of how this project might have evolved in roughly a year from now. ___ 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
2009/10/21 Emmanuele Bassi : > = 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 :-) -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Fwd: gtk+ wrong code in JPEG loading module]
On Tue, Oct 20, 2009 at 6:08 PM, Federico Mena Quintero wrote: > This landed in my inbox - has anyone played with new versions of libjpeg > to see if this works? > I believe gentoo has been trying to get gtk to work with libjpeg7. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
Mark, On Mon, 2009-10-19 at 16:32 +0200, Mark wrote: > on school i study ... > So this project, described in depth below... Keep in mind that contribution to an open source project doesn't have to be bounded by school projects or an institution's academic calendar; you are welcome to continue participating in the evolution of GTK long into the future; indeed, people are going to be happier to work with you if they think that you're going to be around for a while, thereby making their investment in helping you more likely to have a long term impact. GTK is, of course, a very mature project (which in practise means it is a core piece of the infrastructure of a huge number of production [in use] systems), and it is worked on by people with a broad cross section of interests and needs. Which is why you've noticed considerable discussion from your original message, and people adding other aspects to be considered, especially as the specific thing you proposed intersects with ongoing FreeDesktop and GNOME work. This may well take it out of the scope of something you can do in your available school time, but that's the reality of something that is as critical a player in the desktop as GTK. Regardless, I hope you will choose to participate in the broader development of the platform. Finally, I would observe that proposing ideas is important (including for helping find people who might mentor you), but the best way to show the quality of your idea is to write code implementing it and then submit a patch for consideration. AfC Sydney 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
Minutes of the GTK+ Team Meeting - 2009-10-20
= 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 2. Git repository surgery [jjardon] - removal of the gtk-2.16 branch - rename of the gtk-2.90 branch to gtk-2-90 ACTION: desrt to operate 3. state of development branches for 2.20/2.90 - see point 1, re: massive mess of suggestions - xi2 requires testing with complex applications before review - resolution independence requires a high-level story for configuration before reviewing the API changes and more testing with non-gtk applications using gtk API - extended layout should hopefully get a review - deprecation of [H|V] variants or orientable widgets still depends on overriding the default value for properties in sub-classes 4. GtkCurve, GtkNotebook tab packing, non-multihead-safe API deprecation - deprecation of GtkCurve is agreed - deprecation of packing property for GtkNotebook is agreed - maybe deprecation of GtkRuler? - non-multihead-safe API removal for 2.90 is still on the fence, given the changes in X land; remote use case might still apply 4. glib 2.90 branching - glib 2.24 minus deprecations equals 3.0? - general agreement (also at the Summit): not worth doing a 3.0 - it really boils down to features getting traction 5. gobject-performance ACTION: wait for alexl and try to get the work done before glib-next 6. miscellaneous - some stuff fell through the cracks ACTION: next meeting in one week next IRC meeting: 2009-10-27 ciao, Emmanuele. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[Fwd: gtk+ wrong code in JPEG loading module]
This landed in my inbox - has anyone played with new versions of libjpeg to see if this works? Federico --- Begin Message --- Hello all This is a report to the authors mentioned in the gdk-pixbuf/io-jpeg.c module of the current gtk+ 2.18.0 package, from Guido Vollbeding, organizer Independent JPEG Group. I'm sorry if this way is inappropriate, but I'm not involved in any forums or mailing lists. Please forward to whom it may concern if possible. I have noticed various complaints about weird display of JPEG images with applications depending on gtk+ after upgrading to the new IJG JPEG 7 version, and I have seen faulty patches to the above mentioned module to work around the problem. I have now looked through the code and found the flawed code sequence in function "gdk_pixbuf__jpeg_image_load_increment". I strongly advise to correct the code by simply inserting the statement cinfo->scale_num = 1; in front of the following code sequence in mentioned function: for (cinfo->scale_denom = 2; cinfo->scale_denom <= 8; cinfo->scale_denom *= 2) { jpeg_calc_output_dimensions (cinfo); if (cinfo->output_width < width || cinfo->output_height < height) { cinfo->scale_denom /= 2; break; } } jpeg_calc_output_dimensions (cinfo); This addition will work with older and newer versions of the library. The implicit assumption of the given code that cinfo->scale_num is initialized with 1 by the JPEG library is no longer true for versions 7 and later! Version 7 initializes this field (and the other) with 8, and version 8 and later will initialize the fields with the (variable from 1 to 16) block size of the given JPEG file. (Note that the default resulting scaling factor remains 1 in any case.) The usual recommendation for versions up to 6 has always been that "scale_num" and "scale_denom" be set *simultaneously* by the calling application. Applications following this recommendation will not suffer an incompatibility with newer JPEG library versions. Newer applications (written for JPEG library versions 7 and later) MAY choose to set only one of both fields, because the initialization defaults are now depending on the input file and are specified as mentioned above. The given correction code simply retains the same behaviour with new JPEG library versions as with old JPEG library versions. The code may later be revised to utilize the more flexible scaling choices of v7 and later, but there is no need to do this now. I have not verified other code in the module. But this part is clearly wrong for use with newer JPEG library versions and requires correction, as it may affect a lot of gtk+ dependent applications. Regards Guido Vollbeding Organizer Independent JPEG Group --- End Message --- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Invalid typelib for module 'GLib'
Hi, I am seeing this build error while building gobject-introspection on ARM (EABI) --- Error log starts --- ../tools/g-ir-compiler --includedir=. GLib-2.0.gir -o GLib-2.0.typelib ** ERROR **: Invalid typelib for module 'GLib': In directory:The entry is contains invalid characters: LN10\u007f1\xb5\xbb\xb1k\u0002@ aborting... --- Error log ends --- Any pointers on what might be going wrong here? Could it be an ENDIANNESS issue? The same builds works fine on x86. Here is the complete build log: http://arm.koji.fedoraproject.org/koji/getfile?taskID=71821&name=build.log Kedar. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
The difference of mapping between toplevel window and popup window
Hello, I'm new to GTK+ programming.I encountered a problem in my program. There is a window which contain more widgets in my program, the widgets were mapped with more pictures(via gtkrc file ). The problem is: if the window is a toplevel window,you would saw flicker phenomenon; if the window is a popup window,you wouldn't saw flicker phenomenon,and mapped normally(no flikcer phenomenon). The flicker phenomenon not serious,but you could saw it with eyes.and popup window mapped normally( Why ?). The version of gtk is gtk+ - 2.12.9 (the OS is ubuntu 8.04 ), and it already set double buffer mechanism. How could I do to avoid flicker phenomenon ? Thanks, Eric ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Get window screenshot on 2.18.
Good afternoon! I'm experiencing some difficulties using 2.18 release. I'm trying to get window screenshot using such code (working on previous major releases, including 2.16): GdkWindowObject *private = (GdkWindowObject *)(window); GdkPixmap *internalPixmap = ((GdkWindowPaint *)private->paint_stack->data)->pixmap; if (internalPixmap == NULL) { return NULL; } // GdkPixmap *pixmap = gdk_pixmap_new(internalPixmap, width, height, -1); GdkGC *gc = gdk_gc_new(internalPixmap); // gdk_draw_drawable(pixmap, gc, internalPixmap, 0, 0, 0, 0, width, height); But I get nothing... Can anyone help, please? -- Best regards, Nikolay Zamosenchuk ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
2.18.1 directfb breakage
building 2.18.1 with directfb fails with gdkwindow-directfb.c:2077: error: conflicting types for '_gdk_windowing_window_at_pointer' ../../gdk/gdkinternals.h:460: note: previous declaration of '_gdk_windowing_window_at_pointer' was here gdkwindow-directfb.c: In function '_gdk_windowing_window_at_pointer': gdkwindow-directfb.c:2102: error: 'get_toplevel' undeclared (first use in this function) gdkwindow-directfb.c:2102: error: (Each undeclared identifier is reported only once gdkwindow-directfb.c:2102: error: for each function it appears in.) make[5]: *** [gdkwindow-directfb.lo] Error 1 --- gtk+-2.18.1/gdk/directfb/gdkwindow-directfb.c.orig 2009-10-01 12:25:20.0 -0400 +++ gtk+-2.18.1/gdk/directfb/gdkwindow-directfb.c 2009-10-01 12:25:13.0 -0400 @@ -2077,7 +2077,8 @@ _gdk_windowing_window_at_pointer (GdkDisplay *display, gint *win_x, gint *win_y, - GdkModifierType *mask) + GdkModifierType *mask, + gboolean get_toplevel) { GdkWindow *retval; gint wx, wy; @@ -2137,7 +2138,8 @@ gdk_directfb_window_get_pointer (_gdk_windowing_window_at_pointer (display, NULL, NULL, - NULL), + NULL, + FALSE), x, y, mask); } ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
>> Can i get the: >> - Git >> - gnome sub domain >> - blog for this project on planet gnome and/or gtk > > No one is bashing anything, but despite the many who agree, that this > project is NOT a requirement for GNOME or GTK (and since it is only for > school, a place that rots the brain) I would be shocked... SHOCKED... if > they provided you with a GIT, a gnome sub domain, and a blog. Then you have the wrong impression or didn't read everything. It was supposed to be just a single place where all information and progress would be collected. It was not at all my intend to somehow just get my name on there. Don't get me wrong. I can provide myself with all those requests bit not on the gnome site and i would have preferred that. On Tue, Oct 20, 2009 at 6:11 PM, Cosimo Cecchi wrote: > Hi Mark, > > On Tue, 2009-10-20 at 16:34 +0200, Mark wrote: > >> Now can we please quit bashing the idea that there will be 2 >> thumbnailing services in a few months time and can i get some >> constructive feedback about the ideas in my first post? >> Can i get the: >> - Git >> - gnome sub domain >> - blog for this project on planet gnome and/or gtk > > gtk-devel-list is *really* not the right place for this kind of > requests. Please read [1] for information about the GIT account > requests, [2] for Planet GNOME and [3] for the GNOME website. > Anyway, it seems to me that not having these kind of resources available > right now (or even not having them at all) should not block any > development of your project. It's not blocking or holding the project.. but then it might just end up on a local repository to never get released simply because i leave it rot on my hdd. It would just, for me, be nice that something that i make (also for gnome) to be hosted on a oss project and gnome does seem to fit it. > > For what concerns the project itself, I don't like see people > duplicating efforts; as others already told you, I really can't see the > point of rush-writing a daemon that will be, in your own words, less > functional than something which is already widely used in two big > platforms and which has a well-defined spec many people already agreed > upon. Unless you see something so fundamentally broken in the > ThumanailerSpec or in Tumbler that could only be solved with a rewrite > from scratch of everything. I also hate to see myself duplicating something that is existing out there but i learn a lot from it by doing so. > > If I were you, I would really make a step back and reconsider what other > people proposed you, be it a specialized thumbnailer for some format, or > a library with optimized thumbnailing algorithms with a demo test-drive > thumbnailer attached. If it wasn't a school project i would have done exactly that. As said a few times. I can't take a step back. the projects outline is set and must be made now. And to all. Don't get me wrong! I do still want to make this project and have been doing thumbnail benchmarks for the last few months as a "startup" for the project. I do have ideas on how to make it better, faster and "cooler" and yes much of that is in tumbler (which i didn't know a few months ago). So, it seems this is going to be a project just for school with no interesting parts for tumbler, glib or gnome in general. I would have liked it seen different but learning a lot from this project is worth a lot as well. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
Hi Mark, On Tue, 2009-10-20 at 16:34 +0200, Mark wrote: > Now can we please quit bashing the idea that there will be 2 > thumbnailing services in a few months time and can i get some > constructive feedback about the ideas in my first post? > Can i get the: > - Git > - gnome sub domain > - blog for this project on planet gnome and/or gtk gtk-devel-list is *really* not the right place for this kind of requests. Please read [1] for information about the GIT account requests, [2] for Planet GNOME and [3] for the GNOME website. Anyway, it seems to me that not having these kind of resources available right now (or even not having them at all) should not block any development of your project. For what concerns the project itself, I don't like see people duplicating efforts; as others already told you, I really can't see the point of rush-writing a daemon that will be, in your own words, less functional than something which is already widely used in two big platforms and which has a well-defined spec many people already agreed upon. Unless you see something so fundamentally broken in the ThumanailerSpec or in Tumbler that could only be solved with a rewrite from scratch of everything. If I were you, I would really make a step back and reconsider what other people proposed you, be it a specialized thumbnailer for some format, or a library with optimized thumbnailing algorithms with a demo test-drive thumbnailer attached. [1] http://live.gnome.org/NewAccounts [2] http://live.gnome.org/PlanetGnome [3] http://live.gnome.org/Sysadmin/WebSites Regards, Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Thumbnailing service project; opinions, suggestions?
[ CUT ] Sorry to keep chiming in, but regrading the statement: > you just don't seem to get the point. > I need to build something from the ground up (making uml, class > diagrams and such).. and based on that i need to make the actual > program. > Tumbler is existing already! i would be making those diagrams based on > the current inner working which is not the way to go. [CUT] I think everyone understands what you are doing, I think your the one missing the point; from what I gather, many on this very list, have given you some very good constructive advice on what to do, if you want to do this from the ground up. So be it. They are also very prudently advising you that this is not needed, and would ONLY serve as a class project, so: > Can i get the: > - Git > - gnome sub domain > - blog for this project on planet gnome and/or gtk No one is bashing anything, but despite the many who agree, that this project is NOT a requirement for GNOME or GTK (and since it is only for school, a place that rots the brain) I would be shocked... SHOCKED... if they provided you with a GIT, a gnome sub domain, and a blog. My friend, understanding is a two way street, and I'm not sure if any one on this list will convince you of any other path, than the one you are on. But don't expect them to hold your hand in this process as well. You want to do this do it: Put up your own GIT repo. Use a domain name off of your own schools website. and create your own blog for the project. I doubt any of this will effect your grade. Frankly it simply sounds like your trying to get your name on the site, which will help with other prospects. I would LOVE to be attached to such a project, many would. Open source is not about having many choices of software that do the same thing, it is about having many people working together in a cooperative (operative word here) to create something for the people, by the people, that will benefit the people, and in the process have some fun doing what we love. Open source is about freedom to do as you will, without the fear of big bro slamming you. Open source has never NEVER been about quantity, and has everything EVERYTHING to do with quality. IMHO shawn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Tue, 2009-10-20 at 16:34 +0200, Mark wrote: > >> I do miss some vital parts: > >> - Designing the daemon and plugin architecture > >> - Making those 2 > >> > >> That's what i see missing now but i probably missed a few other parts. > > What does "Making those 2" mean? [CUT] > 1. designing a daemon With a specialized thumbnailer for PDF thumbnails you'll be designing a daemon. > 2. designing a plugin architecture I don't know what that means anyway. A plugin "architecture" can mean: - Registering yourself to a DBus service, so that it knows about your existence and can delegate work to you. This is what a specialized thumbnailer is wrt Tumbler. You could see such a thumbnailer as a plugin for Tumbler (or any other thumbnail service). - Implementing an interface in Java or .NET, or implementing Event handlers in .NET, or anonymous classes in Java, or delegates in C#, that provide functionality that a core application doesn't have and that you provide dynamically by installing an assembly (or .class file, in Java) somewhere "on demand". - Making a struct with a bunch of function pointers that you return at a "get_plugin_info"-like function that you find with dlsym after you dlopen a .so file from a core application "on demand". You can also use GModule in GLib to make all this a lot more easy. - etc ... > 3. making the daemon With a specialized thumbnailer for PDF thumbnails you'll be making a daemon. > 4. making the plugin architecture Same answer as #2 > like that Yes? > > I think you are just looking for a reason to make your own one. That's > > you decision of course. It's called NIH, but anyway (I can't and wont > > stop you from doing that). > > you just don't seem to get the point. I'm quite afraid that I do get the point ... :-\ > I need to build something from the ground up (making uml, class > diagrams and such).. and based on that i need to make the actual > program. Yes, you could do that for a specialized thumbnailer for PDF thumbnails. > Tumbler is existing already! i would be making those diagrams based on > the current inner working which is not the way to go. There's no specialized thumbnailer for PDF thumbnails (for Tumbler) yet. > Oke, i know that for each project i start outside of school i don't > make a design at all or a very simple one and in that case i could > perfectly help tumbler. You can help Tumbler by making a specialized thumbnailer that makes PDF thumbnails, for example. > That, sadly, isn't the case (which i told you already on irc) Untrue, specialized thumbnailer that makes PDF thumbnails. > Just for that reason alone tumbler isn't a fine project for me to join > in this case. > Also i would like to learn as much as possible and that is less likely > to happen if i join tumbler. Eh? I disagree. But oh well. > I am not looking for reasons to make it all myself.. the requirements > simple.. require that. Untrue, I know about your requirements. I read them. And a specialized thumbnailer, that for example makes PDF thumbnails, fits it perfectly. > Now can we please quit bashing the idea that there will be 2 > thumbnailing services in a few months time and can i get some > constructive feedback about the ideas in my first post? The replies of the people who have replied so far is the constructive feedback on your first post. > Can i get the: > - Git > - gnome sub domain > - blog for this project on planet gnome and/or gtk That's not up to me. > As said a few times. the outline is right there (in the first post) > now all i can do is steer some more in one direction or the other. I > personally would like to steer in the optimizing direction... -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)
On Thu, 2009-10-15 at 14:02 -0400, Ryan Lortie wrote: > On Thu, 2009-10-15 at 12:38 -0400, David Zeuthen wrote: > > Yeah, I think we need to support this from the get-go. > > > > Anyway, at the end of the day, UNIX fds are just integers so if you > > require that users (such as GDBus itself and apps using GDBus) keep the > > fds alive until the method/signal has been sent/received you should be > > able to treat them as such. Anyway, it's probably more complicated than > > this. > > I talked to Lennart on IRC and the 'h' type, as serialised, isn't a file > descriptor so much as it is an index into a table of file descriptors > that are stored separately (in a separate part of the DBusMessage). > > Keeping this in mind, we could support this by doing the same thing with > GDBus -- support 'file descriptor array offset' as a special type of > integer in GVariant (much like 'o'bject path is a special type of > string) and have a GDBus call for send_with_file_descriptors() or such. > > Lennart mentioned that he thinks that it's a bad idea that the > dbus_message_marshal stuff was ever added to libdbus, and that the > fd-passing stuff in libdbus will break if you try to use those > functions. If we ever want to make a more efficient GVariant-to-DBus > conversion process we'll have to turn it off for the case where fd's are > present -- that's another reason for having a separate call, maybe. > > I don't think we would want to have any more 'deeply integrated' support > than that, for a lot of reasons: Lennart mentioned that this only really > works on Linux (and of course, only works if you connect to the bus > using Unix sockets). There's also the concern of what it would mean to > serialise a GVariant that contains an fd (to dconf, to the registry, to > text format, to XML, or to anything else). Yeah, the 'h' type really is for _handles_ - see the discussion on the dbus list when this was introduced (well, initially Lenny wanted 'f' - but some D-Bus implementations use that for gfloat and we didn't want to screw them). So only in Unix (mind you, not only Linux but any Unix that can pass fds - including Solaris and OS X) 'h' used for sending file descriptors but in Win32 it could probably be used for a HANDLE (e.g. the Win32 concept of file descriptors) - I actually think you can pass HANDLE to other Win32 processes. So how about something like 1. and 2. below? We'd put g_dbus_connection_get_handle_for_unix_fd() g_dbus_connection_set_handle_for_unix_fd() in the gio-unix-2.0 headers. Presumably we could add g_dbus_connection_get_handle_for_win32_handle() g_dbus_connection_set_handle_for_win32_handle() and put that in gio-win32-2.0 if such a thing was to surface. In the future we could also have g_dbus_connection_get_handle_for_iostream() g_dbus_connection_set_handle_for_iostream() that takes a GIOStream (this might not be a good idea, I don't know). For this to work, however, I'd need something like g_object_set_data_full() g_object_get_data() on the GVariant type since we'd want to clean up stuff when the passed GVariant is destroyed. It might be nice to have that on GVariant *anyway*, see http://bugzilla.gnome.org/show_bug.cgi?id=581106 for why associations are useful in general. Thanks, David --- 1. user code for sending variants: GVariant *parameters; parameters = g_variant_new ("(ih"), some_int, g_dbus_connection_get_handle_for_unix_fd (connection, variant, some_fd)); g_dbus_proxy_invoke_method (proxy, "SomeMethodTakingAnIntAndUnixFd", parameters, -1, NULL, callback, user_data); 2. user code for receiving a variant gint some_int; gint handle; gint fd; handle = g_variant_get (result_parameters, "(ih)", &some_int, &handle); fd = g_dbus_connection_get_unix_fd_for_handle (connection, handle); g_variant_unref (result_parameters); /* use fd */ close (fd); ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
>> I do miss some vital parts: >> - Designing the daemon and plugin architecture >> - Making those 2 >> >> That's what i see missing now but i probably missed a few other parts. > > > If you want to make a functional analysis of Tumbler, then go ahead. If > you want to draw cute UML diagrams with the classes and interfaces being > used, yeah sure. Sounds like useful documentation that doesn't exist atm > > What does "Making those 2" mean? You still have to make the specialized > PDF thumbnailer. You can reuse the maemo-video-thumbnailer for getting a > quick skeleton of the code. But if you prefer making an all new one in > C++ or whatever ... yeah sure. > 1. designing a daemon 2. designing a plugin architecture 3. making the daemon 4. making the plugin architecture like that > I think you are just looking for a reason to make your own one. That's > you decision of course. It's called NIH, but anyway (I can't and wont > stop you from doing that). you just don't seem to get the point. I need to build something from the ground up (making uml, class diagrams and such).. and based on that i need to make the actual program. Tumbler is existing already! i would be making those diagrams based on the current inner working which is not the way to go. Oke, i know that for each project i start outside of school i don't make a design at all or a very simple one and in that case i could perfectly help tumbler. That, sadly, isn't the case (which i told you already on irc) Just for that reason alone tumbler isn't a fine project for me to join in this case. Also i would like to learn as much as possible and that is less likely to happen if i join tumbler. I am not looking for reasons to make it all myself.. the requirements simple.. require that. Now can we please quit bashing the idea that there will be 2 thumbnailing services in a few months time and can i get some constructive feedback about the ideas in my first post? Can i get the: - Git - gnome sub domain - blog for this project on planet gnome and/or gtk As said a few times. the outline is right there (in the first post) now all i can do is steer some more in one direction or the other. I personally would like to steer in the optimizing direction... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
XInput 2.0 branch ready for review
Hi all! I think The XInput 2.0 branch is ready for initial review, there are some things missing, but at least the GDK part looks quite consistent, there are some glitches in non-pure GTK+ apps, but as far as I've tested in my jhbuild environment, it works quite well. The patch [1] is fairly big (22'5K lines) and does quite heavy modifications on pretty basic GDK internals, so I'm not sure how could we best do for merging, I've tried to keep things working along git history though. I've also updated the MPX page in l.g.o [2] with some implementation details and roadmap. There are some things left, such as DnD or modifying GtkWidgets, but I think that can be done step by step without disrupting anything. I'll keep working on the missing items in the xi2 branch anyway. So, questions? petitions? :) Cheers, Carlos [1] https://bugzilla.gnome.org/show_bug.cgi?id=596725#c1 [2] http://live.gnome.org/GTK+/MPX ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Tue, 2009-10-20 at 14:33 +0200, Mark wrote: > On Tue, Oct 20, 2009 at 1:08 PM, Philip Van Hoof wrote: > > On Mon, 2009-10-19 at 21:35 +0200, Mark wrote: > >> For Jannis and Philip, > >> Nice tumbler talk but could you two make suggestions for my project? ^_^ > > As I already wrote: > > > > A PDF thumbnailer that implements the 'specialized thumbnailer' spec > > that doesn't need to link with gdkpixbuf. [CUT] Please reply inline and cut away non-relevant things. > I do miss some vital parts: > - Designing the daemon and plugin architecture > - Making those 2 > > That's what i see missing now but i probably missed a few other parts. If you want to make a functional analysis of Tumbler, then go ahead. If you want to draw cute UML diagrams with the classes and interfaces being used, yeah sure. Sounds like useful documentation that doesn't exist atm What does "Making those 2" mean? You still have to make the specialized PDF thumbnailer. You can reuse the maemo-video-thumbnailer for getting a quick skeleton of the code. But if you prefer making an all new one in C++ or whatever ... yeah sure. I think you are just looking for a reason to make your own one. That's you decision of course. It's called NIH, but anyway (I can't and wont stop you from doing that). -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Tue, Oct 20, 2009 at 1:08 PM, Philip Van Hoof wrote: > On Mon, 2009-10-19 at 21:35 +0200, Mark wrote: > >> For Jannis and Philip, >> Nice tumbler talk but could you two make suggestions for my project? ^_^ > > As I already wrote: > > A PDF thumbnailer that implements the 'specialized thumbnailer' spec > that doesn't need to link with gdkpixbuf. > > I think that matches your project description, it fits in the architec- > ture of Tumbler (and if done right we could make this a project that > many people will use and install alongside Tumbler). > > It's much more simple than developing an entire thumbnailer, as you only > need to implement one D-Bus method called "Create". > > - You'll have to work with a queue handling the thumbnailing, as Create > isn't allowed to block, which means that GThreadQueue could for > example be used (which means that your work will involve dealing with > threads). > > - You'll need to deal with DBus .service registration > > - You'll need to code against a specification (which is in general > harder than doing your own thing - but schools like that) > > - It's a thumbnailer service and it could work standalone (which means > that it fits your requirements for school) > > - You wont have the NIH syndrome. Nobody has yet made a PDF thumbnailer > that implements the 'specialized thumbnailer' spec > > - It sounds doable within 8 weeks > > I suggest that you set up a gitorious repository, start with making a > skeleton out of the maemo-video-thumbnailer project, adapt all the files > that you read about in the specification, hollow out the methods, and > then implement them for PDF files instead of video (GStreamer). > > You can check out libpoppler for dealing with PDF files. Poppler can be > compiled not to use gdkpixbuf, but instead cairo as far as I know. > > I strongly advise to do that. > > > Anyway, it's up to you. > > Also, it wont be about free-choice unless your thumbnailer implements > the specification. Each new home-brew specification that isn't agreed by > multiple people adds API clutter to the platform. > > ps. Specialized thumbnailers spec: > > http://live.gnome.org/ThumbnailerSpec#head-83f1d6d2084e75742104681ad94c29b8d0dd2052 > > ps. Note that we might make minor changes to this spec in the following > days. Among them might be the optional Cancel() method and a parameter > to the Create() method called "scheduler" (which you can also ignore, > for now). > > > -- > Philip Van Hoof, freelance software developer > home: me at pvanhoof dot be > gnome: pvanhoof at gnome dot org > http://pvanhoof.be/blog > http://codeminded.be > > I do miss some vital parts: - Designing the daemon and plugin architecture - Making those 2 That's what i see missing now but i probably missed a few other parts. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Tue, 2009-10-20 at 13:08 +0200, Philip Van Hoof wrote: > - You'll have to work with a queue handling the thumbnailing, as > Create isn't allowed to block, which means that GThreadQueue could for > example be used (which means that your work will involve dealing with > threads). Sorry that's GThreadPool, not queue. I have too many 'queue' words in my head at the moment ;-) -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Mon, 2009-10-19 at 21:35 +0200, Mark wrote: > For Jannis and Philip, > Nice tumbler talk but could you two make suggestions for my project? ^_^ As I already wrote: A PDF thumbnailer that implements the 'specialized thumbnailer' spec that doesn't need to link with gdkpixbuf. I think that matches your project description, it fits in the architec- ture of Tumbler (and if done right we could make this a project that many people will use and install alongside Tumbler). It's much more simple than developing an entire thumbnailer, as you only need to implement one D-Bus method called "Create". - You'll have to work with a queue handling the thumbnailing, as Create isn't allowed to block, which means that GThreadQueue could for example be used (which means that your work will involve dealing with threads). - You'll need to deal with DBus .service registration - You'll need to code against a specification (which is in general harder than doing your own thing - but schools like that) - It's a thumbnailer service and it could work standalone (which means that it fits your requirements for school) - You wont have the NIH syndrome. Nobody has yet made a PDF thumbnailer that implements the 'specialized thumbnailer' spec - It sounds doable within 8 weeks I suggest that you set up a gitorious repository, start with making a skeleton out of the maemo-video-thumbnailer project, adapt all the files that you read about in the specification, hollow out the methods, and then implement them for PDF files instead of video (GStreamer). You can check out libpoppler for dealing with PDF files. Poppler can be compiled not to use gdkpixbuf, but instead cairo as far as I know. I strongly advise to do that. Anyway, it's up to you. Also, it wont be about free-choice unless your thumbnailer implements the specification. Each new home-brew specification that isn't agreed by multiple people adds API clutter to the platform. ps. Specialized thumbnailers spec: http://live.gnome.org/ThumbnailerSpec#head-83f1d6d2084e75742104681ad94c29b8d0dd2052 ps. Note that we might make minor changes to this spec in the following days. Among them might be the optional Cancel() method and a parameter to the Create() method called "scheduler" (which you can also ignore, for now). -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[REMINDER] GTK+ IRC Team meeting - 2009-10-06
hi everyone; this is a (late) reminder for the GTK+ team IRC meeting, * date: 2009-10-20 * time: 20:00 UTC [0] * channel: #gtk-devel on irc.gnome.org * agenda: - Git repository surgery [jjardon] - state of development branches for 2.20/2.90 - xi2 - resolution independence - client-side decorations - extended layout - deprecation of [H|V] variants or orientable widgets - glib branching - gobject-performance - Miscellaneous as always, everyone is invited to attend. ciao, Emmanuele. [0] http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=20&year=2009&hour=20&min=0&sec=0&p1=0 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gdk motion event changed behavior in 2.18
Il giorno Mon, 19 Oct 2009 21:24:45 +0200 Alexander Larsson ha scritto: > Your example did not work for me without the added > GDK_BUTTON_PRESS_MASK when using metacity as the window manager, I > think because metacity is a reparenting wm and has button press event > mask on the frame window, but it did work with twm (and probably > other non-reparenting wms like compiz) which doesn't do this. > > The reason it works with twm is that no other window has a button > press mask so there is no implicit grab, meaning events continue to > go to the window with the pointer. As soon as there is a parent > window in the hierarchy with the button press mask set it will stop > working. This could happen before if e.g. the widget was put in some > other widget that had the mask set. Many thanks for the detailed answer. I always thought to press and motion as totally disjoint events but effectively the grab of the button press was "logic", or at least this has little to do with gtk. As you correctly guessed I'm not using metacity but openbox and this has hidden the problem up to gtk 2.18. > I'm not sure how we can fix this in 2.18, or even if we should. I > mean, by necessity we do request button press events from X on the > toplevel (so we can emulate button presses on virtual child windows), > so we *will* get an implicit grab and can't pretend its not there (as > we get different X events now). For what it's worth, this helped me to found a fragile (hence, broken) approach to events so, in this specific case, I don't see any reason to change. Ciao. -- Nicola ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
2009/10/20 Mark > Also the ability to choose between thumbnailers isn't bad.. this is > opensource after all and that's all about freedom of choice. Something inside of me just died. Richard. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list