Heh, it seems I've neglected to mention the significance of the
Unix::Dialog module. All the rest are the back-ends and lumping them
into X, Gnome, and KDE would not maintain the clean separation that I'm
now looking for.
This example should help to illustrate:
<EXAMPLE>
#!/usr/bin/perl
use Unix::Dialog;
#: auto-detect in order: Zenity, GDialog, XDialog
my $GNOME = new Unix::Dialog::GNOME (defaults=>values);
#: auto-detect in order: KDialog, XDialog
my $KDE = new Unix::Dialog::KDE (defaults=>values);
#: auto-detect in order: XDialog, Zenity, GDialog, KDialog
my $X = new Unix::Dialog::X (defaults=>values);
#: auto-detect in order: Dialog, GDialog, Whiptail, Native ASCII
my $Console = new Unix::Dialog::Console (defaults=>values);
#: auto-detect in order:
#: if $ENV{DISPLAY} ... Zenity, GDialog, KDialog, XDialog
#: else ... Dialog GDialog, Whiptail, Native ASCII
my $ASCII = new Unix::Dialog (defaults=>values);
</EXAMPLE>
The above classes are all "included" within the Unix/Dialog.pm so that
one module gives you access to all back-ends. Unix::Dialog will simply
return a new object of the appropriate sub-class. This way things like
ref($d) will report nice and clean strings like Unix::Dialog::Zenity and
all modules will have a method called what_am_i() that will return one
of the following as appropriate: GNOME, KDE, CONSOLE. When using any of
the Unix::Dialog meta module sub classes, the new objects are
initialized in a compatibility mode where variant-specific functionality
is disabled (to a certain extent depending on the back-end).
On Thu, 2003-05-29 at 17:54, Smylers wrote:
> Kevin C. Krinke writes:
>
> > Ok I've decided on the following name space:
> >
> > Unix::Dialog - meta module
> > Unix::Dialog::ASCII - native mode
> > Unix::Dialog::Dialog - console (preferred)
>
> Having "Dialog" twice doesn't really aid with working out what it is; I
> don't immediately see what anybody gains from the second "Dialog" that
> they wouldn't've worked out from the first.
Having dialog twice may not make sense at first glance but it is not
intended to be used directly unless you want to "force" a specific
dialog variant instead of using the Unix::Dialog meta module. If people
have strong feelings that Unix::Dialog::Dialog is way too bad, I could
compromise with Unix::Dialog::cDialog as that's what the project is now
called even though the binary is still just 'dialog'.
I've chosen this meta module hierarchy for the specific purpose of not
having overly long name space extensions and to avoid the necessity of
single letter abbreviations within the name space.
Or maybe I'm not headed in the right direction with this meta module
stuff and you all would like to have something like the following name
space hierarchy instead:
Unix::Dialog - does nothing, simply POD
Unix::Dialog::Gnome - auto zenity gdialog Xdialog
Unix::Dialog::Gnome::Zenity
Unix::Dialog::Gnome::GDialog
Unix::Dialog::KDE - auto kdialog, Xdialog
Unix::Dialog::KDE::KDialog
Unix::Dialog::X - auto gnome, kde, X
Unix::Dialog::Console - auto dialog, gdialog, whiptail, ASCII
Unix::Dialog::Console::Dialog
Unix::Dialog::Console::Whiptail
Unix::Dialog::Console::ASCII
Thanks for your feedback, all is welcome and appreciated.
PS: For those not in the know; GDialog supports both GUI and Console
interfaces, thus making it a very versatile widget tool. Also Zenity is
the Gnome2 replacement for GDialog (which is gtk/gnome1).
PPS: Sorry for the lack of detail within the last email. I hope this
clears things up and shows that I've put more thought into things than
just the pathetic UDPM name/design.
--
Kevin C. Krinke <[EMAIL PROTECTED]>
Open Door Software Inc.
