Generating key press event using gtk button
Dear all: I am trying to write a virtual keyboard like application that can generate keyboard key press event on click of a button. How do I make a button click generate a key press event ? An example of such program is xvkbd (http://homepage3.nifty.com/tsato/xvkbd/ ). Regards, Sulabh Bista ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Generating key press event using gtk button
I haven't done any signal emission of my own, but you probably want to look at putting g_signal_emit_by_namehttp://library.gnome.org/devel/gobject/unstable/gobject-Signals.html#g-signal-emit-by-name or one of its companions into your button click callback. Hopefully this will get you off in the right direction or someone more informed will respond soon with more info. Eric Squires On Fri, Aug 14, 2009 at 11:26 AM, Sulabh Bista sul...@gmail.com wrote: Dear all: I am trying to write a virtual keyboard like application that can generate keyboard key press event on click of a button. How do I make a button click generate a key press event ? An example of such program is xvkbd ( http://homepage3.nifty.com/tsato/xvkbd/ ). Regards, Sulabh Bista ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtkAssistant
Trying to use GtkAssistant.set_page_complete(), but keep getting an error: TypeError: GtkAssistant.set_page_complete() argument 1 must be gtk.Widget, not int The documentation says the first argument should be a page of the assistant, which I assumed to be a number. What should I be putting in there? -- Sam Bull s...@sambull.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK application hangs in Windows and Wine, works fine in Linux
Hi, I've been trying to fix this myself but I had no luck so far, so I'm asking here, I hope it's the right place to ask. So here is my problem: I developped a GTK application for converting encodings, it's open source and the URL is here if you want to see the source code perhaps : http://houbysoft.com/cc/ The problem with it is that it works completely fine on Linux, but if I build it in Dev-C++ and try to run on Windows, just a blank window appears, and it hangs, leaving me the sole option to force quit it. I also tried running it in wine, gives this error: err:ntdll:RtlpWaitForCriticalSection section 0x13b670 ? wait timed out in thread 003f, blocked by , retrying (60 sec) Also let me say that I wrote also other GTK applications so it's not a problem with the compiler settings, etc., other GTK apps I wrote ran fine so far in both OSes, with the same compilation procedure. Thanks for your precious help! Jan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Notes and thoughts on the GTK+ meeting at GUADEC
Hi All, First my apologies for being so late writing you this e-mail. I had some very high priority tasks related to my studies to take care of first. At GUADEC early July this year (roughly a month ago), we did not schedule for a GTK+ meeting in person like we did in the preceding years. When talking with Vincent at one of the parties, we figured that it would be a pretty good idea to actually get some people together and talk about GTK+ 3, since GNOME really wants to move forward with the platform clean-up in GNOME 3.0. In this e-mail, I will briefly outline what was discussed in this meeting, as well as pour in a couple of ideas from me personally. I have not really taken notes like I normally do and we also did not have an agenda for this meeting, so I am not able to provide the structural and factual form that you might be used to. Even though this summary is influenced by my own ideas, I hope it will serve as a good basis for further discussions. We ought to have a release of a GTK+ 2.90 in parallel with GTK+ 2.18, in time for GNOME 2.28. This means a release before the end of September. The work to complete the sealing of the API is far, but not fully complete. Several people have tried to bring this to completeness, in particular Cody Russell. Due to lack of feedback (I am to blame here as well), this work could not be fully finished yet. What is left to do here (basically acquired from re-evaluating [1]): - A couple of files are still pending sealing. Bugs have been filed for most of these, see http://live.gnome.org/GTK%2B/3.0/PendingSealings. - Implement class private data, bug 521707 has been filed for this and contains a patch. I will give this a review and if the patch seems right get Tim to review it as well. - Deprecate public class data using GSEAL. I think there has actually been a discussion on whether this is necessary and whether we should keep slots in classes. I hope Mitch can fill me in on this. - Introduce GObject convenience accessors. Bug 541569 has a patch that is partly reviewed. I will review this as well. - Deprecate widget flags and introduce proper API as replacements. See also bug 69872. Mitch has been working on this recently. Mitch, could you give a status update here? - Seal GtkStyle. This really has to be done together with investigating the plans for theming, see below. - Investigate whether there is stuff to seal in GDK, GLib. I think for now there won't be a GLib 3 (but please correct me if I am wrong), so I would say to leave out GLib for now. GDK certainly has to be done. I can look into this and write up a proposal later on. - Make up our minds whether or not to deprecate non-multihead-safe function calls (bug 547920). People are pretty divided on this, I don't have a strong opinion on this yet. The wiki page also lists investigating a diagnostic mode that I think we can skip for now. Investigations for using -Bsymbolic and using attribute-based deprecation might still be useful to do, but can happen after the sealing is done. When done, we can move on with the 2.9 development branch tasks as listed on [1]. These tasks should be pretty straightforward. So, what should happen next? For the current plan, we need to sit down and determine a feature set for GTK+ 3.0. There are a lot of ideas on features and a draft roadmap has been posted earlier this year[2]. The roadmap is fairly large and we have not really received many comments on this. Some people at GUADEC told me this is because everybody agrees. I think one of the other problems is that the items are not very elaborate. Furthermore, we should at least check if we have gotten the priorities right in the draft roadmap and see if we are missing something obvious. I doubt that much will come from this roadmap in its current form. During the meeting it has also been mentioned that when we put out a GTK+ 3.0 and start working on features (for example in the incremental manner as was described in the original ideas[3]) and we notice that an ABI break is needed then we won't be able to get such features in until GTK+ 4.0. It is not clear to me personally if a GTK+ 4 (with an accompanying ABI break) will happen at all in the near future, but even if it happens at least this means a wait of 3 to 4 years. When this is the case for new features such as theming system improvements, etc, I agree that another 3 to 4 year wait is unacceptable. A different way to start working on the new features is to decide on a feature set first, research the features and (if required) make required changes *before* an ABI frozen GTK+ 3.0 is put out. This brings up the next question: what features to research first? For this, I think we need to talk with our prime users: GNOME, GIMP, Mono/MonoDevelop, XFCE, etc, etc (this list is of course fully up for discussion). Make them aware of the existence of the roadmap and ask them what features are most important to them and which they feel
Re: Notes and thoughts on the GTK+ meeting at GUADEC
2009/8/14 Kristian Rietveld k...@gtk.org: Hi All, A different way to start working on the new features is to decide on a feature set first, research the features and (if required) make required changes *before* an ABI frozen GTK+ 3.0 is put out. This brings up the next question: what features to research first? For this, I think we need to talk with our prime users: GNOME, GIMP, Mono/MonoDevelop, XFCE, etc, etc (this list is of course fully up for discussion). Make them aware of the existence of the roadmap and ask them what features are most important to them and which they feel are missing. Talk with the most active people involved in theming and art (there really is much going on in there right now) to come to consensus on a feature set with regards to theming; this is important because it will tell us what GtkStyle should be migrated to. Also look at outstanding patches adding new features in Bugzilla. This is an information gathering phase that can be turned into a GtkTask[4]. If people agree with this approach, we can turn this into a more formal and clear description of the work. First things first, thanks a lot Kris for taking the bullet and kickstarting this discussion, congrats for finishing college and I'm really excited to have you back ;-) As for theming, I've been discussing a bit with Thomas, Carlos and Cody. We have reached some sort of consensus that a backwards compatible path is possible adding a second vtable for engines, checking the vtable size and working out a structured way to poke the scene graph representation. However, we need time to try these things out. Thomas pointed out that working on a separate theming library makes a lot of sense as it would allow reaching a nice API and it would help the special purpose GObject baed toolkits around to have proper theming as well (say Nbtk, Glitter...). So I think that we've reached the conclusion that theming shouldn't get in the way of the current 3.0 plans, as we don't have time to deprecate GtkStyle and introduce something new all at once (eventhough, we all would have loved to make it). There's the issue of CSS though. Would it be acceptable to deprecate gtkrc's in the middle of the 3.0 cycle in favor of CSS theming files? This is an area where I'm pretty much blind, prolly Robert Staudinger has a better picture than me here, Robert? Now, what I'd love to see is having IRC meetings back, ebassi and myself talked roughly about it on IRC, seems that mclasen has a toughest schedule these days. Anyone up to figure out hours/date to have a 3.0 kickstart meeting and do some rock and roll? As I said, thanks a lot for the heads up Kris! -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Quartz DnD patch review approval sought
2009/8/12 Kristian Rietveld k...@gtk.org: Hi Paul and John, On Tue, Aug 11, 2009 at 7:17 PM, John Rallsjra...@ceridwen.us wrote: http://bugzilla.gnome.org/show_bug.cgi?id=588449 I'd appreciate some more review and possible approval of this patch. It would remove the last substantive item in the patch that is necessary to get Ardour to run on GTK/Quartz, and would presumably help other applications similarly. And while whoever is at it, could he also look through the other GTK+ Mac tickets and close the ones that are clearly obsolete (like the two can't compile bugs from 2.13)? I recently got a recent version of GTK+ building again on my Mac. I am still on Tiger and it needs some more fixes before it cleanly builds GTK+ again, I intend to look into this soon. When that is done, I will certainly try to find time to go through the pending Mac bugs and see what I can do. Please understand that I currently am no where near as experienced hacking on the Mac port as Richard is. Also I've got a good bunch of other stuff on my plate as well, so I cannot promise time frames/deadlines at this point ... I recently bought a Leopard license to start playing out again, once I have broadband at home I'll setup a full jhbuild environment there so expect a little help from my side eventually, although I've been only playing with theming bits so far, nothing in the backend. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Un saludo, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
patches to make gtk head build on win32 with MSVC
Hi, all I spent a day on building gtk head on win32 by utilizing OAH (https://launchpad.net/oah) and came up with these small patches. I'm not sure if I should file a bug report first and then attach patches there, since they are so small and trivial. The 6th and 7th are not required, since gdk doesn't build with GDK_DISABLE_DEPRECTED, but I think they help cleanups anyway. I'm not quite sure about the 5th one, but it doesn't link if _gdk_drawable_imp_win32_get_type, since all GDK_WINDOW_HWND in gtk/gtksocket-win32.c and others need it. Best Regards Shixin Zeng 0008-C89-style-fix.patch Description: Binary data 0001-C89-style-fix.patch Description: Binary data 0002-dereference-the-pointer-after-it-s-successfully-init.patch Description: Binary data 0003-return-1-on-failure-to-make-it-build.patch Description: Binary data 0004-include-gdk-gdkinternals.h.patch Description: Binary data 0005-export-_gdk_drawable_impl_win32_get_type-for-gtkplug.patch Description: Binary data 0006-replace-specialized-gdk_-_unref-with-g_object_unref-.patch Description: Binary data 0007-protect-_GdkFontPrivateWin32-by-GDK_DISABLE_DEPRECAT.patch Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GZip{In,Out}putStream in GIO?
2009/7/31 Brian J. Tarriconebj...@cornell.edu:
On 07/31/2009 05:48 AM, Mikkel Kamstrup Erlandsen wrote:
From the looks of it, it should be straight forward to write
GZip{In,Out}putStream classes based on zlib
I'd say call it GCompressed{In,Out}putStream and have it either auto-detect
the compression type, or have a param in the API to specify from an enum
(or
both). People can add support for other types of compression as time goes
on.
It's nice to see I'm not the only person that's after this.
I'm not sure what other people need this for, but I thought
I'd give a data point for why it's useful to me.
Yelp currently has its own subclass of GIOChannel that does
decompression on the fly for gzip, bzip2, and lzma.
http://git.gnome.org/cgit/yelp/tree/src/yelp-io-channel.c
It's not a particularly elegant solution. It has everything
in one file, with bzip2 and lzma functionality in #ifdefs,
and determines what to do by file extension. But it does the
job for Yelp, which needs to read man and info pages that may
be compressed.
(It's also a fairly trivial and not-complete implementation.
For instance, it doesn't do seeking, because Yelp doesn't
need it.)
I've been looking at converting Yelp over to GIO, so having
such an InputStream would be very useful to me. If it's not
in GLib, I'll have to do my own.
I'd really need all three of the above compression schemes to
work. If a gzip-only InputStream is done, I can always ship
my own bzip2 and lzma implementations.
A flexible system using runtime-loadable backends is fine for me,
as long as I know bzip2 and lzma implementations are available.
I don't particularly care about having a guarantee that they're
there. Distributions that ship lzma-compressed man pages can
just make sure the backend is installed. Not my problem.
And yes, this is me volunteering to do the work, but not until
I get around to gutting Yelp, which will be in maybe two months.
I'll have to do the work anyway for Yelp. It would be nice to
get input from the maintainers about what approach they think
is best.
--
Shaun
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with GBufferedOutputStream
On Fri, 2009-08-14 at 20:49 +0200, Sebastian Pölsterl wrote: I came across a problem with GBufferedOutputStream and g_output_stream_write recently. If I try to write more data than the buffer size, not everything is written to the file. From the documentation of g_output_stream_write: On success, the number of bytes written to the stream is returned. It is not an error if this is not the same as the requested size, as it can happen e.g. on a partial i/o error, or if there is not enough storage in the stream. All writes either block until at least one byte is written, so zero is never returned (unless count is zero). Use g_output_stream_write_all if you want to make sure that all bytes are written (as long as there is no error). Cheers, Jürg ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with GBufferedOutputStream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jürg Billeter schrieb: On Fri, 2009-08-14 at 20:49 +0200, Sebastian Pölsterl wrote: I came across a problem with GBufferedOutputStream and g_output_stream_write recently. If I try to write more data than the buffer size, not everything is written to the file. From the documentation of g_output_stream_write: On success, the number of bytes written to the stream is returned. It is not an error if this is not the same as the requested size, as it can happen e.g. on a partial i/o error, or if there is not enough storage in the stream. All writes either block until at least one byte is written, so zero is never returned (unless count is zero). I read the documentation, too. But non of the issues mentioned is applicable here. If the behavior is intended I'd have absolutely no idea why one would need such a function. - -- Greetings, Sebastian Pölsterl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqF5OcACgkQ1ygZeJ3lLIcJBQCfQZ9KrzygPcHHq3l4qlYYwSTH qHQAnA0EEIZsxIbuTkf/piS5rNz4TmxL =+UAm -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
