Re: Modules and Name space

["Kevin C. Krinke" <kckrinke opendoorsoftware com>]

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. 
> > "ErrorMsg"
> > 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, 
> $prompt_string)
>
> 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 
> clearer.

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.

> > :truth
> >        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 
> false.

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

> > [constants]
>
> those look handy.
>
>
> > The final module has two very simple utility functions:
> >
> > <code>
> >
> > 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.