A good place to start is Wikipedia’s Comparison of SVN clients. I skimmed through the list and retained a few solutions (my selection is arbitrary)

• OS X native front ends: Cornerstone, SCPlugin (finder integration), svnX, Versions, ZigVersion
• Java front ends: sdSVN, SmartSVN, Subversive, sventon, Syncro SVN
• Other front ends: RapidSVN

I was rather used to TortoiseSVN. Tortoise integrates well with the windows desktop although the SVN version isn’t flawless (been quite a learning curve to understand some of what it does, and how, and why…). Never mind, tortoise isn’t available on MacOS.

Since I started developing on OS X, I used svnX. It’s free, but it’s nothing like Tortoise. XCode integrates SVN services and it’s OK to do simple operations, but it doesn’t substitute a comprehensive SVN front end.

I’m testing SmartSVN right now. It feels great compared to svnX so far. However I’m kind of missing a nice desktop integration so before I drop the buck ($79, oh my goodness) I guess SCPlugin is next on my list.

How XCode manages my files…

Working with XCode doesn’t make it intuitive to keep the actual code base neat. What really happens is like this:

1. You create files and add them to your project.
2. You organize your files using groups. Groups are nice in a way. The downside, however, is that without care all files end up in the same folder.
3. You put aside files you don’t want anymore (well, yea… happens to everybody, right)
4. The files aren’t ‘project files’ anymore, but they’re still in your project folder and still in SVN.
5. XCode’s SVN integration keeps track of these files like anything else. So we have these ghost files in the repo and in the project director(ies), and we don’t really know where they’re coming from, what they’re doing here and if we want to keep them or not.

I feel annoyed with this situation – it’s not terribly annoying if we were only working with XCode, and that is exactly why it is annoying. I end up with scores of files that I don’t need, making checkouts heavier. I’m also having a hard time running other tools against my codebase. All the while everything looks perfectly neat inside XCode. And to perfect a rather diminishing portrait, the XCode proj. files aren’t anything easy like neat, humanly readable XML. More like porridge.

But surely that is nothing to bear with. Objective-C doesn’t even support packages anyway.

It might turn out that my first impressions on wxPython will be somehow biased. Well, not because there seems to be a decent, comprehensive tutorial readily available…

…but because the tutorial focuses on putting a very simple text editor together, and that’s where I’d like to start (see source code on the wx man pages).

Although wxPython isn’t bundled with Python itself, it installs easily on windows. The tutorial is comprehensive and readily addresses essential questions (GUI creation, layout, events).

I just picked the source code and skimmed through it while reformatting it. Superficially, there are similarities with tkinter. While reformatting I noticed stuff that looks strange to a python beginner (that, I am):

def askUserForFilename(self, **dialogOptions):
        dialog = wx.FileDialog(self, **dialogOptions)

This looks like a ‘double pointer’; I have no idea what it might be.

dialog = wx.MessageDialog(self, 'A sample editor\n'
            'in wxPython', 'About Sample Editor', wx.OK)

This may just be a way to continue a string on the next line (notice there’s no comma at end of line)

Anyways, I fired up this stuff (the reformatted version) and got an output window flashing on the screen and disappearing. Not good. So I went back to their ‘hello world’ and found they use…

wx.App(False)

… to avoid routing stdout to a separate window.

The mini text editor seems to be working like a charm. In the meantime, I haven’t learned much.

wxPython wins hands up for the  first three hours of use. It doesn’t mean much. Just a way to say, the docs seem fairly usable compared to tkinter, with lots of examples to play with and a nice tutorial.

Aside, I encountered an issue both with tkinter and wxPython: stdout doesn’t print until I exit the app. Maybe it does if we route the output to a separate window. Still not great.

I guess that’s it for now. However unfair I’m likely set to have a closer look at wxPython before anything else.

I’ve been idling (quite not literally) for more than a year over how I would progress my work on programming/coding tools.

One idea that stuck is that I’d be happier if my tool(s) included a scripting facility – rather than ‘step backwards’ and have to write an extension/module for every other need I run across.

If I think hard, I guess that’s where Python really came to mind. Then of course there is a choice:

1. I could port some of my tools to Python entirely (including the gui).
2. I could keep my tools (mainly, ee-ide) in java and provide some level of integration with Python.

I’m not overly fond of the second solution (and I’m having ‘post-thoughts’ about the whole ‘need scripting facilities’ idea even while I’m writing this).  Learning new stuff is nice. Integrating technologies is cool. In the meantime, the ‘some of level of integration’ casual talk is probably hiding costs that need to be measured against what could turn out to be a quick, clean and somehow progressive rewrite.

So I decided to try a couple of py GUI libraries (not incidentally chosen)

Round 1 – tkinter

I’ve used the following references

• A hello world tkinter tutorial
  => popping up a window (remember to run GUIs with pythonw.exe, not python)
• What looks like comprehensive tkinter docs
  => reading about events, scrollbars and the text widget…
• A kind of introduction / user guide
  => side reading, not always terribly efficient but contains useful recipes (aka, patterns)

After messing with this stuff for a while, I found pretty much what I would like to start with, a page explaining step by step how to make a notepad like text editor with tkinter.

This is what I got so far (35% battery left on my eepc)

from Tkinter import *

class GUI(Frame):
    def __init__(self,master=None):
            Frame.__init__(self,master)
            self.vbar=Scrollbar()
            self.text = Text(self, yscrollcommand=self.vbar.set)
            self.vbar.config(command=self.text.yview)
            self.vbar.pack(side=RIGHT,fill=Y)
            self.text.pack(side=LEFT,fill=BOTH)
            self.pack(fill=BOTH)
            self.text.bind("<Any-KeyPress>",self.onKeyPress)

    def onKeyPress(self,event):
        #print "bummer"
        self.text.insert(END, "bummer")

if __name__ == "__main__":
    guiFrame = GUI()
    guiFrame.mainloop()

First Impressions

I haven’t fallen in love with tkinter yet. The library itself doesn’t seem absolutely worse than another, but the docs I found are often unsuitable for ‘learning by practice’.

Don’t get me wrong, I like reading conceptual overviews and reference material (no… seriously). What lures me into doing just that and learning a library in depth is usually a bunch of seriously good code samples assorted with no-nonsense explanations.

Binding the scroll-bar to the text has been a minor pain. Yea, it’s just two lines of code. Compared to making a scrollpane and just adding the text component to it, it feels unwieldy, which brings me to another source of unease: I’m not always clear about how components get added, let alone how to remove them.

I also had to fiddle quite a bit to get the layout right. I had the scroll-bar not resizing and the text component filling the screen, and other weird stuff…

Please note I’m not judging the library, just how easily I got around it after 2-3 hours coding.

Guess I’ll be on my way trying wxPython next – let’s read this page first as it seems somehow un-intimidating, giving guidance about choosing a Python GUI.