Re: UDPM name space finalization
One quick comment - why not follow DBI's lead and use ::PurePerl:: instead of ::Perl::? --Bill. -- William R Ward[EMAIL PROTECTED] http://www.wards.net/~bill/ - A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.- Emerson
Re: UDPM name space finalization
UI::Dialog UI::Dialog::GNOME UI::Dialog::KDE UI::Dialog::Console UI::Dialog::Backend::Zenity UI::Dialog::Backend::GDialog UI::Dialog::Backend::XDialog UI::Dialog::Backend::KDialog UI::Dialog::Backend::CDialog UI::Dialog::Backend::Whiptail UI::Dialog::Backend::ASCII (future native perl extensions) UI::Dialog::PurePerl UI::Dialog::Backend::PurePerl::GTK UI::Dialog::Backend::PurePerl::Wx UI::Dialog::Backend::PurePerl::Tk UI::Dialog::Backend::PurePerl::QT ...and the beat goes on... -- Kevin C. Krinke [EMAIL PROTECTED] Open Door Software Inc.
Re: UDPM name space finalization
On 3 Jun 2003, Kevin C. Krinke wrote: ...and the beat goes on... Would somebody give Kevin a cookie for his concerted effort to get this audiences' difficult approval? His persistance is admirable IMHO. -- /chris Programming is a Dark Art, and it will always be. The programmer is fighting against the two most destructive forces in the universe: entropy and human stupidity. They're not things you can always overcome with a methodology or on a schedule. -Damian Conway, Perl God
Re: UDPM name space finalization
Kevin C. Krinke writes: UI::Dialog::Backend::GDialog ^^^^ Sorry to bring this up again, but I still don't see how the second Dialog helps clarify anything in the slightest. Having gone past UI::Dialog::Backend, we know that it is a user-interface thing, related to dialogue boxes, and provides a type of backend. Learning that the particular backend in this instance is a _dialog_ backend does not in anyway add to the knowledge about it: if it wasn't a dialog backend then it wouldn't be under UI::Dialog::Backend. Smylers
Re: UDPM name space finalization
On Tue, 2003-06-03 at 15:05, Smylers wrote: Kevin C. Krinke writes: UI::Dialog::Backend::GDialog ^^^^ Sorry to bring this up again, Sure you are... :) but I still don't see how the second Dialog helps clarify anything in the slightest. Having gone past UI::Dialog::Backend, we know that it is a user-interface thing, related to dialogue boxes, and provides a type of backend. Learning that the particular backend in this instance is a _dialog_ backend does not in anyway add to the knowledge about it: if it wasn't a dialog backend then it wouldn't be under UI::Dialog::Backend. The significance of the second dialog is that it's part of the name of the 3rd party binary which the particular backend wraps around. You'll notice that in my last name space list, the second dialog isn't consistent among the backends and so IMO is not redundant and instead respectful (to the name of the wrapped software) and intuitive (for those who use any of these dialog variants in shell scripts, and would rather do things in Perl than SH, will automatically know the feature set with little thought). The idea is that if you don't know what the backend is for... who cares? Use the UI::Dialog::GNOME or UI::Dialog::Curses modules and let the module figure out the best one for your environment. Heck don't even use a UI::Dialog::Class... just use the UI::Dialog one and it'll Do The Right Thing (tm) based on the user's environemnt. From GUI to no binary (native ASCII) something's bound to work :) Of course when using these modules you don't have access to variant-specific widgets like the various calendar implementations. But if you've heard of Xdialog and know it can do lots of things, well then you can use the specific backend directly and get access to all the features of Xdialog instead of just the compatible features made available by any of the non-Backend meta-modules. So basically I don't have a real choice as to what the Backends are called. They're just called the same name of the app they wrap. -- Kevin C. Krinke [EMAIL PROTECTED] Open Door Software Inc.
Re: UDPM name space finalization
All seems fine to me. Tim. On Tue, Jun 03, 2003 at 09:17:13PM -0400, Kevin C. Krinke wrote: UI::Dialog UI::Dialog::GNOME UI::Dialog::KDE UI::Dialog::Console UI::Dialog::Backend::Zenity UI::Dialog::Backend::GDialog UI::Dialog::Backend::XDialog UI::Dialog::Backend::KDialog UI::Dialog::Backend::CDialog UI::Dialog::Backend::Whiptail UI::Dialog::Backend::ASCII (future native perl extensions) UI::Dialog::PurePerl UI::Dialog::Backend::PurePerl::GTK UI::Dialog::Backend::PurePerl::Wx UI::Dialog::Backend::PurePerl::Tk UI::Dialog::Backend::PurePerl::QT ...and the beat goes on... -- Kevin C. Krinke [EMAIL PROTECTED] Open Door Software Inc.
Re: UDPM name space finalization
Sorry to bring this up again, I should have chased it more the last time but what exactly is UNIXy about about this module? The reason given previously was that all the dialog programs run on UNIX. That seems fairly incidental, it's not like there can't be dialog be programs for windows, Mac, Amiga etc and quite possibly there are. I presume if The Gimp can be compiled on windows then surely gDialog could be and KDialog could probably be ported easily as it's based on the QT toolkit. If I was searching for a dialog module on CPAN, unix would not be one of my search terms and if someone ever does write a backend for a windows dialog program then anyone who tries to find it could be confused by the UNIX and assume it won't work under windows. I just don't see any fundamental UNIX connection. Is there a reason why this module could never work on anything else? UI::Dialog::* seems like a much more apt prefix and as someone pointed out in another thread, there's nothing wrong with starting a new toplevel namespace as long as it makes sense and you don't hog the whole thing, F
Re: UDPM name space finalization
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. Unix::Dialog::Console, perhaps? Unix::Dialog::Whiptail - console Whiptail means nothing to me, but if it's a console thing how about Unix::Dialog::Console::Whiptail? (Yes, that's a long name, but you do seem to want to discourage people from using it.) Unix::Dialog::Zenity- GNOME (preferred) Unix::Dialog::GDialog - GNOME Unix::Dialog::KDialog - KDE Unix::Dialog::XDialog - X Again the repetition of Dialog doesn't seem to help things. Removing it from those last three would give: Unix::Dialog::X Unix::Dialog::G Unix::Dialog::K If I saw those I'm not sure I'd guess what G and K stand for. There doesn't seem to be any reason for not using their full names: Unix::Dialog::Gnome Unix::Dialog::KDE And then perhaps: Unix::Dialog::Gnome::Zenity Smylers
Re: UDPM name space finalization
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.
UDPM name space finalization
Ok I've decided on the following name space: Unix::Dialog- meta module Unix::Dialog::ASCII - native mode Unix::Dialog::Dialog- console (preferred) Unix::Dialog::Whiptail - console Unix::Dialog::Zenity- GNOME (preferred) Unix::Dialog::GDialog - GNOME Unix::Dialog::KDialog - KDE Unix::Dialog::XDialog - X Anyone have any objections? I'll be requesting the name spaces within a week (or so) from within the PAUSE site interface. -- Kevin C. Krinke [EMAIL PROTECTED] Open Door Software Inc.
