all I need some window to host webkit or/and cairo drwaing, but i have to deal with all that first to understand what I'm doing.
now. I'm lost and no more understand what's all that about.
and things get worse when I try working with binding or trying to figure what are dependencies for something.
for example: in python, pyGtk deprecated and replaced by pyGObject(sometimes called pyGl!!)
there are many sites, many downloads and versions, mixed outdated and new references,but not one architectural view of the whole thing.
what I don't understand..is how all these things mixed with each other in too many sites,packages and versions?
The short story:
If you're programming for GTK 2, use pyGTK.
If you're programming for GTK 3, use pyGObject.
The long story:
From what I understood, pyGTK was based on pyGObject. GObject is the "object" API of GTK. GTK is developped in C, which is not an object-oriented language. GObject is a library that provides advanced object-oriented facilies. All GTK objects inherit from the GObject class provided by that library.
Then came the GObject-introspection work. Its goal was to make bindings maintenance easier, and use source code annotations to automatically generate most of the bindings code for each language (python, C++, etc.). This resulted in the python side in pyGI, the python bindings based on the GObject introspection work. That's when people were told to use it for GTK3 development.
Since then, the GObject-introspection work once provided by pyGI has been integrated into GObject. pyGObject eventually became what developers should use for python development in GTK3.
Please read:
https://wiki.gnome.org/Projects/PyGObject
About the GNOME/GTK relationship:
GTK is the toolkit used by the GNOME project. It has been extracted from the GIMP, hence its name (GTK stands for: GIMP Tool Kit). GTK is a core part of the GNOME project, and GTK developers often also are involved in the GNOME project.
My understanding of those components you mentioned:
Think of GI as an interface that the core GNOME libraries conform to.
PyGI doesn't exist any more; it's now part of PyGObject in the GNOME 3 setup.
What is the relation between GTK, GTK+ and GTK2?
Related
New to Gtk. I tried to compile a GtkSocket example in c, but it gives error unknow type name 'GtkSocket'.
Is it supported in Windows OS?
If not, is there any way I can embed gvim in a gtk+3 applicaton?
Also is there any link where can I know which Gtk feature is supported on which OS?
Thanks
From reference manual:
The GtkPlug and GtkSocket widgets are now X11-specific, and you have
to include the gtk/gtkx.h header to use them.
Afaik, there is no list of features supported by which backend/os. For APIs difference, GtkSocket is pretty much the biggest difference. But there are several backend specific APIs, usually with a different namespace, such as x11/win32.. This is quite common with portable libraries.
I don't know a proper way to embed an application on win32. There are other stackoverflow questions about this, since this is not gtk specific. For example QT How to embed an application into QT widget that you could adapt to Gtk+ application.
I'd like to write some interactive GUIs in Perl. I've used TclTk but it looks dated. I've written QT code for C++, but the PerlTk module hasn't had a release in several years. Googling around I see other possible options.
What are good packages for this, including basic windowing, menus, drawing canvas, scrollbars, and so on.
Gtk2 has glade2 which can write out an XML file usable by Gtk2::GladeXML. Here is an example of how to bundle the XML with the app in the same file.
I misread the question at first. I thought you wanted a GUI editor for making GUIs (which is what glade2 is). You can also create GUIs using Gtk2 without glade2:
#!/usr/bin/perl
use strict;
use warnings;
use Gtk2;
Gtk2->init;
my $window = Gtk2::Window->new;
my $vbox = Gtk2::VBox->new;
my $label = Gtk2::Label->new("Hello World");
my $button = Gtk2::Button->new("Press me");
$window->add($vbox);
$vbox->add($label);
$vbox->add($button);
$window->set_default_size(200, 200);
$window->signal_connect(
destroy => sub {
Gtk2->main_quit;
}
);
my $i = 0;
$button->signal_connect(
clicked => sub {
$label->set_text("button pressed " . ++$i . " times");
}
);
$window->show_all;
Gtk2->main;
Try wxPerl!
From the web site:
wxPerl is an extension module allowing
the creation of GUI (Graphical User
Interface) from Perl; it is built as a
wrapper for the awesome wxWidgets C++
GUI toolkit.
Echoing Chas Owens, glade is quite usable with Gtk2 in Perl. In addition, Gtk2 also supports GtkBuilder files (which you can create the latest glade too).
The main problem with wxPerl (and wxWidgets itself) is that it doesn't let you install file event watchers into its main loop (it only has GUI, Socket and Timer events), unlike Tk and Gtk.
The Qt, Tk and Gtk2 event loops can be used in Perl with AnyEvent, and Gtk2 can be hooked into applications running the Event or Ev mainloop with Glib::Event and Glib::EV modules.
A GUI builder for WxPerl would be wxGlade or wxFormBuilder, both open-source.
I would probably use Gtk2, but Tk is definitely not dead. The lack of releases is due to the bugs being ironed out over the years. A lot of people still use it, and it generally works fine. (Tk's event loop is somewhat silly, but that is a detail that probably shouldn't concern you.) The only disadvantage is that your GUI looks like it is from 1996, but who cares?
(The gitk tool included with git showed that Tk GUIs look fine as long as they're useful.)
Recently I was made aware of another GUI toolkit for Perl called Prima. Its claim to fame is that it was written in C especially for Perl, not a port from TCL or bindings to something else. Assuming you have some rather standard libraries on your system, it will install directly from CPAN and its cross-platform!
David Mertens has been writing a new plotting library for PDL using it, and a REPL too!
Regarding quality of widgets, all three gtk2, wx and qt4 are equally good -- gtk2 is fastest, qt4 has best resolution, whereas wx is somewhere between the two in terms of both the parameters.
But tk is behind all the three both in terms of speed and resolution, but remains firstly because it is the original widget for all unix based interpreted languages, and secondly because it is native-widget of freebsd.
As on today in case of perl, documentation of perl-gtk2 is slightly more developed than both perl-qt4 which is in turn is more developed than wxperl. In fact, if you browse the web, you will find that tutorials for perl-gtk2 is more extensively available than even pygtk (which is also very well established) and ruby-gtk2. In case of python, wxpython documentation leads over PyQt and pygtk, whereas in case of ruby, ruby-qt4 leads over ruby-gtk2 and wxruby. However, others are developing very fast (e.g. ruby-gtk2) and after some time all nine will be equal in all aspects.
The perl-qt4 specific problem is: In case of non-kde desktops, perl-qt4 may not run. I tried running all in ubuntu and sabayon and found that perl-gtk2 and even wxperl (and wxruby also) runs fine whereas I'm not able to run even a single perl-qt4 programs in gnome-desktop where I have installed complete qt4 support without kde.
perl-qt4 asks for installation of not just qt4-libraries, but also kde-desktop libraries. This problem is uniquely perl-qt4-specific, does not exist in case of PyQt and rubyqt4 since they both run fine with qt4 runtime under gnome.
Hence, in this way eight (plus three tk) out of nine options did well (I havent tested PySide yet).
In case of perl-tk, widget is well developed and established and unlike tkinter, pmw and rubytk, its documentation is the best among all of these mentioned above.
But maybe after some time all the documentations become developed and any would become equally good.
After taking a balance between speed, clarity and cross-platform into consideration choose either perl-gtk2, or perl-qt4 or wxperl.
perl-tk, perl-gtk2 and perl-qt4 syntaxes nicely go well with perl programming language syntax, whereas wxperl syntax look more like proper c++ blended into perl which is different from the respective language syntax (just like in case of wxpython and wxruby).
But if you are already keeping in mind that wx code is uniquely different then you can straightaway begin with wxperl.
Otherwise, best way out is: begin with perl-tk, then switch over to perl-gtk2 then perl-qt4 or wxperl alike but make sure that you learn all four instead of only one (the same sequence should also apply to python and ruby too despite the fact that documentation support is reverse, but in case of perl even for this aspect it is same).
I don't have a real answer for you, but often you have to consider your deployment targets. Some of the GUI libraries are very nice, but only if you can get them to work on your operating system. I don't necessarily think that all frameworks need to be cross-platform compatible, a very laudable goal to work toward in a perfect world, as long as the one you choose doesn't lock out a significant portion of your users because the foundation GUIs libraries are hard to install or support on a particular platform.
I just want to let everyone know PerlQt is great and this site has a lot of tutorials on how to use it and lots of examples to download.
PerlQt Wiki tutorial
PerlQt is a very fast and easy way to create great looking GUI programs using the Qt drag and drop form designer and Perl. PerlQt is powerful enough for advanced developers and easy for beginners as well.
The solution I'm going with is Gtk-Perl. At first I had difficulty installing it, but in the end I found Camelbox Perl+Gtk2 in one package.
I have used Tk, but in the last few days I have been playing around with Continuity (CPAN entry), a stateful (persistent state per user) web application/server, and it could easily be a way to add "GUI" features into an application, while making it multi-user and portable at the same time.
Edit: At the time I wrote this, I was most interested in the fact that Continuity had its own built-in webserver. This is now true of other webframeworks for Perl as well. I have been using Mojolicious though I hear good things about Dancer too.
I'm confused by the GTK terminology. According to Wikipedia, there seem to be bindings to GTK+ that are called GTK (GtkAda) and GTK2 (gtk2hs, Gtk2-Perl).
Could someone clear this up for me?
The first incarnation of the project was called GTK (which stood for GIMP Toolkit).
At some very early point, while the project was still part of The GIMP (and before version 1.0), it was renamed to GTK+. Despite this, people often referred to it as GTK out of convenience or ignorance.
The GTK+ name was used for more than 20 years through versions 1.x, 2.x, and 3.x, but the "GIMP Toolkit" expansion was dropped. I don't know when exactly this happened but perhaps during the 1.x → 2.x transition.
There is nothing officially called GTK2. It's just what some people call the 2.x series of GTK+.
On 2019-02-06, the project was renamed back to GTK, which will affect version 4.0 onwards.
GTK/GTK+ and GTK2 are different versions of the same API. GTK is an old, deprecated version, GTK2 is the previous one, GTK+ 3/GTK3 is the current version.
GTK+ is the correct name of the old API, but most people just call it GTK.
The C++ bindings for GTK+ are part of the project GTKmm.
GTK is the library for creating GUI-s for Linux / GNU. It has several versions (I think the latest is version 3).
In order for other programming languages to use it (other than C), there have to exist libraries that can bind GTK to that particular language.
PHP-GTK means that there's a library binding GTK to PHP enabling PHP to create apps that can be displayed in a nice interface. It supports, however, only up to version 2.2 of the GTK.
Same goes for other languages, they have a prefix / suffix and (GtkAda for example) those libraries also tell you up to what version they support GTK (since you might want to try newer GTK functions that aren't available in the library binding GTK to your language).
Glade helped me get started on a project quickly, but I've found it harder to maintain in the long run, and I'm thinking about switching it all to native code. In what circumstances would you choose glade, and when would you use native code?
I would personally only use native code for performance reasons. I find it much easier to work with gtkbuilder. Have you used glade or gtkbuilder? With Glade 3, gtkbuilder format is easy to use and easy to layout and design. Also, gtkbuilder is easier to load widgets from than glade was.
if by native code you mean "direct GTK calls to build ui", then i'd switch to it for several reasons:
if widgets are built dynamically depending on user preferences, etc
if i use a lot of custom widgets, esp. contained within each other (for example GDL docking panels)
to maintain backwards compatibility with older version of GTK
upd: also i'm still using glade2.x which has code generation (patched it to compile against latest gtk2). it really helps to get quickstart on "gui build from code", and works with both ancient and newer GTK versions. though i'm afraid i will have some troubles porting to gtk3 :)
and i never choose gtkbuilder over other alternatives, 'cause it is not available in (still widespread) older GTK versions.. dunno if i'll ever switch to it.. maybe when gtk3 comes out.
I'd like to write some interactive GUIs in Perl. I've used TclTk but it looks dated. I've written QT code for C++, but the PerlTk module hasn't had a release in several years. Googling around I see other possible options.
What are good packages for this, including basic windowing, menus, drawing canvas, scrollbars, and so on.
Gtk2 has glade2 which can write out an XML file usable by Gtk2::GladeXML. Here is an example of how to bundle the XML with the app in the same file.
I misread the question at first. I thought you wanted a GUI editor for making GUIs (which is what glade2 is). You can also create GUIs using Gtk2 without glade2:
#!/usr/bin/perl
use strict;
use warnings;
use Gtk2;
Gtk2->init;
my $window = Gtk2::Window->new;
my $vbox = Gtk2::VBox->new;
my $label = Gtk2::Label->new("Hello World");
my $button = Gtk2::Button->new("Press me");
$window->add($vbox);
$vbox->add($label);
$vbox->add($button);
$window->set_default_size(200, 200);
$window->signal_connect(
destroy => sub {
Gtk2->main_quit;
}
);
my $i = 0;
$button->signal_connect(
clicked => sub {
$label->set_text("button pressed " . ++$i . " times");
}
);
$window->show_all;
Gtk2->main;
Try wxPerl!
From the web site:
wxPerl is an extension module allowing
the creation of GUI (Graphical User
Interface) from Perl; it is built as a
wrapper for the awesome wxWidgets C++
GUI toolkit.
Echoing Chas Owens, glade is quite usable with Gtk2 in Perl. In addition, Gtk2 also supports GtkBuilder files (which you can create the latest glade too).
The main problem with wxPerl (and wxWidgets itself) is that it doesn't let you install file event watchers into its main loop (it only has GUI, Socket and Timer events), unlike Tk and Gtk.
The Qt, Tk and Gtk2 event loops can be used in Perl with AnyEvent, and Gtk2 can be hooked into applications running the Event or Ev mainloop with Glib::Event and Glib::EV modules.
A GUI builder for WxPerl would be wxGlade or wxFormBuilder, both open-source.
I would probably use Gtk2, but Tk is definitely not dead. The lack of releases is due to the bugs being ironed out over the years. A lot of people still use it, and it generally works fine. (Tk's event loop is somewhat silly, but that is a detail that probably shouldn't concern you.) The only disadvantage is that your GUI looks like it is from 1996, but who cares?
(The gitk tool included with git showed that Tk GUIs look fine as long as they're useful.)
Recently I was made aware of another GUI toolkit for Perl called Prima. Its claim to fame is that it was written in C especially for Perl, not a port from TCL or bindings to something else. Assuming you have some rather standard libraries on your system, it will install directly from CPAN and its cross-platform!
David Mertens has been writing a new plotting library for PDL using it, and a REPL too!
Regarding quality of widgets, all three gtk2, wx and qt4 are equally good -- gtk2 is fastest, qt4 has best resolution, whereas wx is somewhere between the two in terms of both the parameters.
But tk is behind all the three both in terms of speed and resolution, but remains firstly because it is the original widget for all unix based interpreted languages, and secondly because it is native-widget of freebsd.
As on today in case of perl, documentation of perl-gtk2 is slightly more developed than both perl-qt4 which is in turn is more developed than wxperl. In fact, if you browse the web, you will find that tutorials for perl-gtk2 is more extensively available than even pygtk (which is also very well established) and ruby-gtk2. In case of python, wxpython documentation leads over PyQt and pygtk, whereas in case of ruby, ruby-qt4 leads over ruby-gtk2 and wxruby. However, others are developing very fast (e.g. ruby-gtk2) and after some time all nine will be equal in all aspects.
The perl-qt4 specific problem is: In case of non-kde desktops, perl-qt4 may not run. I tried running all in ubuntu and sabayon and found that perl-gtk2 and even wxperl (and wxruby also) runs fine whereas I'm not able to run even a single perl-qt4 programs in gnome-desktop where I have installed complete qt4 support without kde.
perl-qt4 asks for installation of not just qt4-libraries, but also kde-desktop libraries. This problem is uniquely perl-qt4-specific, does not exist in case of PyQt and rubyqt4 since they both run fine with qt4 runtime under gnome.
Hence, in this way eight (plus three tk) out of nine options did well (I havent tested PySide yet).
In case of perl-tk, widget is well developed and established and unlike tkinter, pmw and rubytk, its documentation is the best among all of these mentioned above.
But maybe after some time all the documentations become developed and any would become equally good.
After taking a balance between speed, clarity and cross-platform into consideration choose either perl-gtk2, or perl-qt4 or wxperl.
perl-tk, perl-gtk2 and perl-qt4 syntaxes nicely go well with perl programming language syntax, whereas wxperl syntax look more like proper c++ blended into perl which is different from the respective language syntax (just like in case of wxpython and wxruby).
But if you are already keeping in mind that wx code is uniquely different then you can straightaway begin with wxperl.
Otherwise, best way out is: begin with perl-tk, then switch over to perl-gtk2 then perl-qt4 or wxperl alike but make sure that you learn all four instead of only one (the same sequence should also apply to python and ruby too despite the fact that documentation support is reverse, but in case of perl even for this aspect it is same).
I don't have a real answer for you, but often you have to consider your deployment targets. Some of the GUI libraries are very nice, but only if you can get them to work on your operating system. I don't necessarily think that all frameworks need to be cross-platform compatible, a very laudable goal to work toward in a perfect world, as long as the one you choose doesn't lock out a significant portion of your users because the foundation GUIs libraries are hard to install or support on a particular platform.
I just want to let everyone know PerlQt is great and this site has a lot of tutorials on how to use it and lots of examples to download.
PerlQt Wiki tutorial
PerlQt is a very fast and easy way to create great looking GUI programs using the Qt drag and drop form designer and Perl. PerlQt is powerful enough for advanced developers and easy for beginners as well.
The solution I'm going with is Gtk-Perl. At first I had difficulty installing it, but in the end I found Camelbox Perl+Gtk2 in one package.
I have used Tk, but in the last few days I have been playing around with Continuity (CPAN entry), a stateful (persistent state per user) web application/server, and it could easily be a way to add "GUI" features into an application, while making it multi-user and portable at the same time.
Edit: At the time I wrote this, I was most interested in the fact that Continuity had its own built-in webserver. This is now true of other webframeworks for Perl as well. I have been using Mojolicious though I hear good things about Dancer too.