The Cookbook has some text mode recipes (colour, reading from screen, termios) and some (shabby) Perl/Tk recipes. I'm astonished to realize that I have no idea where the 2003 GUI work goes in Perl. Are people still building Perl/Tk interfaces? Has GTkPerl supplanted it? Or has everyone bought a Mac and learned CamelBones?
Elaine pointed out that the web is the interface most people put on their programs, but I cover web stuff in another chapter. I'm specifically wondering about desktop GUI, not browser GUI.
Any comments to help me see through this miasma of possibilities will be greatly appreciated.
Thanks,
--Nat
Sure, it would be a major pain to research and write. But it would make my decision as to whether to upgrade to the 2nd edition much easier. Now, how much is that on your royalty statement?Problem: You want a Cross Platform GuiRecipe: TK, WX, whatever else, how to choose and use.
Problem: You want a Windows-only GUI
Recipe: win32, et al
Problem: You want a Mac-only GUI
Recipe: Camelbones, etc.
Problem: You want terminal GUI
Recipe: Termcap, etc.
Problem: You want a Gnome GUI.....
All the interfaces I have built in the last 4 years or so use HTML or the command line (or both).
Is there going to be an XML section in the cookbook?
Re:I'll have to agree with Elian
Ovid on 2003-01-29T23:36:44
While it is the case that many programmers want to use a browser for an interface, there are considerable difficulties with this approach. First, you have to create a state maintenance mechanism. Second, it's tough to duplicate true application behavior with a Web-based GUI.
Right now, I'm building a "temporary" CGI application that will be replaced with a desktop app when we have time. Originally, the designers had it create a lot of pop-ups for searching. However, the pop-ups can't be used as a modal dialog box. Further, the pop-ups had to remain if the search failed, or update the parent page if they succeeded. The only convenient way to do that was send all data back to the pop-up and have it update the parent and close itself on success, or to reprompt the user for input. It was such a kludge that I convinced the designer to put the search function on the original Web page and get rid of the pop-up.
That raised the problem of the DHTML menus not appearing over <select> boxes because of an IE bug that puts the z-index of the select box so high that nothing appears over it. ANd I won't even begin to discuss the horrors of making the DHTML cross-platform (we still haven't succeeded).
Further, when we had a 500 error, the DHTML menus from one frame wouldn't appear over the 500 error causing us to trap the errors, return a 200 OK status and write things to the log rather than allow proper error handling. Web-based GUIs are quick and easy, but you get what you pay for
:) Of course, if you stick with very vanilla HTML, many of these problems go away, but so does fine-grained control over the appearance and behavior of the application. Re:I'll have to agree with Elian
mir on 2003-01-30T00:16:12
Well, as most of the code I write is of the type "set parameters right, shoot, wait for results, go home" I don't have that kind of problem. Plain vanilla HTML is more than enough for me (for example, I just used multi-valued checkboxes for the first time 1 hour ago).
I agree that HTML does not give you nearly as much power as a regular GUI. It's just that you don't necessarily need the full power. The added bonus is also that with a web-based interface, users expect the application to be slow (they are rarely disapointed
;--) so you can take your sweet time in the back-end and forget about all those painful optimizations to get a good response time. Re:I'll have to agree with Elian
gnat on 2003-01-30T04:37:02
XML: yes. I'm unsure how many recipes, though, as the new stuff is to be written once the old stuff is updated.--Nat
Just to be pedantic....
VSarkiss on 2003-01-30T15:29:48
I'm pretty sure gnat meant hfb (Elaine Ashton), not Elian (Dan Sugalski).
In terms of web based user interfaces, there's lots to say with recipies on templating, MVC, generating multiple formats (HTML/XHTML/XML/WML/etc.), generating RSS, handling logins and customization, etc. These are much higher level issues than dealing with 500 error messages, using non-parsed headers, or using taint mode.
http://wxperl.sourceforge.net/
I've tried most GUI modules out there, and it's the only one I liked. It looks native on the platforms on which it runs (as opposed to looking ugly no matter where, like Tk). Its API makes sense. It's fast enough. I've found it stable. It has bindings for other languages too. The author is nice and helpful. I've been taking my time, but I'm building a XUL module for it which I hope will make it even easier to use. IOW, Wx rocks, the rest sucks
I personally would love to see thorough coverage of using Curses with Perl, or, heck, even outside of Perl. I do everything that I possibly can from a shell, and Curses-based interfaces, when done well, make my life much easier.
Also, I hope there is a section on command line interfaces, and how to do them well. I'm trying to do my part in making them easier to write (e.g., my Shell::Base module) but they're still pretty hard...
Re:Curses!
gnat on 2003-01-31T06:05:05
Have you seen the first edition? Recipe 15.12 ("Managing the Screen") gives an introduction to Curses. If you can suggest other specific recipes you'd like to see, I'll be happy to put them in.Similarly for commandline interfaces, what recipes do you want to see that aren't there yet? What problems are you facing that you want to have solved by a recipe?
--Nat
Re:Curses!
dlc on 2003-01-31T13:32:22
Of course I have!Have you seen the first edition?:) Unfortunately, my copy was out on loan yesterday. Recipe 15.12 ("Managing the Screen") gives an introduction to Curses. If you can suggest other specific recipes you'd like to see, I'll be happy to put them in.And it's a good introduction, but given time restraints and the Cookbook format, it's pretty short. The pieces of Curses that I think could do with better recipes include things like using multiple windows; the form, panel, and menu libraries; and using the stuff effectively from Perl -- the Perl API is sufficiently different from the C API that a lot of the available docs don't directly apply (e.g., the lack of mvw* functions). Maybe there's a whole book in there somewhere...
Similarly for commandline interfaces, what recipes do you want to see that aren't there yet? What problems are you facing that you want to have solved by a recipe?Well, I've worked out a lot of my own issues while I wrote Shell::Base (anyone know of a good readline tutorial?). I'd like to see the Term::ReadLine section (15.11) expanded (yes, I got my copy of the Cookbook back
;) to include some of the more advanced readline features, like custom completion functions, binding custom functions, prompt ornaments, and so on.
I want to see Gnome and WxPerl. I never liked Tk.
