Tag Archives: Programming

Python Code completion in Emacs — at last!

I’ve been coding Python in Emacs for years now, and for the most part it’s been a satisfactory experience. After experimenting with various python modes and utilities, I’ve had a pretty good environment that marries Emacs editing to syntax highlighting, real-time error highlighting, the ipython shell, linting tools like pylint and pep8, and various other goodies. But the one hole, the one sore spot in the whole works, was code completion. Something even idle can do out-of-the-box was simply beyond my ability to get functional in Emacs.

I’d tried just about every solution the internet could offer: PyMacs, company-mode, anything-mode, ipython completion, standard autocomplete-mode. Everything I tried either gave unacceptable results (like autocomplete-mode, which just scans the current buffer for completion information), or just flat-out didn’t work no matter how many tutorials I followed.

Here lately I’ve been trying to work a lot more on my Pythoning, so I decided to see if the state of the art has caught up with this need. Echo base, I’ve found it. Repeat: I’ve found it.

(more…)

Tkinter: not dead yet!

If you follow my posts or projects much, you know that, when it comes to GUI toolkits for Python, I’m a confirmed PyQT guy. QT is arguably the most advanced, polished, complete, and powerful GUI toolkit do-everything programming library out there, and a treat to use. But sometimes it’s overkill, and when I have to put together something quick for certain legacy OS that lack decent package management, having to load in Python and extra libraries just to get a couple text fields and a button doesn’t make sense1.

Wouldn’t it be great if there was a really simple, easy to use, lightweight graphics toolkit built right in to the standard Python libraries, so you could pop together those little one-window GUIs without loading in extra stuff? Well, hey, what’s this dusty thing over here in the corner? It looks like… Tkinter!?!??

(more…)

Better window splitting in Emacs

Emacs’ window-splitting functionality is an ergonomic way to view multiple files at once without having to deal with shuffling around floating windows or clicking between tabs. Anyone who does much with Emacs probably knows already that they can use C-x 2 or C-x 3 to split the window vertically or horizontally.

What always bothered me about this feature was that the newly-created window defaulted to the current buffer, which in layspeak means you had the same file or content open in both your new window and the old. The was almost (but not quite) never the behavior I wanted, since usually you split the window to have multiple buffers on screen at once. Typically, I would do this right after opening a new file or buffer to compare with whatever I already had open, so that I would have the old buffer in one window and the new buffer in another.

This is where having an extensible editor rocks; because in Emacs, if you get tired enough of a behavior, you start hacking elisp and fix it…

(more…)

WCGBrowser update: http_proxy and more

For users of WCGBrowser…

In the last few days I’ve added a few features:

  • Firstly, proxy server settings. Several people requested this, though none wanted to sponsor development (I only asked $100 US). Turns out I needed it for something I was doing myself, so happy birthday everyone, you get this for free. Proxy settings can be set from the CLI, config file, or environment variables (common on many Linuxes).
  • Secondly, stylesheets. Not that there’s much to style on WCGBrowser (the navigation bar, mostly), but you can now do it with QSS style sheets. A (really tasteless) example stylesheet is included.

Latest code can of course be downloaded from the wcgbrowser github page, or just do a “git pull” if you cloned it from there in the first place.

Enjoy! 😀

Five reasons why I choose PostgreSQL

I’ve worked with most of the major SQL databases over the last several years, including Oracle, MS SQLserver, MySQL, and PostgreSQL, both as an admin and (more often) as a developer. They’ve all got their ups and downs (some more of one than the other…), but when it comes to choosing a database for my own projects, my choice these days is nearly always PostgreSQL. This amazing, powerful server is unfortunately one of the hidden gems of the relational database world, so I thought I’d share a few reasons why it’s my personal favorite.

(more…)

From PHP to Python: things I wish I’d known

The story so far…

Back around 2005 I took my first leap into the world of writing useful programs armed only with my laptop, a Pentium II running Debian, and a fat book on PHP5. Though I’d taken a few classes on C++ and tinkered with BASIC on a few different platforms over the years, I’d never managed to produce anything that actually did anything practical (or, did it very well, at any rate); with PHP, though, it didn’t take long to spread my coding wings and take to the air as a novice web developer.

Before long, my skills proved useful in some critical situations at work, and my place as a web developer was cemented. My PHP code became more mature as I learned hard lessons of experience and combined them with the programming theory and computer science I was avidly consuming on the web.

Around the same time, I got interested in Python when I saw a coworker using it to build powerful desktop applications quickly and effortlessly; I wanted to round out my programming skills with a “desktop stack” as quick and simple as PHP, and Python turned out to be a good choice.

So for a few years now I’ve written mainly in these two languages, PHP for the web and Python for the desktop. As my applications have grown bigger and more complex, I began to develop a growing discontentment with PHP on a number of levels. So when people started talking about doing web development in Python, I had to see if I could make the switch.

(more…)

State of WCGBrowser

While I realize that wcgbrowser isn’t exactly the most exciting or groundbreaking piece of software ever created, I’ve been having fun improving it bit by bit over the last few months since I opened the source code.  If I keep hacking away at this pace, I’ll easily have the most feature-packed kiosk browser around, for whatever that’s worth.

Here’s a quick rundown of new features, if you haven’t been watching the git logs closely:

(more…)

KiLauncher and Qt Stylesheets

The default theme of KiLauncher

The default theme for KiLauncher. Ok, so it kind of looks like your gramma’s formica breakfast table from the 1970s.

I’ve been doing a lot of tinkering on my KiLauncher project over the last week or so, and it’s not only shaping up into a nice useful little application, but an educational opportunity as well

My goals for KiLauncher were to make it both theme-able, and configurable with plain-text files.  The natural mechanism for this (for the theme, anyway) was CSS, a format with which any self-respecting UI designer is familiar.  Fortunately, Qt supports a subset of CSS to style its GUI classes, sometimes referred to as QSS.

(more…)

New project:KiLauncher

Last night i uploaded a new project to my github page, KiLauncher.  It’s a fullscreen, static (as in not auto-updating) launcher menu aimed at kiosks, kids computers, corporate systems, and any other situation where an administrator wants to be able to both provide a simple interface and exercise some control over what applications are available to the user.

The software is still in the early stages, of course; I’m still working out the best way to structure the config file; yet it meets all its primary goals at this point and works just fine.  It’s built in python and QT of course, and after my positive experience using YAML in wcgbrowser, I’m of course using it for KiLauncher too. Unlike wcgbrowser, I don’t have a real-world use for this software yet, but maybe someone who does can give me some feedback on it.

WCGBrowser updated

I’ve been wanting for some time to update my wcgbrowser code to be python3 compatible, but I’ve been held back by the ambiguity surrounding the configobj library — in a nuthshell, the official project isn’t 3.x compatible, but there is a fork that is. Unfortunately the fork maintainer isn’t putting real effort into a release, and Debian won’t include it until they do.

So fed up with that, I got a wild idea last night to port the code to something more supported. I considered JSON and XML, but settled on YAML, since it seems to be reasonably hand-hackable, well supported, and handles about any data types I need.

I thought this would be a big deal, but surprisingly it only took about 20 minutes to get things working. I decided to keep going with my momentum by adding the remaining command-line configuration parameters to the config file and making sure the whole thing worked with python 3.

I also fixed some logic bugs in the process. Nice.

If anyone out there is actually using it, you can get the latest code on github.  Naturally, the conversion to YAML will break any existing configuration; sorry in advance.  To make up for it, I’ve fully commented the config file so it should be pretty simple to figure out how to port it over.  Also, bear in mind that it’s now looking for a config file called “wcgbrowser.yaml”, not “wcgbrowser.conf”.

« Previous PageNext Page »