Blog Why Not?!

GUI Programming
How to program GUI
Programming and Design, 090704

So, I wanted to write down this thing that I have learned about programming GUI. Being really interested in design patterns and so forth, I took a step back and begun thinking of what we actually do, what kind of strategies we have, when we program GUI.

What I have learned is that while OO-programming and modularization usually is a good way of tackling problems, it is not such a good strategy when handling some part of GUI programming. Though the MVC is a nice pattern, the V-part can also be broken down into modules and one part of this module does not, in my experience, lend itself to OO.

Take as for an example this list that I am working on right now. It is the usual infinite list where we got potentially infinite number of elements. To make this possible I have created a paging system that accordingly to the OO way of doing things and populating the list is done via a Binder which is also harmonizes with OO. But when moving, swapping (instead of having an infinite number of graphical elements, there is a finite number which are recycled) and interacting with the finite number of graphical elements the story is a little different. Instead of using taking an OO-strategy, the list is considered a data structure where the x- and y-coordinates of the elements are the keys to accessing the elements. The elements are not put in a linked list and does not even have a static index (the index can easily be calculated on the fly). Think of it like this, instead of using object-references, you have the x- and y-coordinates and the elements are ordered in reference not to each others but by their position on the screen. Thus the element has no knowledge of each others, or even that they are existing in a list. The element manager (the List) knows about all the elements, but does not know that they contain any data really. All it really cares about is the coordinates about the elements and if it should perform any swapping. The binder takes care of setting the data, when it is told to.

So while the data is managed through OO, the element handling are not and the same goes for the rest of the GUI. Perhaps one could even say that stuff like lists have more in common with mathematical expressions, then object oriented problems. Grouping is done for sure and so forth, so there is definitely encapsulation and what not. But a fundamental is to think about GUI elements as the graphical entities they really are, with coordinates and everything, instead of considering them as single referenced objects. This makes everything just so much easier to program. Sure, in the end you will end up with this widjet that you will be handling as an object, but the design up until then will be one with very little entanglements and will be highly mutable and adoptable to just about any type of GUI that I have had experience of.

That was but one example of what I mean and I feel that there are so much more to write about, but I am off to hit the beach so I have to stop writing now.

- Aramis

Comments

Blog Why Not?!
Personal Blog of Aramis
Welcome. Filter: Show all, Personal, Programming & Design, Spirit, Economics.

There is no particular goal to this blog, but to convey what I find interesting and worth writing about. Get blog as RSS or ATOM