Thank you very much BlueLines, both for your informative, and speedy response.

I'm not sure if I really want to dig into the grime that is called GUI's. (no matter how manly that would be :) ).

I really want to take an approach that would be something like GLADE (or at least what I know of what GLADE is). I don't mean I necessarily want a drag and drop GUI contruction kit (ala VB-sickness). Rather, I just don't want to be required to do all the low level grunt work unless I get backed into a corner without a stick.

I don't mind having to deal with somethings, but I do not intend on making this program a drag and drop GUI jukebox where you can take your GNOME/KDE aware filebrowser program and throw mp3s at mine!

(in fact, I'm not really enthusiastic about using GUI unless it does make my life simpler (as a programmer) or makes the UI much much much more powerful -- I'm quite happy with a TUI or even a command line-ish interface).

But again, I would like to stress my gratitude for this response, and I am going to go look at the GTK+ site right now!

Cheers and Thanks,
Gryn

While I can understand wanting to write/use a GUI for the experience, I'm of the opinion that someone has already written a helluva GUI. I call it a 'Web Browser'...

Seriously, with the modules available, you can write a webserver in Perl for a standalone app, or you can write something that runs under Apache, with or without mod_perl. Now you've got a client/server app, so you can use your laptop in the kitchen to manage it, stream it to work (if you've got the bandwidth), and (IMHO) you've better future-proofed it (/me thinks that web apps will survive longer than platform dependant GUI apps).

My basic take on anything I'm doing for my projects is that a web browser is going to be available on any computer I have. It's also gonna be networked, either with cable, 802.11b, or a cell modem. So, why not make it usable from everywhere/anywhere?

I've also seen apps written in Perl/Tk, GTK+, whatever, and frankly, I think they are about as visually unappealing as you can get. And a lot more work.

--Chris

e-mail jcwren

I don't mean I necessarily want a drag and drop GUI contruction kit (ala VB-sickness).

VB sickness would be _fine_ by me. I'm wanting to add basic GUIs some tools written in Perl. (So as to 'wizard' them a little for neophyte users)

The catch is that it needs to be cross platform _and_ I cannot rely on access (or permission) to an appropriate TCP/IP port. (So, AFAIK, browser+server model is out.)

So text or TK it is (as the distro is almost standard) .

A 3GL TK front end would be a blessing.


---


Butlerian Jihad now!

Thank you little (and of course jcwren).

I think I will pursue both avenues (GTK and HTML), I am well on my way with links to read about for GTK. However I know HTML is a hairy and TIMTOWDI way of programming.

Unfortunately HTML is also a place I am not well experienced (at least, on the backside of things). I understand what CGI is (as in, it's not a programming language, it's an interface), and a few other basic concepts.

However, I am very swamped at the myriad of choices on how to approach programming a HTML server. I like the idea of using Apache (because it's a good karma program and useful for many other things), but I'm not wholly against writing the UI to be completely standalone without Apache.

So, I am asking, which do I choose, what are the differences? mod_perl, etc? My UI program will be interfacing with the jukebox program to get it's information and send it's commands (most likely through UNIX domain and TCP/IP socket programming). It would need to present the current playlist with a few commands to help control what the play list looks like (I think the gtk-perl interface will have more powerful/interactive commands than the HTML one).

Thanks again guys for all your help, I really appreciate it!!! :)

Cheers,
Gryn

A lot depends on the details. Are you looking to have the program contain it's own mini-web server, allowing you to run it on any box that runs the rest of your perl code, and interact with it via a web-browser? or are you looking to have an HTML interface that will send commands to your jukebox server that runs on the same machine as the webserver, allowing you to connect to that box from any machine with a browser? (I'd really recommend the latter over the former. Less overhead, less re-inventing the wheel.)

Assuming the latter, I'd just set up Apache with the default mod_cgi which lets you run perl scripts as CGI. (Mod_perl is wonderful, but takes a significant time investment to learn the tricks of.)

Perl scripts via CGI work on a sort of call-response system. The webserver gets the request, runs the perl script, and returns any output.

What you'd probably want is to have your jukebox server sitting on the box, accepting connections (on, say, port 8080). Your perl script, if called with no arguments, simply returns an HTML page of options. If a button is clicked/selected on this page, the perl script will connect to port 8080, send whatever authentication you require, and send "SET VOLUME to 80%" (or whatever). Once it gets a reply from your jukebox server, it prints the results in HTML, re-displays the original options (all in HTML), and finishes. The webserver returns this result to the browser.

If you designed your jukebox program was built as a sort of API, your jukebox program will be a gtk-perl program (or even console) that does a loop over $jukebox->accept_commands().. Likewise, the client, be it a looping gtk-perl program, or a one-shot CGI script, will call $jukebox_client->play(), $jukebox_client->set_volume() etc.

Of course, this is all IMHO, TIMTOWTDI, and I'm very new to socket programming myself, so I have only my recent successes to judge by.

I'm also going to vote against using HTML/web-browsers. I love HTML, but I think there is a limit to stretching a technology into an area that it wasn't designed to handle. If you want to send a few sets of large data, HTML is great. If you are sending many packets of small data (such as when you want an instant response to, oh, say, a volume change), HTML is horrible.

Of course, the best way to do it is to write your code into a module/API, and call it from a wrapper script. Thus you might make Gtkperl your first interface, but it only takes a few lines in a CGI script to run it from HTML, and if the next guy to come along decides that he likes your functionality, but hates the interface, he can rewrite it in Perl-Tk without starting over from scratch.

I looked at the gtk-perl tutorial, and it looks alot nicer than the GTK+ tutorial (which is in C instead of perl).

I think I could handle (that is not be annoyed at :) ) using gtk-perl. But additionally I think some of the players functionality would be well suited to HTML (or some other UI). So I think I will keep my UI open and program it in both.

Thank you very much Maqs, BlueLines, and SwiftOne for the GTK pointers! :) .

Cheers,
Gryn

• Easy GUI tool
• I beleve it doesn't require the browser (can be a stand alone player)
• Can connect to a database
• Works on Linux, Mac, Win9x
• You can let someone else design the front end while you work on programming

Just a thought, good luck!

Thank you Ignorance,

I'm not very familiar with the feature set of Flash, except for the vector graphics (and nice ones at that).

I will though check it out, to see how the programming language goes. What I need is less graphics and more functionallity than anything. But since I don't know anything substantial about Flash, I can't make that decision. (So, as I said, I'll go look :) ).

Thanks again,
Gryn

Does HTML work with this? We shall see.

I have found that writing the UI parts, when going for ultimate portability, is best with Python/Tk. It really depends on the platorms you are writing for. Perl/Tk works great between Windows and Unix, it does not work with the Mac. Python/Tk will run on all three platforms with very minimal fuss. Plus Python is really easy to learn. I got the stage of writing UIs with python in about three to four days.

I tend to write the "unseen" stuff with Perl, such as server-side. Then I'll write the client side with Python. If you don't have to worry about Macs, then Perl/Tk would suffice. If you don't have to worry about Win32 machines, Perl/GTK+ should suffice.