Re: Modules and Name space

On Wed, 2004-09-15 at 22:16, muppet wrote:
On Sep 15, 2004, at 2:33 PM, Kevin C. Krinke wrote:

Before we get to my real questions, here's a quick tut on how to use
these wrappers. There are currently three dialogs implemented.
"Message"  which is a straight forward message box, ok button and
optional stock-icon placed nicely to the left of the content. 
which is just a "Message" with the default title of "Error" and
stock-icon "gtk-dialog-error". The last is "Question" which is the same
a "Message" with the exception of having "Yes" and "No" buttons.

i hate to say it, because it sounds like you've done a fair amount of 
work, but Gtk2::MessageDialog (nee GtkMessageDialog) has most of this 
functionality already, including the ability to specify a parent window 
(which is rather important, actually); they are meant to be standards, 
and gtk+ 2.6 is supposed to have extended gnome HIG compliance.  
Gnome2::App has some handlers which make sure the message dialogs are 
transient to the app window and have the app's name as the title.

are your dialogs meant to be replacements for those, or just wrappers 
around them?

Simple wrappers.

# Note: Questions always block with a call to run()
$answer = new_run Question ( title => "And?",
                             text => "So what's it going to be?" );
if ( $answer eq 'yes' ) {
} else {

i once created a wrapper along the lines of

   boolean = confirm ($parent, $title, $verb, $default_yes, 

which will create a dialog with two buttons, saying "Don't $verb" and 
"$verb", in a style used by Mac and recent Gnome -- i find it a little 

Interesting. I'd suppose this would go into Gtk2::Utils as opposed to
it's own name space however I think there are two different purposes to
our variances. I myself don't like the "Don't $verb" buttons because
it's not really translatable unless you provide an extra option for the
"Don't" replacement but that seems to me kinda hackish whereas using
stock gtk-yes and gtk-no buttons seems more practical to me.

       TRUE = 1
       FALSE = 0

i think ross already pointed out that these are in Glib since 1.020.  
in fact, in Glib, the FALSE is '', as is usually returned by perl for 

Duly noted but in it's more for completeness but can be removed.


those look handy.

The final module has two very simple utility functions:


sub Gtk2_Main_Iteration {
    while ( events_pending Gtk2 ) {
        main_iteration Gtk2;

a more to-the-point name would be "update_ui" or "flush_events", as 
that's what you'd use this for.  "Main_Iteration" makes it sound like 
it's just going to go through once.  the original Inline-based Gtk2 had 
an "update_ui", iirc.

I like flush_events() better as IMHO the former implies only visual
updates but I don't like flush_events() that much either. How about
something more direct then like process_pending_events()?

So what this all boils down to is the following questions:

A) Do I tuck these things into UI::Dialog::PurePerl::Gtk2?
   (my original plan).

if they are just backend implementations for UI::Dialog, then that may 
make sense.

Well, the current code is not "just" backend implementations. Heck they
have nothing to do with UI::Dialog short of mimicking zenity/xdialog
widgets using Gtk2 and Perl. I don't like the UI::Dialog::PurePerl::Gtk2
name space that much but as a backend for UI::Dialog that's fine and
I'll implement it someday but for the purposes at hand these modules are
extremely simple and would not fit well in UI::Dialog at all (I'd need
to add a date picker, text entry field, etc, etc).

B) Make a separate module under a different name space, ie: Gtk2::UI::*

it would be Gtk2::Ex, our "sanctioned" pureperl extension namespace (to 
avoid potential clashes with future additions from gtk+).

Gtk2::Ex sounds great.

C) either A or B but omit the Constants and/or Utils

Gtk2::Ex::Constants and Gtk2::Ex::Utils would be handy; i could see 
lots of useful stuff fitting nicely into those.

So you're implying the other way around? Leave the dialogs to
Gtk2::MessageDialog and provide the Constants (minus :truth) and Utils
modules? Hmm.

D) Get suggestions and implement a best fit solution
All feedback on this topic is greatly appreciated.

give it a few days for more people to respond; there are other 
opinionated people on the list besides ross and me.  ;-)

/me nods
Of course.

Kevin C. Krinke <kckrinke opendoorsoftware com>
Open Door Software Inc.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]