A good way to learn GUI programming is to pick a library set that supports GUIs and go with it. Build a couple of applications with that library then try another. Pick a library that functions at the level of the graphics stack where you want to work and that's fitting for your target system.

There are CPAN modules for Tk, Wx, SFML, IUP, and Prima all of which are fairly straightforward. Tk isn't very pretty but is fairly simple and multi-language (it originally comes from the TCL community). Prima is Perl-specific. Wx is cross-platform and multi-language but is a bit more involved than Tk. IUP is cross-platform as well. There are some Windows GUI modules too.

Then there are the desktop environment types of libraries. Gtk and Qt are widely used on Linux and work on other platforms (including Windows and Mac) well if the right libraries are installed. Gtk is the graphics library used by Gnome and Qt is used by KDE. Gtk, Gtk2, Gtk3, QtCore4 and its associated modules, and more are available.

Any of the above are designed for windows, widgets, controls, all those things that a desktop GUI does. Then are the libraries actually focused on games and multimedia like OpenGL, SDL and the SDLx libraries, and the like. These could be useful for a word game with tiles, but may be overkill.

The X11 family of modules are for lower-level access to X11 services. Those are probably not what you're wanting, but it's good to know they are available.

Then there are the less conventional ways to do this. If characters are okay, you could go with Curses or Curses::Application maybe with Curses::UI. You could make it a web app and play it in a browser (using a local little web server for local games). You could make it hundreds of different ways.

I think worrying about how the game rules work first is a grand idea. Get an engine that represents your board, tiles, players, tile draws, and plays. Have a good idea how you want to move data in and out of that. Then build whatever UI to send and receive data from outside the engine, either as separate modules or even separate programs.

thanks and ++mr_mischief for this wonderful GUI programming perl panorama, state of the art 2016!

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

mr_mischief, Thank you very much for a detailed overview on GUI development and what options are available out there. Your final paragraph on a real life action plan is very useful as well for beginners like me.

There's Games::Literati already in CPAN which does all the math work (scoring words, and finding optimum scores, which would be great for a computer opponent). I recently took over maintenance of the module -- it originally had Scrabble and Literati (the old Yahoo! Games board from the early 2000's), and I added in Words With Friends, and Super-Scrabble, and hopefully making it easier to extend.

When I found the right Round Tuit^TM, I was going to eventually expand it to have alternate interfaces of a GUI and a web interface -- either as sub-modules, or over in the App hierarchy. (Something like App::Games::Literati::Web, ...::WinGui, ...::TkGui). But I wouldn't complain if you wanted to help / work on the front ends; in fact, it would be good to work together to keep them in sync.

If you do want to go that direction, play around with the existing single-turn command-line interface from the existing module, and then we can talk about what features I need to add to the backend to make it easier to program the interface. I know one quick fix would be for the game initializer routines to define the letter frequencies, not just the letter scores and board scores. There's probably also a few functions that need to be taken out into their own sub instead of being buried in the find-best-scores loop, soas to make it easier for the interface.

I was in your position a few years ago. I wanted to develop a GUI version of "Hangman", and had no idea how to start. I bought the book "Mastering Perl/Tk". It was exactly what I needed to get started. I still rely on that book as I continue to add minor enhancements.

On the down side, the Tk module is no longer included in the ActiveState download. (With help from this forum, I was able to get a precompiled version that works with my perl.)

... module is no longer included in the ActiveState download ...

That's why I recommend using Strawberry Perl instead of using ActivePerl:

AP is essentially a binary distribution, using a propritary package manager. Either ActiveState (or someone else) provides a compiled package, or you are lost. OK, AS has added some package some time ago that delivers compiler, linker, make, but you need to know and install that.

Stawberry Perl comes wil compiler, linker, make and everything else you need to build perl modules on Windows, plus several modules already compiled for you. It offers the same cpan tool that you find on any unix-like operating system. No surprises, no new tricks to learn to get stuff done.

(Sometimes, I install SP just for the compiler, to get some C program running on Windows.)

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

That's why I recommend using Strawberry Perl instead of using ActivePerl:

In theory, I agree. I have not acted on your recommendation because I remain a little lazy and a lot timid.

Marshall has indicated that my concern about Tk on AP is no longer an issue.

Bill

I am running Active State 5.20.2, I think the latest release. Use the Perl Packet Manager (ppm at the command prompt) to install Tk. There is also Tkx. The Tk came with a lot more widgets than I expected. I've been able to run a number of Tk GUI question code pretty much "right away". There is not as much "help" for the widgets, there are more there than you would think from the documentation.

You don't mention which OS you are in. Or are you trying for something that's a bit more agnostic in terms of OS and make it a website? A perl back-end and a javascript front end is a nice portable solution. I see that many nice GUI libraries have been recommended. However I'm going to start somewhere else.

My recommendation is for you to break apart your design a bit. Leave the GUI alone for a while. If you want to choose Perl for the backend, (and later the front-end) great. So start with the back-end since it seems that that's where you are most comfortable.

Make it a command line interface and write system that can take that input and process what you want. Keep score. Keep track of the game. However you want to design this. Once you have the core functionality (classes or functions or however you are coding it) then you should be able to graft on a UI that interfaces with what you have and that choice becomes INDEPENDENT of your existing work to a large extent. And that's a Good-Thing(tm). Free the UI and the backend from any inter-dependencies if you can. My 2 cents.

Hi KurtSchwind, thanks for your suggestions, at the moment I am not sure about the platform I am targeting. At the back of my mind I would like to develop the whole thing so that it can be played via a webpage so that I can share with the world the tweaks that I want to introduce e.g change things that frustrate me with the game. As you emphatically suggested I will now focus on figuring out the mechanics, with input just from the command line, and try to make something that works. I might use the Games::Literati module suggested above or the script that was linked above, but I might try my luck with writing the whole thing from scratch. Kind Regards Demeter

I haven't tried this program but it looks like a good starting point for you.

Chapter 15 GUI Example: Tetris
Advanced Perl Programming
By Sriram Srinivasan