Very nice Jedi and really can't think what I have contributed (I am usually trying to catch up to the rest of you) but thanks for the shout.  Could not agree more about the community and on a day like today where I fall behind a little I miss so much.  I also can't say enough about the work all of you have put in and what a smooth operation this all is.  I still can't recall a change in distro that caused me less pain, reconfiguration or work.  Instead of spending my time fixing things to the way I like them, I can spend my time enjoying using the distro and expanding it's functionality. Not to mention the fact that it seems like whenever I need something it is already there.  As always though I think we follow the leader and VastOne deserves another tip of the cap.

vrkalak that is very nice.  Not really a green guy but simple, clean and elegant.  Really like the conky.  I definitely need to take spend some time on eye candy.

Oh wow that is cool! I'll do this now and let you know. Ha Ha Ha -- well that turned into an extremely interesting little project.  The long and short of it is that I can use your neat little tool now to get a dmenu deb but in order to do that I had to build from scratch a dmenu.deb. Perhaps I didn't but it was the only way I could get dmenu installed on my box so apt would see it as part of the apt system.  You see I had just done a quick and dirty make clean install and then done my adjusting from there.  So when I ran dpkg-repack dmenu the system said "whachyou talkin bout Willis" I know nothing of this dmenu. 

dmenu would not build as a deb easily because ..... it doesn't come that way.  Or at least I could not find it.  So after about 100 ways that did not work I found http://stackoverflow.com/questions/8003739/is-there-a-way-to-automatically-determine-dependencies-when-setting-up-a-dpkg-co in which the answers lay. Outstanding stuff by that guy.

Anyway it created an opportunity.  I disliked the way my install was and this allowed me to build it to install dmenu and stest to where I want and I can easily add packages and scripts to the install (now that I know what I am doing) as anyone sees fit to suggest.  e.g. I built it so dmenu and stest go into /usr/bin and dmenu_run which is what matters goes into /usr/local/sbin but that is essentially trivial to adjust at this point.  I also was able to create and use any dmenu_run of my choice (although I used the one from the Arch Forum for this build).  VastOne can't thank you enough for sending me on this little errand.  I learned a lot (mostly more about how little I really know) but good stuff. 

In the end I did use your tool but after I had already done the install and had a deb.  I am attaching the one built with repack named dmenu_4.5.2_amd64.deb. It is version .2 and my initial build from source is dmenu-4.5.1.deb just to keep them straight.

Finally if anyone has read this far and is interested.  If there are dmenu tweaks that you would like to have in the Vsido version you can either pass them along to me then I can have them or follow the instructions on the link and build your own.  Fun stuff!

PS - I haven't tested the repack on my system due to time constraints, the original version kept the proper ownerships of files etc.  Both should work the same though I would expect. One more thing you might want to put a hold on dmenu so it doesn't get updated by Sid and you lose you settings.

Since I posted in the wrong thread will update this and say this issue is solved.  I was easily able to compile dmenu and it did in fact solve all the problems I was having.  The debian version that is in the repo's is very old and moving to dmenu 4.5 was discussed but never seems to have happened.  This means that the dmenu in the repo's is built on the old structure.  Not a deal killer but a lot of the goodies are unavailable as PackRat has mentioned.  The new version allows more flexibility for calls and patches.  Thanks for all the help, sorry I was a little slow on the uptick.

OK I am hijacking this  temporarily (screens look nice by the way, I really need to change my conky)

Nope, nothing special, I was trying to compile it by running config.mk and then head slapped opened it in geany/build/Make it compiled and ran sudo make clean install and it was over and done with.  Never forget I am an idiot!  Anyway thanks for the help and back to your regularly scheduled screenshots and discussions.  Pardon my interruption.

I haven't rebuilt dmenu yet VO I will later tonight and let you know but relatively positive it will resolve it.  I looked a little at the package in debian builds and the one on the suckless site and it looks like I will have to patch first to get it "debian ready" not sure if PackRat can confirm this.

PackRat I am resisting -- barely -- playing with the paths in dmenu.  It really is a world changer for me.  I don't know if I am a script kiddie but I do love my scripts and most of the stuff I use daily is stuff I wrote or modded for my needs.  I did write up something that will essentially zen a list of my scripts from a dmenu call and then give me a terminal and that is what got me started on this path as it is pretty obvious I can do all that without zenity from the actual dmenu itself with the script you posted earlier.  There is just so much cool stuff being done with dmenu it's put a hop in my step.

PackRat may disagree but the basic install is a good place to start and probably good enough.  The thing is there is just sooo much you can do as PackRat mentioned I have also seen some incredibly clever stuff.  For example there are menu's and scripts for mpd that make plait and things like that unneeded.  Even with the dmenu basic (without stest) you can call scripts that will work either in console or as needed.  All dmenu_run does is set the environment (simple way to put it) and then call dmenu as is.  As I am learning you can set all sorts of cache, history, terminal, menu, document, etc files that will give you scripts of all sorts. .eg.
#!/bin/bash

if [[ -f $HOME/.config/dmenurc ]]; then
  . $HOME/.config/dmenurc
else
  DMENU="dmenu -i"
fi

ARTIST=$( mpc ls | $DMENU )

if [[ $ARTIST == "" ]]; then
  exit 1
else
  ALBUM=$( echo -e "Play All\n$( mpc ls "$ARTIST" )" | $DMENU )

  if [[ $ALBUM == "" ]]; then
    exit 1
  else
    mpc clear
    if [[ $ALBUM == "Play All" ]]; then
      mpc add "$ARTIST"
    else
      mpc add "$ALBUM"
    fi
    mpc play
  fi
fi

exit 0
will basically call a dmenu with all your artists listed out and you can play all or selected, etc. This is just one small example.

dmenu is pretty awesome.  Dmenu run is basically the config script for dmenu.  As PackRat posted below a pretty good example.  It is installed as part of suckless_tools and on the Vsido version it is:
#!/bin/sh
exe=`dmenu_path | dmenu ${1+"$@"}` && exec $exe
As shown above it uses dmenu_path which is an executable.  There is no stest in our version from what I can tell but I can't find much out about our version or what the differences are and not sure why we are getting dmenu_path versus the stest version.  I am guessing that there has been a fork or two somewhere between the arch version and this one. I have coded up something to work around this and sort of do what I want but now curious as to what the differences are and why.  A quick check of dmenu 4.5 from the suckless site shows stest in the archive but it's not on my box and apt says dmenu is up to date.  So I am guessing I would have to uninstall dmenu and build the latest version.

I am double posting here so shoot me 

In following that thread (from PackRat) I have an issue on my box (at least).  The changes to dmenu_run include a call to stest.  Which from what I can find is not on my box.  In the posts I have read it is a standard part of dmenu.  Can anyone out there confirm for me that they have or don't have /usr/bin/stest ?  According to what I have read it is a replacement for dmenu_path

Quotedmenu_path was removed in favor of stest,

that seems to be just the arch repo/fork apt says I have the latest suckless tools.

Anyone else seen this or have a solution? 

VastOne I don't think it was specifically asked for but it would be nice to see.  Nice work as always

Good lists here, some new things to explore.  My problem is most of what I used is wrapped in a script but I do find myself using the following directly in one way or another daily or nearly so

emacs
rdiff
cdargs
bashburn
incrontab (even though I never see it, I use it to backup my work folders, music, etc. automatically)
terminator

Dizzie sorry, my post was a little confusing but PackRat somehow managed to interpret my gibberish. 

PackRat, yes that is exactly what i was after.  The problem (for me) was that when I was reading that thread I was so giddy about some of the other crazy arse stuff that I saw you could do with dmenu I skipped that post and went straight to TOYS!!!! I found it again last night and was planning on trying it today but ... thanks to your kindness I don't have to wade through all that it's right here   I love Vsido. 

Thank you both for the help.

I have been playing around with dmenu (you know reading the arch forums, stealing the stuff and then with half and idea of what I am doing trying to run things and having them explode).  Specifically I am wondering how you can get dmenu to call a script that runs in a terminal from a hot key call.  Like this SUP+S pulls up dmenu and then somescript is selected then ... crickets.  Shouldn't I be able to get the script to run or do I have to do all this in the terminal?  Very late at night for me so if this is stupid don't hammer me but did I miss in the configuration somewhere or am I off on the concept of dmenu completely?

I think wodim is a bit finicky of late.  I was playing with it from the command line and found that
wodim -devices
wodim: No such file or directory.
Cannot open SCSI driver!
For possible targets try 'wodim --devices' or 'wodim -scanbus'.
For possible transport specifiers try 'wodim dev=help'.
For IDE/ATAPI devices configuration, see the file README.ATAPI.setup from
the wodim documentation.


Scanbus obviously fails so my disk identification loop no longer works in my zen script, I hardly ever burn a cd but if I want to my script will fail .  Bashburn is prepared for this and in fact once the config file is properly setup it does all my original script did and a ton more.  Sooooooo.....as a result of this question being asked I have rediscovered bashburn and replaced my diy model with it.  Thanks to the OP for making me think through what I was doing.

My install is about a month or so old and I am using flux (if you are more recent and using i3 that would make our environments different  Gee, guess I was not really thinking through when I posted, I really need to install the latest on this box but just so busy haven't gotten to it.  I hadn't looked at dunst (or i3 for that matter), so more to learn.