Here's my 2 cents, having a bit of experience doing GUI programming, using databases, and doing web-dev both with and without MVC frameworks.
Don't bother! MVC is popular for the web because it makes a certain amount of sense -- you have a database, AND you have server-side scripts that generate "static" pages, which makes the View/Controller distinction somewhat more meaningful.
But what you are talking about is a single GUI program that provides access to a database. Keep looking around if you want, but, particularly if you have not done any GUI work before, you already have enough to learn. Perl/Tk works well, and looks nice if you add some color, etc. Here's a perl/Tk project I wrote a while back:
http://tkcodex.sf.net
If you want an idea of how Tk stuff comes out. I have not used perl/Gtk, but it is probably also good. Recently I wrote an app using Curses::UI, which is not truly "graphical", but it has the advantage of running via ssh and the API is nice and easy.
You can/should keep the "MVP" pattern in mind, but I think you are asking for a headache looking for a formal framework. The first thing I would do if I were you would be to create an SQlite address book which you can access and modify using your choosen GUI module, which might take you an afternoon. This will get you used to the API, etc, etc, before you jump in and start on what is important. | [reply] |
Thanks for the reply.
I figured the app was a bit small for using a framework. What isn't coming clear though is how all the bits of the GUI get organized. I mean, I can create a button and a menu, but do I keep all these in the same file (called GUI)? Or is each window a package?
I figured the framework would help me understand how it's all supposed to come together.
| [reply] |
Okay, like I said, I have done some stuff with perl's Tk module. I've also done GUI programming in C with Gtk+.
GUI API's are "widget" oriented. A button is a widget. A text entry is a widget. A window is also a widget. Some widgets "belong" to other widgets -- perl's Tk module is object oriented. Usually there is considered to be a "top level" widget which is the eventual ancestor of all other widgets. The top level widget is a window.
So the widgets are perl objects created from widget classes, which some classes inherit from others. Ie, no, each window is not a package unto itself. TkCodex is pretty complex and in fact does use a database (via Storable, not SQL) but it is still all one file (1300 lines/45k -- I am not totally proud of the sometimes sloppy/dense looking code, but I still use it on a near daily basis and it has not required any bug fixes in a year).
That is the general scheme of all GUI libraries, whether in perl or not (altho in C there are no formal objects/classes, the idea is same). I would recommend Tk because it is a common perl package, and it is highly functional without being to hard to use. Gtk will likely match your destktop better on a linux box, and has probably some additional capacities if you want to embed 3D graphics, et al. Outside of linux, it may "clash" and is possibly harder to learn/use than Tk (certainly, the C library is...). Qt would be a good choice on windows or mac, but I notice perl/Qt has been unmaintained for a long time.
I also know there are tk and gtk programmers here at perlmonks -- they helped me. So take your pick and if you have a problem, this is the place to get assistance. Like I said before, and I can't stress this enough, do a small experimental project FIRST before you start fooling around seriously. Life will be much easier that way and the time it takes will be saved later because of the learning. An address book, or anything else you can think of to make into an SQL database, is ideal. You do not need to separate the GUI and the db code into separate packages (altho you can if you want). You just use the GUI buttons or whatever to issue queries, insertions, what-have-you (I'm presuming you've already done a bit of SQLite manipulation in perl using DBI), and you can display strings using "label" or "textarea" widgets.
| [reply] |