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.
