a custom epiphany location bar

since i do much research on the internets, i often find myself in a web browser. my favourite of the lot is epiphany. this post isn’t about its merits or failures, but about the awesome way to make my location bar be exactly how i like it: monospaced.

just add the following into your ~/.gtkrc-2.0 file and then restart epiphany. feel free to modify as you wish.

# ~/.gtkrc-2.0
style "Epiphany_Locationbar" {
# leave out the font size if you wish
font_name = "Monospace 12"
#bg[NORMAL] = "#ff0000"

# both of these seem to work...
#widget "*.EphyLocationEntry.*" style "Epiphany_Locationbar"
widget_class "*.EphyLocationEntry.*" style "Epiphany_Locationbar"

thanks to raphael for the original post, and the #epiphany developers.

getopt vs. optparse vs. argparse

sooner or later you’ll end up needing to do some argument parsing. the foolish end up writing their own yucky parser that ends up having a big if statement filled with things like:

if len(sys.argv) > 1

in it. don’t do this unless you have a really good excuse.

sooner or later, someone directs you to getopt, and you happily continue on with buggy manual parsing thinking you’ve “found the way“. useful in some circumstances, but should generally be avoided.

since you’re a good student, you read the docs, and one chapter later, you find out about optparse. higher level parsing! alright! the library that we all wanted to write, actually exists, and it seems to follow some ideals too. this i actually appreciate, and it is lovely to use. you dream about all programs using this common library and unifying the world. consistency is a dream.

you then remember that the positional syntax of cp, git, man, and friends actually does makes sense, and you’d like for them not to change. you go on with life, hacking up optparse when needed. everything is pretty good, and you’re a seasoned coder by now, but sooner or later, someone sets you straight with a nice blog post like this.

there’s a new kid in town, and it’s called argparse. you read the docs, and you promise yourself to use standard argument styles. subparsers, and types finally exist in a sensible way. you love the inheritance schemes, and you’re one step away from being able to complete your parsing code, but you still haven’t found that magic place in the manual that hides the precious answer you need. and now you have (probably the fourth code block down from that link- maybe also the fifth). why this way buried in with the api specs, i don’t know, but i’m glad it was there.

thanks to ivan for getting me to check out argparse in the first place.