Regarding newer version of GTK php software
Dear Sir / Madam, I have used your GTK+ version for desktop application of PHP. Here you are using PHP version 5.1.4.Is there any provision to do serial communication in GTK+ with PHP 5.1.4? I have dll file for serial communication but it is working on PHP 5.2.0 or higher. So please help me in this matter. -- Bhagyashri Ajagare ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Regarding newer version of GTK php software
bhagyashri wrote: I have used your GTK+ version for desktop application of PHP. Here you are using PHP version 5.1.4.Is there any provision to do serial communication in GTK+ with PHP 5.1.4? I have dll file for serial communication but it is working on PHP 5.2.0 or higher. So please help me in this matter. This question does not have much to do with GTK itself, so you won't find any answers on this list. You'll have to ask this question of the PHP folks on one of the PHP lists. But if you do find information on PHP and serial communications maybe the PHP-GTK community can help you integrate them. My guess, though, is that you're unlikely to find anything useful anywhere. PHP is simply the wrong language for this kind of stuff. PHP is intended for generating HTML web pages and as such has no intrinsic low-level stuff, except what is hacked in crudely through extensions, such as your DLL. Python or Perl would be much more appropriate choices for a GTK application that needs serial port access. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk-directfb crash
Hi All, I have built gtk with target directfb. I have installed following pacakages: 1.gtk+-2.12.9 2.atk-1.13.2 3.cairo-1.6.4 4.glib-2.22.2 5.pango-1.20.2 6.pixman-0.12.0 7.DirectFB-1.2.0 I have built webkit-1.1.1 based on this gtk-directfb.Then I have bulit one browser called Midori that is based on webkit. When I am running midori , it is crashing in some of gtk call. Could any one please let me know how to solve this issue? Below is back trace for this crash (gdb) bt #0 0x00110416 in __kernel_vsyscall () #1 0x076c2660 in raise () from /lib/libc.so.6 #2 0x076c4028 in abort () from /lib/libc.so.6 #3 0x0060c093 in signal_handler () from /usr/gtkdirectfb//lib/libdirect-1.2.so.0 #4 signal handler called #5 0x00379f33 in IA__gdk_screen_get_system_colormap (screen=0x9416010) at gdkcolor-directfb.c:240 #6 0x0037c48b in IA__gdk_display_open (display_name=0x0) at gdkdisplay-directfb.c:193 #7 0x0035a4f5 in IA__gdk_display_open_default_libgtk_only () at gdk.c:288 #8 0x00769788 in post_parse_hook (context=0x93fc228, group=0x93fc040, data=0x0, error=0xbfe5e44c) at gtkmain.c:725 #9 0x002659c3 in IA__g_option_context_parse (context=0x93fc228, argc=0xbfe5e490, argv=0xbfe5e494, error=0xbfe5e44c) at goption.c:1947 #10 0x00769599 in IA__gtk_init_with_args (argc=0xbfe5e490, argv=0xbfe5e494, parameter_string=0x80a9f6f [Addresses], entries=0xbfe5e388, translation_domain=0x80a9f44 midori, error=0xbfe5e44c) at gtkmain.c:830 #11 0x0805d97b in main (argc=1, argv=0xbfe5e514) at ../midori/main.c:1662 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RFC: Adding zlib dependency to libgio
I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). We already have a dependency on zlib from gdk-pixbuf, so all Gtk+ apps already pull this in, however there could be non-gtk+ using glib apps that now get an additional dependency. Its a very small (74K .so) and very widely availible/used library though, so I don't think this is a huge deal. Anyone who thinks this is a bad idea? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On 11/08/2009 10:54 AM, Alexander Larsson wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). Hi, Will there some kind of plug-in architecture so it is possible to add say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib dependency also be made optional? Not that I see a problem with a mandatory zlib dependency. GIMP currently has bad hacks to support transparent loading of .xcf.gz and .xcf.bz2 files and it would be nice to let this be handled at a lower level. BR, Martin -- My GIMP Blog: http://www.chromecode.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Sun, 2009-11-08 at 12:01 +0100, Martin Nordholts wrote: On 11/08/2009 10:54 AM, Alexander Larsson wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). Hi, Will there some kind of plug-in architecture so it is possible to add say .bz2 and .z7 support to the GIO level? If so, couldn't the zlib dependency also be made optional? Not that I see a problem with a mandatory zlib dependency. GIMP currently has bad hacks to support transparent loading of .xcf.gz and .xcf.bz2 files and it would be nice to let this be handled at a lower level. Yelp has a custom GIOChannel for transparent loading of gzip-, bzip2-, and lzma-compressed man and info files. I'd also be very interested in a GInputStream that handles this for me. There was a thread about this in July: http://mail.gnome.org/archives/gtk-devel-list/2009-July/msg00133.html Alex, I'm not sure what your plan is, but if you're planning some sort of GFilterInputStream to do automatic decompression, I think making it zlib-only would miss the mark for what most people would want to use it for. -- Shaun ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Sun, Nov 8, 2009 at 10:54 AM, Alexander Larsson al...@redhat.com wrote: I've been working on some API for gio (more details later) that involves having an API for (de)compression. Having this as a public API makes zlib a mandatory dependency for libgio (and thus the glib tarball). We already have a dependency on zlib from gdk-pixbuf, so all Gtk+ apps already pull this in, however there could be non-gtk+ using glib apps that now get an additional dependency. Its a very small (74K .so) and very widely availible/used library though, so I don't think this is a huge deal. Anyone who thinks this is a bad idea? Well - as I already said earlier, I think GIO - in the long run - has a potential of becomming *the* free desktop API for file-management. Simply because it's design is modern, universal and reminiscent of IO APIs, which people already know from other programming languages (i.e. Java). And it's sitting very low in the stack. Such an API is hard to design and takes long to consolidate. Therefore i'm a bit worried when too many features get added to this API (like bookmarks, gdbus,...), which make it less attractive as a basic free desktop commodity. For instance Qt lacks such a VFS API, Thiago Macieira said that he would like to see a QtVFS. Qt is a very good thing to get more applications written for the free desktop, IMHO GIO/GVFS developers should see it as one of their potential customers. Qt can already link GLib for the main-loop, provide Gtk+ filechoosers, thus moving forward to full VFS support seems natural. Perhaps QtVFS could be thin bindings for GIO, designing another VFS API from grounds up doesn't sound like a good idea, and i guess GIO is portable to the same OSs like Qt. But i don't know whether there are main-loop issues on Non-Unixes. KDE can also use GIO with my KIO-GioBridge ioslave. Not very popular though :-( I can't really comment on this (de)compression API, sounds like a good feature. But wouldn't it be sufficient to include some zlib compression/decompression code in libgio.so itself? I also put Thiago Macieira on CC. Regards, Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Sun, 2009-11-08 at 21:24 +0100, nf2 wrote: Qt can already link GLib for the main-loop, provide Gtk+ filechoosers, thus moving forward to full VFS support seems natural. Perhaps QtVFS could be thin bindings for GIO, designing another VFS API from grounds up doesn't sound like a good idea, and i guess GIO is portable to the same OSs like Qt. My understanding was that they will link to GLib, but not to GObject. And since GIO depends upon GObject, what you're suggesting doesn't sound very likely to happen. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
