Jaap Karssenberg wrote:
I looked at that module before and I got the feeling that it is intended as an alternative interface for the Gtk2 widgets.
Here you're wrong ;) It just wraps the most important Gtk2 widgets and adds the convenient auto-updating magic to them, but it's not an alternative, more a supplement.
You still need to design a layout in terms of the widgets from the Gtk2 namespace
The major goal is to abstract the layout. Of course you need to think about the structure of your GUI, even with Gtk2::Ex::FormFactory. But in particular for the thing you have in mind, building a preferences dialog, you can just use the Gtk2::Ex::FormFactory::Form widget, which arranges your widgets in a standard way (label left, widget right) and you don't have do any further layout. And even if you don't like the layout a Gtk2::Ex::FormFactory::Form widget is designed by default: just write your own Gtk2::Ex::FormFactory::Layout module which implements it in another way. That's one of the key features: abstracting data from the GUI *and* the layout.
and it looks like it is intended to design the complete interface instead of just a form (I'm thinking of a "form" in terms of something like a "form element in a webpage). What I'm looking for is not an alternative way of writing my application, it's fine with me to deal directly with the Gtk2 objects -
You still can deal with the Gtk2 objects, if you like or need to. As well Gtk2::Ex::FormFactory doesn't force you to use it for anything. It's just a convenient tool to build Gtk2 widget trees without fiddling with all the details. You can mix it in an arbitrary way with other parts of your GUI, which are constructed directly out of Gtk2 widgets.
I just want to have an abstraction layer for my hash with preferences. It's not clear to me how Gtk2::Ex::FormFactory is similar to the module I intend to write.
Of course it's a bit more than that. But it does what you want: abstracting the data from the GUI layout, widgets get automatically initialized with your data and changes are passed pack into your data structure. The difference is that Gtk2::Ex::FormFactory not just manages a simple hash of values, instead it expects an object oriented data model. In that way it's probably not that simple to use than the module you have in mind, but I bet once you started writing it, you'll add more and more features which Gtk2::Ex::FormFactory already has ;) E.g. the hash data model isn't sufficient. Probably it is for really simple forms, which consist only of some text entries. But what about combo boxes (which need a preset list), popups or lists (which need a list of entries and probably allow multiple values), radio buttons and so on? You need more than simple hash to declare these different widget types, and that's why I bet you're getting closer to Gtk2::Ex::FormFactory than you think know ;) Ok, the declaration is done in the XML file, not in the data hash, but if you put the combo preset lists in XML, you're mixing layout and data! Think of managing translations of your GUI. You need to have one XML file for each language, while a Gtk2::Ex::FormFactory application simply can be localized with gettext. The XML layout idea is good (not for nothing glade uses this approach), I thought already about that for Gtk2::Ex::FormFactory, because writing widget trees with it looks much like XML, due to the nested structure and the attributes which are defined for each widget. But the disadvantage of the XML solution is that you can't use closures that simply, because the XML stuff is completely unattached from the Perl code it's used with.
I do not mean to start a flame about this, but correct me if I'm wrong.
I can't see any flame here ;) And I think both modules would have their domains. Gkt2::Ex::FormFactory has a learning curve, because it's architecture is abstract and the API offers many features. Gtk2::Ex::FormManager should be leaner because it's focus is narrower. Regards, Joern -- Joern Reder supporting: http://www.zyn.de/ unbelievable: http://www.exit1.org/ CPAN: http://www.perl.com/CPAN/modules/by-authors/id/J/JR/JRED
Attachment:
pgp2uC_5cR2tO.pgp
Description: PGP signature