Commits

jjacky committed 976bee6

new post

Comments (0)

Files changed (7)

0019 - dapper 0.1.2 released.markdown

+As I explained before, I don't use a session manager, and when I needed something to take care of handling the autostart of Desktop applications for me, and couldn't find anything what I wanted, [I made dapper](http://mywaytoarch.tumblr.com/post/24191680769/dapper-a-desktop-applications-autostarter "dapper, a desktop applications autostarter").
+
+Until now it only followed the FreeDesktop specifications, that is started things according to `.desktop` files found in user & system autostart folders. In that order, in fact.
+
+Version 0.1.2 now works differently, introducing options allowing you to decide which folders should be processed :
+
+`--system-dirs` to process system (*XDG_CONFIG_DIRS*) autostart folders
+
+`--user-dir` to process user (*XDG_CONFIG_HOME*) autostart folder
+
+`--extra-dir PATH` to process the specified _PATH_ (not an autostart subfolder)
+
+Bonus: process will happen in the same order the options were specified.
+
+This turns out to be pretty useful to me, because I really don't like to have thing autostarted when I open a new session, I like things to stay fast & clean.
+
+(So I'm all for pulse or the PolicyKit agent to be started, but not much else, for instance. That's done with a clean `~/.config/autostart` and `dapper -su` on session openning)
+
+However, I do start a few of the same applications every single time : web browser, file manager, e-mail reader, kalu, etc
+
+So now, I just made myself a new folder (`~/.local/autostart`) where I put symlinks to `.desktop` files of those very applications. And when I want to start it all, instead of doing it manually for each of them, I just start `dapper -e ~/.local/autostart` and voilà!
+
+_Note: dapper doesn't actually resolve the tilde (~) to your home folder. That is if you were, as I did, to create a `.desktop` file to start this in a single click on a menu item, make sure to specify the full actual path, e.g: `dapper -e /home/jjacky/.local/autostart`_
+
+Also worth mentionning a few bugs have been fixed, notably dapper would crash if the config file couldn't be opened, or a folder to be processed did not exist (fixed in 0.1.1); and parsing fields was actually quite buggy/not working (fixed in 0.1.2).
+
+### Download
+
+dapper is released under GNU GPL v3+ The source code is available on [this BitBucket repository](https://bitbucket.org/jjacky/dapper "dapper @ BitBucket.org"), where the issue tracker welcomes bugs/suggestions.
+
+The release tarball can be downloaded here; and Arch Linux users can use [the PKGBUILD in the AUR](https://aur.archlinux.org/packages.php?ID=59681 "AUR: dapper").

0019 - kalu now usable from CLI (1.1.0 released).markdown

-A new version of kalu - [upgrade notifier for Arch Linux](http://mywaytoarch.tumblr.com/post/19350380240/keep-arch-linux-up-to-date-with-kalu "Keep Arch Linux Up-to-date with kalu") - has been released.
-
-Two main changes with this version. Firstly, the addition of two command-line options - `--manual-checks` (`-m`) and `--auto-checks` (`-a`) - to **run manual/auto checks from command line**. No GUI will be used at all, everything gets printed on stderr/stdout (using the same templates as for notifications).
-
-This can be done without the need for a DISPLAY/running X server (i.e. no GTK init performed), thus **works from a tty or through SSH**. This can also be useful to use kalu from scripts.
-
-Alongside those options is a _configure_ option (`--disable-gui`) to make kalu a small CLI-only binary (i.e. no dependency to GTK nor libnotify), which could be useful on GUIless box (e.g. servers), where kalu can then still be used to check for upgrades, watched packages, etc
-
-(Running this CLI kalu without arguments will do the same as using `--manual-checks`)
-
-
-And then, there were improvments & fixes on the news parser, mainly with **support for links**. As expected, links will now be in blue & underlined, the URL available as tooltip, and clicking it will open it in your default browser.
-
-Opening the URL is actually done via `xdg-open` Although I just realized, right after uploading the new version to the AUR in fact, that this wasn't really the best way to go.
-
-A better solution than hardcoding the use of xdg-open would be to introduce a new option, and that's what I did. The code is already done, though it's not in this version. But next version will also use xdg-open by default, but let you change it to whatever replacement you use, or even your web browser directly. Up to you.
-
-_(So if you don't have `xdg-utils` on your system and don't want to install it just for kalu, but want to be able to click on links, you can download the code from the repo (branch default) and you'll then have the option available (under Misc).)_
-
-### Downloads and whatnot
-
-Thanks to all those who reported bugs or suggested features.
-
-**kalu** is released under GNU GPL v3+ The source code is available on [this BitBucket repository](https://bitbucket.org/jjacky/kalu "kalu @ BitBucket.org"), where bugs/suggestions can be added to the issue tracker.
-
-The release tarball can be downloaded [here](https://bitbucket.org/jjacky/kalu/downloads/kalu-1.1.0.tar.gz); You can also find [a PKGBUILD in the AUR](https://aur.archlinux.org/packages.php?ID=56673 "AUR: kalu").
-
-And of course, as always, new bug reports, suggestions or any other form of constructive criticism is very much welcome.

0020 - A couple of plugins for WeeChat.markdown

-When I moved to Linux, I looked for an IRC client. Originally, I wanted/looked for a GUI one, probably because coming from Windows I'm used to GUI applications.
-
-Soon enough it looked like I wouldn't be able to find a client that would fit my needs, so I tried CLI clients, and eventually found [WeeChat](http://www.weechat.org/ "WeeChat, the extensible chat client."). It's a great client, does lots of things by itself, but also has scripting support to extend things even further.
-
-Still, as I started to use it more and more, there were a few things I needed that I couldn't find scripts for. Probably, the easiest way to add them would have been to write such a script, either in perl, python, or any of the other languages supported by WeeChat.
-
-Instead, I went with C plugins. The only reason, to be fair, is that I don't know anything about any of the (many) script languages supported by WeeChat, while I had been doing some C for a little while. So it was easier/faster _for me_ to do so, is all.
-
-### weenick: Provides support for common NickServ operations
-
-First of all, since I use registered nicks of a few networks, I wanted to be identified automatically. This could be done by a simple command triggered upon connection, but I also wanted that on reconnection the command to kill the ghost, the change of nick & do the identification all be done without me having to do anything. Laziness is strong with me. :)
-
-weenick should handle all of that, and you can also define command(s) to be executed once identified.
-
-It is configured through options under `var.plugins.weenick.server_default.SETTING` for "global" values, which will be used (as fallback) on all servers. You can also define options under `var.plugins.server.SERVER.SETTING` for settings to be used on server SERVER only.
-
-The options are :
-
-- `nick` : your (registered) nickname. When defined, weenick will try to use that nick upon connection (in case WeeChat used another one). If the nick is already in use, killing the ghost will be triggered.
-
-- `password` : your password, to identify/kill ghost with services
-
-- `command` : command(s) to get processed upon identification
-
-- `nickserv_nick` : nickname to send messages to. Default: _NickServ_
-
-- `nickserv_registered` : string to identify notice that nick is registered Default: _nickname is registered_
-
-- `nickserv_ghost_killed` : string to identify notice that ghost was killed Default: _ghost with your nick has been killed_
-
-- `nickserv_identified` : string to identify notice that nick was identified Default: _password accepted_
-
-- `nickserv_failed` : string to identify notice that password is wrong Default: _access denied_
-
-The `nickserv_*` options are there because not all servers uses the same strings for each case (starting with servers in another language than English, I guess).
-
-(Of course, a match must happen in a NOTICE from NickServ (or whatever is specified as `nickserv_nick`) for it to be effective.)
-
-Going over this, I realized the actual commands to kill ghost or identify are hard-coded, which probably isn't the best. Hopefully all services use the same, specifically: `/msg <nickserv> GHOST <nick> <password>` and `/msg <nickserv> IDENTIFY <password>`
-
-(Registering your nick with services is all up to you, btw.)
-
-### weereact: Triggers commands in reaction to messages
-
-Another thing I was after, was a way to have commands be triggered automatically in reaction to something that was said in a channel. Sort of a bot-like behavior, if you will.
-
-weereact will allow to do just that: you can define "triggers" that will filter messages, and trigger the specified command(s) for each match.
-
-Messages can be filtered by server, channel, user and content (through perl-compatible regular expression).
-
-All configuration must be done in file `weereact.conf` in WeeChat's working directory (e.g. `~/.weechat`). There's no interface, you need to manually edit the file in your favorite editor, and can use the `/reload` command to have weereact reload its config from the file.
-
-Syntax in that file is pretty basic: Empty lines and lines starting with # are ignored; otherwise the format is simply: `key=value`
-
-To start a new trigger definition, use the following on a new line: `[]`
-
-Options (keys) can be used to filter on which messages should the actions be triggered, as well as define said actions.
-
-- `on` : name of the server the message must be sent on
-
-- `to` : name of the channel (with #) or nick for PMs. For PMs send to yourself/you're receiving, use: `to=-`
-
-- `by` : name of the sender of the message. For messages you're sending, use: `by=-`
-
-- `is` : [perl-compatible regex](http://developer.gnome.org/glib/2.30/glib-regex-syntax.html "Regular expression syntax") to filter the message.
-
-- `do` : command to be executed when a message matches. You can specify this option as many as times as you need.
-In addition to the back-references from the regex in `is`, you can also use the following variables:
-- `$on` : name of the server
-- `$to` : name of the #channel/nick the message is sent to
-- `$by` : name of the sender (only available if you're not sending the message)
-
-#### New command: /tobuffer
-
-One last thing this plugin does, is introduce a new command - `/tobuffer` - which can be used to send text (or commands) to a specific buffer.
-
-It's very possible you don't need it for most things, since you can e.g. specify a server & channel with `/msg` for instance, but I needed to send text/command to plugin buffers (i.e. not IRC channel/privates).
-
-Also, I'm not sure there's a way, from such a command, to do a `/me does nothing` Although you wouldn't need to use `/tobuffer` for that, if that needed to happen in the channel/private where the original message occured, as by default all text/commands sent by weereact are done to the buffer of the original message, IOW in the same channel/private as the original message.
-
-### Downloads and whatnot
-
-**weeplugins** is released under GNU GPL v3+ The source code is available on [this BitBucket repository](https://bitbucket.org/jjacky/weeplugins "weeplugins @ BitBucket.org"), where bugs/suggestions can be added to the issue tracker.
-
-Arch Linux users can also use the [PKGBUILD in the AUR](https://aur.archlinux.org/packages.php?ID=62366 "AUR: weeplugins"), which grabs the latest code from the GIT repo.
-
-And of course, as always, new bug reports, suggestions or any other form of constructive criticism is very much welcome.

0020 - kalu now usable from CLI (1.1.0 released).markdown

+A new version of kalu - [upgrade notifier for Arch Linux](http://mywaytoarch.tumblr.com/post/19350380240/keep-arch-linux-up-to-date-with-kalu "Keep Arch Linux Up-to-date with kalu") - has been released.
+
+Two main changes with this version. Firstly, the addition of two command-line options - `--manual-checks` (`-m`) and `--auto-checks` (`-a`) - to **run manual/auto checks from command line**. No GUI will be used at all, everything gets printed on stderr/stdout (using the same templates as for notifications).
+
+This can be done without the need for a DISPLAY/running X server (i.e. no GTK init performed), thus **works from a tty or through SSH**. This can also be useful to use kalu from scripts.
+
+Alongside those options is a _configure_ option (`--disable-gui`) to make kalu a small CLI-only binary (i.e. no dependency to GTK nor libnotify), which could be useful on GUIless box (e.g. servers), where kalu can then still be used to check for upgrades, watched packages, etc
+
+(Running this CLI kalu without arguments will do the same as using `--manual-checks`)
+
+
+And then, there were improvments & fixes on the news parser, mainly with **support for links**. As expected, links will now be in blue & underlined, the URL available as tooltip, and clicking it will open it in your default browser.
+
+Opening the URL is actually done via `xdg-open` Although I just realized, right after uploading the new version to the AUR in fact, that this wasn't really the best way to go.
+
+A better solution than hardcoding the use of xdg-open would be to introduce a new option, and that's what I did. The code is already done, though it's not in this version. But next version will also use xdg-open by default, but let you change it to whatever replacement you use, or even your web browser directly. Up to you.
+
+_(So if you don't have `xdg-utils` on your system and don't want to install it just for kalu, but want to be able to click on links, you can download the code from the repo (branch default) and you'll then have the option available (under Misc).)_
+
+### Downloads and whatnot
+
+Thanks to all those who reported bugs or suggested features.
+
+**kalu** is released under GNU GPL v3+ The source code is available on [this BitBucket repository](https://bitbucket.org/jjacky/kalu "kalu @ BitBucket.org"), where bugs/suggestions can be added to the issue tracker.
+
+The release tarball can be downloaded [here](https://bitbucket.org/jjacky/kalu/downloads/kalu-1.1.0.tar.gz); You can also find [a PKGBUILD in the AUR](https://aur.archlinux.org/packages.php?ID=56673 "AUR: kalu").
+
+And of course, as always, new bug reports, suggestions or any other form of constructive criticism is very much welcome.

0021 - A couple of plugins for WeeChat.markdown

+When I moved to Linux, I looked for an IRC client. Originally, I wanted/looked for a GUI one, probably because coming from Windows I'm used to GUI applications.
+
+Soon enough it looked like I wouldn't be able to find a client that would fit my needs, so I tried CLI clients, and eventually found [WeeChat](http://www.weechat.org/ "WeeChat, the extensible chat client."). It's a great client, does lots of things by itself, but also has scripting support to extend things even further.
+
+Still, as I started to use it more and more, there were a few things I needed that I couldn't find scripts for. Probably, the easiest way to add them would have been to write such a script, either in perl, python, or any of the other languages supported by WeeChat.
+
+Instead, I went with C plugins. The only reason, to be fair, is that I don't know anything about any of the (many) script languages supported by WeeChat, while I had been doing some C for a little while. So it was easier/faster _for me_ to do so, is all.
+
+### weenick: Provides support for common NickServ operations
+
+First of all, since I use registered nicks of a few networks, I wanted to be identified automatically. This could be done by a simple command triggered upon connection, but I also wanted that on reconnection the command to kill the ghost, the change of nick & do the identification all be done without me having to do anything. Laziness is strong with me. :)
+
+weenick should handle all of that, and you can also define command(s) to be executed once identified.
+
+It is configured through options under `var.plugins.weenick.server_default.SETTING` for "global" values, which will be used (as fallback) on all servers. You can also define options under `var.plugins.server.SERVER.SETTING` for settings to be used on server SERVER only.
+
+The options are :
+
+- `nick` : your (registered) nickname. When defined, weenick will try to use that nick upon connection (in case WeeChat used another one). If the nick is already in use, killing the ghost will be triggered.
+
+- `password` : your password, to identify/kill ghost with services
+
+- `command` : command(s) to get processed upon identification
+
+- `nickserv_nick` : nickname to send messages to. Default: _NickServ_
+
+- `nickserv_registered` : string to identify notice that nick is registered Default: _nickname is registered_
+
+- `nickserv_ghost_killed` : string to identify notice that ghost was killed Default: _ghost with your nick has been killed_
+
+- `nickserv_identified` : string to identify notice that nick was identified Default: _password accepted_
+
+- `nickserv_failed` : string to identify notice that password is wrong Default: _access denied_
+
+The `nickserv_*` options are there because not all servers uses the same strings for each case (starting with servers in another language than English, I guess).
+
+(Of course, a match must happen in a NOTICE from NickServ (or whatever is specified as `nickserv_nick`) for it to be effective.)
+
+Going over this, I realized the actual commands to kill ghost or identify are hard-coded, which probably isn't the best. Hopefully all services use the same, specifically: `/msg <nickserv> GHOST <nick> <password>` and `/msg <nickserv> IDENTIFY <password>`
+
+(Registering your nick with services is all up to you, btw.)
+
+### weereact: Triggers commands in reaction to messages
+
+Another thing I was after, was a way to have commands be triggered automatically in reaction to something that was said in a channel. Sort of a bot-like behavior, if you will.
+
+weereact will allow to do just that: you can define "triggers" that will filter messages, and trigger the specified command(s) for each match.
+
+Messages can be filtered by server, channel, user and content (through perl-compatible regular expression).
+
+All configuration must be done in file `weereact.conf` in WeeChat's working directory (e.g. `~/.weechat`). There's no interface, you need to manually edit the file in your favorite editor, and can use the `/reload` command to have weereact reload its config from the file.
+
+Syntax in that file is pretty basic: Empty lines and lines starting with # are ignored; otherwise the format is simply: `key=value`
+
+To start a new trigger definition, use the following on a new line: `[]`
+
+Options (keys) can be used to filter on which messages should the actions be triggered, as well as define said actions.
+
+- `on` : name of the server the message must be sent on
+
+- `to` : name of the channel (with #) or nick for PMs. For PMs send to yourself/you're receiving, use: `to=-`
+
+- `by` : name of the sender of the message. For messages you're sending, use: `by=-`
+
+- `is` : [perl-compatible regex](http://developer.gnome.org/glib/2.30/glib-regex-syntax.html "Regular expression syntax") to filter the message.
+
+- `do` : command to be executed when a message matches. You can specify this option as many as times as you need.
+In addition to the back-references from the regex in `is`, you can also use the following variables:
+- `$on` : name of the server
+- `$to` : name of the #channel/nick the message is sent to
+- `$by` : name of the sender (only available if you're not sending the message)
+
+#### New command: /tobuffer
+
+One last thing this plugin does, is introduce a new command - `/tobuffer` - which can be used to send text (or commands) to a specific buffer.
+
+It's very possible you don't need it for most things, since you can e.g. specify a server & channel with `/msg` for instance, but I needed to send text/command to plugin buffers (i.e. not IRC channel/privates).
+
+Also, I'm not sure there's a way, from such a command, to do a `/me does nothing` Although you wouldn't need to use `/tobuffer` for that, if that needed to happen in the channel/private where the original message occured, as by default all text/commands sent by weereact are done to the buffer of the original message, IOW in the same channel/private as the original message.
+
+### Downloads and whatnot
+
+**weeplugins** is released under GNU GPL v3+ The source code is available on [this BitBucket repository](https://bitbucket.org/jjacky/weeplugins "weeplugins @ BitBucket.org"), where bugs/suggestions can be added to the issue tracker.
+
+Arch Linux users can also use the [PKGBUILD in the AUR](https://aur.archlinux.org/packages.php?ID=62366 "AUR: weeplugins"), which grabs the latest code from the GIT repo.
+
+And of course, as always, new bug reports, suggestions or any other form of constructive criticism is very much welcome.

0022 - How to convert a mercurial repo to git.markdown

+When I started working on a few things, and needed to use some version control, I used mercurial. This wasn't really something I thought about all that much: I had used subversion & mercurial before (back on Windows) without problems, whereas with git the few times I had to use it (e.g. to try things quickly, or clone a repo) things weren't as smooth (to me, that is).
+
+Admittedly I never bothered looking into git then, and so mercurial was an obvious "choice" when I needed to use a VCS. Just like [bitbucket](https://bitbucket.org/jjacky "jjacky @ BitBucket") was obvious for the same reason (it's probably the best hosting solution with mercurial support).
+
+But the Linux ecosystem loves git, they're both quite close historically, and lately I decided to actually looked into git. I'm still not done with all the reading, but already I like it a lot.
+
+It can do a lot, so far I understand & like how things work, and I therefore decided to move. Which means, I'll have to convert my mercurial repos into git ones; starting with [kalu](http://mywaytoarch.tumblr.com/post/19350380240/keep-arch-linux-up-to-date-with-kalu "Keep Arch Linux Up-to-date with kalu").
+
+### The right tool for the job
+
+There are many possible solutions to do the conversion. I tried a few :
+
+- First I used the [hg-git](http://hg-git.github.com/ "Hg-Git Mercurial Plugin") plugin. It gives hg the ability to pull to and push from a Git server. Simple enough, however I wasn't entirely satisfied with the results.
+(I don't remember exactly why, but it had to do with tags being lightweight, maybe also missing branches...)
+
+- I then tried [hg2git](https://github.com/antono/hg2git "Mercurial to Git converter"), but the results weren't satisfying. Tags were still lightweight, which I was hoping to find a way around, and my branches had all (but master) been renamed "branch-xx"
+
+- Finally, I looked at [fast-export](http://repo.or.cz/w/fast-export.git "mercurial to git converter using git-fast-import"), which gave me the most satisfying results.
+
+The convertion itself is easy enough to do:
+
+	git clone git://repo.or.cz/fast-export.git .
+	rm -rf .git .gitignore
+	git init
+	./hg-fast-export.sh -r /path/to/hg/repo
+	git clean -f # remove fast-export files
+
+_Note: On Arch Linux, python 3 is the default, so you need to edit `hg-fast-export.sh` to add a 2: `PYTHON=${PYTHON:-python2}`_
+
+However, things still weren't perfect. Tags were still lightweight, and my history was a bit of a mess. Though I believe this is my fault, due to the way things were done in hg.
+
+I'm not sure if I just created this mess, or if it is due to the fact that branches work quite differently in git that they do in mercurial, but the end result is the same.
+
+**I ended up with two parallel branches in the history** : _master_, where daily commits were done, and _stable_, where things were merged and tags done. This seemed alright at the time, but not anymore.
+
+Because **I wanted to have a "cleaner" (more linear) history in git**, and one where all tags could be seen from the branch _master_. The branch _stable_ should in fact just be in the same history line, only lower up until things are deemed stable and it gets fast-forwarded (and a tag is added).
+
+So, even though I don't know any python, I started looking at the source code, to see if I could help "improve" things a bit.
+
+### Let's hack fast-export a bit
+
+Lucky enough, things looked pretty simple & straight forward, and I was able to make a few adjustements.
+
+As I said, I don't know python so expect things to be ugly. And those are probably quite specific to my needs, and might not be applicable as-is to any other repo.
+
+#### Create annotated tags
+
+Tags were not annotated, even though **in mercurial every time a tag is created, we have a commit** (that updates the `.hgtags` file). fast-export was smart enough to ignore this file, since it's completely useless in git, but still kept those (empty) commits.
+
+I decided to change things, to ignore those commits (again, they were empty/useless in git, even more so without the `.hgtags` file around) and instead use their info (date, author...) to create the annotated tags.
+
+Should be noted that I didn't make sure this would always work, and it's probably not ideal for a very large repo. But for the small one that I was working on, it worked fine.
+
+Every time a commit is added, we check to see if it's tagged. If so, **the next commit will be "ignored", and instead the annotated tag will be created**. As mentionned, the commit author becomes the tagger, we re-use the date as well, and I forced the commit message to "_Add tag for version &lt;tag&gt;_" since all my tags are version number, and the original commit message was about the same, only referencing a mercurial changeset which, here, meant nothing.
+
+It was also needed to adjust the marks used, to not reference the commit we didn't import but the one before (i.e. the one tagged) instead.
+
+#### Avoid the unnecessary history branch
+
+One problem remained: at one point I had created a new branch (stable), where tags for stable versions would be done. As described earlier, this resulted in a "messy" history, with **two parallel branches of commits in the history** : one with the actual work/commits being done, and one where things were merged, and tagged.
+
+This looked bad, but because I had consistently done it the same way, it was easy enough to fix it. It always went like so :
+
+- commit 1 : [master] some work
+- commit 2 : [stable, tagged] merge latest
+- commit 3 : [stable] add tag (to commit 2)
+- commit 4 : [master] more work
+
+So all I had to do was, when dealing with a commit being the result of a merge, check if it was tagged. If so, in addition to "ignoring" commit 3 (and using its info for the annotated tag), simply have the tag applied to commit 1 instead of commit 2.
+
+This worked well, and while all the "commit 2-s" were still being added to git, they would all go away since their branch wasn't used in any way. I only had to manually delete the branch stable to make it all proper, and then re-create it pointing to the right commit (last tagged one).
+
+And with that, **I ended up with a "clean", linear history in git**. Success!
+
+### kalu is now using GIT
+
+Now kalu is now using [a git repo](https://github.com/jjk-jacky/kalu "kalu @ GitHub") (with a nice linear history), hosted on github. And for those interested/curious, [my fork of fast-export](https://github.com/jjk-jacky/fast-export "jjk-jacky/fast-export on GitHub") is also available on github, in branch [annotated-tags](https://github.com/jjk-jacky/fast-export/compare/master...annotated-tags "Compare branches master and annotated-tags").

dapper 0.1.2 released.markdown

-As I explained before, I don't use a session manager, and when I needed something to take care of handling the autostart of Desktop applications for me, and couldn't find anything what I wanted, [I made dapper](http://mywaytoarch.tumblr.com/post/24191680769/dapper-a-desktop-applications-autostarter "dapper, a desktop applications autostarter").
-
-Until now it only followed the FreeDesktop specifications, that is started things according to `.desktop` files found in user & system autostart folders. In that order, in fact.
-
-Version 0.1.2 now works differently, introducing options allowing you to decide which folders should be processed :
-
-`--system-dirs` to process system (*XDG_CONFIG_DIRS*) autostart folders
-
-`--user-dir` to process user (*XDG_CONFIG_HOME*) autostart folder
-
-`--extra-dir PATH` to process the specified _PATH_ (not an autostart subfolder)
-
-Bonus: process will happen in the same order the options were specified.
-
-This turns out to be pretty useful to me, because I really don't like to have thing autostarted when I open a new session, I like things to stay fast & clean.
-
-(So I'm all for pulse or the PolicyKit agent to be started, but not much else, for instance. That's done with a clean `~/.config/autostart` and `dapper -su` on session openning)
-
-However, I do start a few of the same applications every single time : web browser, file manager, e-mail reader, kalu, etc
-
-So now, I just made myself a new folder (`~/.local/autostart`) where I put symlinks to `.desktop` files of those very applications. And when I want to start it all, instead of doing it manually for each of them, I just start `dapper -e ~/.local/autostart` and voilà!
-
-_Note: dapper doesn't actually resolve the tilde (~) to your home folder. That is if you were, as I did, to create a `.desktop` file to start this in a single click on a menu item, make sure to specify the full actual path, e.g: `dapper -e /home/jjacky/.local/autostart`_
-
-Also worth mentionning a few bugs have been fixed, notably dapper would crash if the config file couldn't be opened, or a folder to be processed did not exist (fixed in 0.1.1); and parsing fields was actually quite buggy/not working (fixed in 0.1.2).
-
-### Download
-
-dapper is released under GNU GPL v3+ The source code is available on [this BitBucket repository](https://bitbucket.org/jjacky/dapper "dapper @ BitBucket.org"), where the issue tracker welcomes bugs/suggestions.
-
-The release tarball can be downloaded here; and Arch Linux users can use [the PKGBUILD in the AUR](https://aur.archlinux.org/packages.php?ID=59681 "AUR: dapper").