Re: Where do I find the constants?

[Terence Ferraro <terencejferraro gmail com>]

my $store = Gtk3::ListStore->new(qw/Glib::String/);

$store->insert_with_values(0,0,'Testing');

my $combo = Gtk3::ComboBox->new_with_model_and_entry($store);
$combo->set_entry_text_column(0);

The above should work. Other than a few quirks I had to work out a few months ago going from Gtk2 to Gtk3 (which can be found in the list archives), I've been quite pleased with the perl interface for Gtk3.

The only unresolved issue I have left is figuring out a way to 'require' Gtk3 instead of 'use' (as 'use' then unnecessarily loads all of the Gtk3 libraries into my other threads which do not touch the gui). Funny enough, it seems this is an issue because of how closely it follows the C implementation. :)

Terence J. Ferraro

On Fri, Jan 3, 2014 at 3:19 AM, Christian Jaeger <chrjae gmail com> wrote:

TL,DR: feeling disappointed enough about having repeatedly been stuck trying to use perl-Gtk3 now that I'm pondering alternatives (straight C, Scheme&embedded C, Python). Could perl-Gtk3 follow libgtk3 more closely (simpler/more stupidly/with less abstraction) to solve my gripes?

Long version:

2013/12/31 Torsten Schönfeld <torsten schoenfeld gmx de>

At least as of perl-Gtk3 0.009, the run() method should return strings
for the predefined response types, i.e. those with negative integer
values.

That leaves me wondering whether my script stops working when perl-Gtk3 is upgraded.

I understand that the version number "0.006" that I'm using is very far from "1" and doesn't exactly suggest to offer a stable interface. But then 0.009 suggests the same, ergo, I couldn't use perl-Gtk3 at all currently (even though everyone so far recommended that I write new apps using Gtk version 3 not 2; perhaps I'd have to write directly in C instead).

So, I guess you could say that you're free to change the API since this is not a stable version yet. But it still leaves me also wondering why you try to move away from the C api at all; perhaps it would make things more comfortable, but it also makes understanding things more difficult. I don't think I like this, considering that there's no perl-Gtk3 docs/tutorial etc. and that I might want to write future programs in other languages than Perl and still profit from what I learned about Gtk3. I also think that to get a really nice API to create GUI apps, I'll have to write higher level abstractions anyway; I won't write code like this every time I want a combobox:

    {

my $cb= get "videodev_combobox";

my $list= new Gtk3::ListStore ("Glib::String");

my $seen_cur;

for (@videodevs) {

   $seen_cur=1 if $$config{videodev} eq $_;

   $list->append([$_]); # actually not working, I haven't figured it out yet

}

# add editable entry if necessary

unless ($seen_cur) {

   $list->append([$$config{videodev}]);

}

$cb->set_model($list);

        # ...not even finished...

    }

Instead I want something similar to:

    my $cb = get "videodev_combobox";

    $cb->set_items(@videodevs);

and I *don't* really want this kind of abstraction in the Gtk3 layer; I want this on a higher layer, that I could use to target other toolkits than Gtk3 in the future. (I know there's WxWidgets which sounds like it might fit that aim but I suspect that I will be better off writing the subset of GUI functionality that I need in my apps as a higher level myself, as it will allow me to tailer my apps more closely to native toolkits and will allow me to target toolkits other than those supported by WxWidgets.)

So, for me it's preferable when perl-Gtk3 stays very close to the C api. Keep it simple and all.

Just my thoughts.

Thanks,

Christian.

_______________________________________________
gtk-perl-list mailing list
gtk-perl-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-perl-list