Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • gui perl (Score:2, Informative)

    I think you might have to cover everything! (Easy for me to say, I know.)

    Problem: You want a Cross Platform Gui

    Recipe: 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.....

    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 muc

  • 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?

    --
    mirod
    • 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

      • 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 r

        --
        mirod
    • XML: yes. I'm unsure how many recipes, though, as the new stuff is to be written once the old stuff is updated.

      --Nat

    • I'm pretty sure gnat meant hfb [perl.org] (Elaine Ashton), not Elian [perl.org] (Dan Sugalski).

  • I don't know what you have scoped out in the "web" chapter(s) for 2ed, but there's a lot of stuff that falls under that rather broad umbrella. You've mentioned mod_perl recipies before; presumably this is in line with the current Ch. 19, CGI programming. These are the kind of low-level recipies I'd look to if I have a basic issue I need to solve -- not if I'm trying to build a user interface.

    In terms of web based user interfaces, there's lots to say with recipies on templating, MVC, generating multiple

  • Don't forget... (Score:3, Interesting)

    by rjray (1649) on 2003.01.29 22:55 (#16519) Homepage Journal
    PerlQt [cpan.org].
    --

    --rjray

  • I've just started playing with WxPerl, attempting to develop cross platform applications.

    http://wxperl.sourceforge.net/ [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 :)

    --

    -- Robin Berjon [berjon.com]

  • Curses! (Score:2, Insightful)

    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 [cpan.org] module) but they're still pretty hard...

    --
    (darren)
    • 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

      • Have you seen the first edition?

        Of course I have! :) 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;

        --
        (darren)
  • I want to see Gnome and WxPerl. I never liked Tk.

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers