Archive for the 'FOSS' category

running flake8 in git's pre-commit

Oct 23 2011 Published by under FOSS, software

I'm forever forgetting to remove debug statements or to run flake8 on my source code. Not to panic though, git hooks to the rescue!

You can just put pre-commit into $PROJECT_DIR/.git/hooks, chmod +x it and be away.

This is the useful part of the file;

ret_code=0

for file in $(git diff --name-only --cached $against)
do
    if [ ! -z "$(grep 'DEBUGS' $file)" ]
    then
        echo "DEBUGS in file $file"
        ret_code=1
    fi

    if [ "${file##*.}" == "py" ]
    then
        flake8 $file
        if [ $? != 0 ]
        then
            ret_code=1
        fi
    fi
done

exit $ret_code

$against is the commit to check against (taken from the pre-commit.sample file).

DEBUGS is the comment tag I use to denote debug statements, which is used by geany in the Task addons plugin to list any occurrences of it in the file (along with TODO and FIXME comments)

No responses yet

Importing existing git repos into Eclipse/PyDev

Aug 22 2011 Published by under FOSS, Lapwing.OS, software

I've spent most of today trying to get either Anjuta or Eclipse/PyDev working with my django git repos for lapwing.os/website. And watching notch work on his LundumDare 48 submission.

I probably missed an easier method, but these were the steps;

  1. File > Import > Projects from Git
  2. Next, Add
  3. Browse, Select the directory with your git repo in, OK
  4. Search, OK
  5. Next, Import as General Project, Enter a project name if you wish
  6. In the Package Explorer pane, right click on the new project
  7. Pydev > Set as Django Project
  8. In the Package Explorer pane, right click on the project again
  9. Properties > PyDev - PYTHONPATH, in Source Folders click "Add source folder" and include the selected directory
  10. Properties > PyDev - Django  and set where manage.py and settings.py are. You may need to copy manage.py from somewhere if isn't part of your git repo

By default Eclipse/PyDev add .project and .pydevproject to the directory, so you may want to add them to your .gitignore file.

No responses yet

lapwing-web.download; mockups

Aug 22 2010 Published by under FOSS, software

I've been working on some mockups for lapwing-web download application.
These are some SVG mockups made using Inkscape and JessyInk. JessyInk turns SVG files into mini presentations, in this case I've used the effects to fade in the comments about some design decisions.
These aren't particularly high quality and may change before they get into the application.

You can click the images to get to the associated SVG file, where clicking the image opens the comments or moves to the next slide.
You can also use the left and right arrow keys to navigate backward/forward as needed.
Hopefully the mockups will become reality in the near future ;)

Continue Reading »

No responses yet

peewit, Lapwing-Linux and annoying kernels

Aug 05 2010 Published by under FOSS, software

I've been working on peewit recently. I've finally got it talking to telepathy-mission-control, logging in, retrieving a contacts list, displaying it in the GUI and updating when contacts leave/change status.
The current code is the master branch, but extra work may go on in the "tmc" branch.

This has distracted me slightly from Lapwing-Linux, but not by much. Updates are still occurring, although the 2009 core is starting to creak a bit. I've decided therefore to limit updates to aaa_base/aax_base to security and major bug fixing only; there is a lot of exciting things coming in the next 6 months or so (gobject-introspection, GVariants, GTK3, GSettings) that would be more suited to a clean base, rather than getting tacked onto or hacked into 2009.

Where does this leave 2009? I am going to get a release out, with a LiveCD and GUI installer. First however I have to get the web2py site working as I'm fed up with TikiWiki being so clunky (yes, I do remember singing it's praises before. Blogged too soon ...).
Writing a custom site will be better in the long run, but is still a long run ;) The current hurdle is porting my bastardised version of pyForum to work on GAE, or writing it from scratch to work without SQL based queries.
Whilst it would be nice to get the bugtracker and package lister working, I'd be happy to settle for the wiki, forum and user apps working to start with.

LiveCD/installer wise, I'm probably not going to use anaconda, it seems to be getting weirder with each release. vanellus will be the installer for the forseeable future, basically copying the SquashFS image to the HDD. Currently it requires code to do the actual installation, the GUI is good to go AFAIR.

Kernels. Damn. 2009 will ship with a 2.6.30 kernel. Mainly because I've been using it constantly since August last year without hiccup; also because the last few kernels (2.6.33, 2.6.34, 2.6.35) have an annoying bug/feature/omission/regression with "snd_hda_intel spurious response" in dmesg. It seems lots of people are having this problem, especially with VIA chipsets.
It doesn't cause no sound or clicks, but under heavy load the sound will skip, and having dmesg full of noise prevents real errors from appearing, like why nouveau doesn't like resume from hibernation, resuming to a garbled screen and then a hard lock up.
I'll take solace in that the mainline distros with kernels > 2.6.30 also have this sound problem, so it's not just me being stupid.

Until next time :)

No responses yet

Why we still have the point and click GUI

Jul 11 2010 Published by under FOSS, software

TechRadar have an article about "Point and click GUIs: why are we still stuck with them?", bemoaning the lack of innovation in the software interfaces we all use daily. Since the 80's computer GUIs have been based on files, taskbars, menus and windows, manipulated by a mouse and keyboard.
My defence of point and click GUIs? They are an adequate fit for the majority of computer based tasks.
You'll note the caveats adequate fit and majority in that sentence. It isn't best fit to train surgeons in keyhole surgery, or for running automated tasks or better immersion in driving or flying simulation games. It also wouldn't be practical for use with a mobile devices or single purpose machines (ATMs, information points, ticket machines etc.).

The point and click GUI with a mouse and keyboard is the best fit for what most people use their computers for; manipulating files whilst sat at a desk.

For example, imagine organising your physical photo collection. You'd collect the photos together based on a criteria like location, time, people in the photo etc. You'd then place this collection in a pile or folder, suitably labelled, adding or removing from piles as you went along, until you were happy about the collections.
This is the same as you'd do on your computer with a digital collection; select the photos you want, make a folder or open a new window, move/copy them across, label the folder and repeat until finished. Instead of physical piles of photos, you have windows with them in; instead of physically picking up the photos and moving them, you click and select with the mouse.
It's the same thought process in both instances, just executed differently.

The article mentions touch screens and the iPad specifically as better for read only use of files, and in these circumstances, I agree. However, as also mentioned in the article, touchscreens aren't good for "data input or content creation ... [or] heavy-duty desktop computing". They aren't an adequate fit for the majority of tasks. They are a specialised interface for a limited set of (mostly) well defined tasks. The point and click GUI is at least adequate for browsing the web; typing on an iPad is so bad you can get a keyboard for it.

Just as a humorous illustration, suppose the author had been talking about doors. We haven't changed the basic premise of the door in hundreds of years; they mostly require us to exert a force on one edge either via a handle or push plate, to rotate along the opposite edge on a set of pin hinges in order to move a lump of material from a hole in a wall. I mean, sure we've got alternate door types for specialised situations (sliding doors, airlocks, revolving doors) but I'm bored of pushing material out of the way.

The reason we aren't clamouring for a revolution in door design? The current design works fine, thanks.
The reason there hasn't been a revolution in UI design away from point and click GUIs? The current design works fine, thanks.

2 responses so far

Older posts »