Dmenu and scripts

[statmonkey]

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.

[VastOne]

@statmonkey, thanks for that update

I would like you to do something for me and at the same time show the power of a package on VSIDO that not many users know about... 

First, is this package you build called dmenu? If that is the case simply run this from terminal

Code Select Expand

sudo dpkg-repack dmenu

This will package the exact build you just made into a debian deb file... please upload that file to me somewhere and I can use it as the source for the new ISO's and will not have to build it myself

[statmonkey]

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

Code Select Expand

make clean install and then done my adjusting from there.  So when I ran

Code Select Expand

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.

[VastOne]

Wow... excellent perseverance statmonkey!  Well done, and I am sure you have learned a few more things!

Thank you for the time and effort in sorting this out... this is the type of help I am always looking for and makes me very proud that users are willing to invest the time and effort that will help every one.

Great job!   

Sorry for the long delay, I have a major tournament this weekend and I am spending as much time as I can to practice for it... I will install this tonight and if all testing goes well I may release the ISO later tonight or tomorrow sometime

[statmonkey]

No worries.  I haven't seen any issues but let me know.  Really no thanks nec. I enjoyed it, really enjoyed it.  Now that I know this pretty well I am trying to resist the temptation to start forking every debian app with a bugaboo that drives me nuts (like mpd and the root crap it does) 

I have been buried the last few days as well but do want to research the dmenu add ons and see if there is anything useful.  The xft stuff for example might be worth having in as standard.  I am using fluxbox but there might be things the other wm's use that could/should be here.

Slight issue - not sure why yet but it seems that dmenu-run needs help when called from a key combo.  It has to do with interactive/non-interactive shell but I thought stest would cover that.  Starting to wonder if I need to include dmenu-path in the install to make this a little more flexible.  It seems wasteful but ... another method would be to call dmenu_run the first time from the cli, this would initialize the dmenu_cache according to .profile and .bashrc but that requires user knowledge that should be avoidable.  Sorry, guess I am thinking out loud here.

[statmonkey]

Sorry for the double post.

I just noticed that when I did a fresh install it is still installing the sucklesstools version of dmenu and not the individual deb version.  This means that dmenu_run is the older version and doesn't install stest.  In order for dmenu with stest allowing all the latest features to work you will need to remove sucklesstools using apt then install the dmenu deb from this thread.  If you want the other suckless tools they will have to be installed individually.  I am working on rebuilding a package that will give you all the latest suckless tools and dmenu4.5+ in one go.  I am a little busy at the moment but hope to get it done in the next day or so.  I'll then pass that along as a more proper fix.  So now I will add a sorry that I missed that when I passed this upstream.  In my defense I was so giddy at resolve dmenu and getting that together I completely forgot the part about sucklesstools and the debian sid repo's impact on this.

[VastOne]

No worries statmonkey, this is all a never ending process...

That is what makes it so much fun!   

[statmonkey]

Thanks VastOne, sending you a pm on this

[statmonkey]

VastOne asked me to summarize what is different about the latest Dmenu and Suckless-Tools I put together for Vsido and I suppose summarize why it was done.  The Debian version of Suckless-Tools 39.1 remains behind the actual dmenu in both structure and options.  So, I built a new dmenu and repackaged suckless-tools essentially giving Vsido our own custom version.  In the latest version 39.1.1 the following has been done:

• Replaced dmenu 4.4.1 with dmenu 4.5, this version uses stest and is much faster and more efficient.
  The Debian dev has moved dmenu and dmenu_run to a different folder, I moved them back to /usr/local/bin for consistency with where suckless-tools originally put them.
  Added xft support so that you can use xft fonts
  Removed dmenu_path since it is no longer used
  Added dmenu_select which is a nice user script that allows you to run scripts/etc from dmenu in a terminal and remembers what programs you did this with

The only local adjustments that might be needed would be to add a full path to the dmenu_run script.  I find it useful because I use my download folder and a project folder for testing and add those paths.  The other thing is to put suckless-tools on hold to keep this from being over written.  I will add a write up on at least part of how I did this and maybe each of the three major parts to it, someone might find this interesting.  I don't use i3 and know that you guys use dmenu a lot.  If anyone has anything they would like to see included in this package in the future let me know I would be happy to include it.

[VastOne]

^ Very nice statmonkey...

I have added your deb to your message...

I really appreciate this work and your commitment to seeing it through, well done!   

[statmonkey]

This is like my own private thread 

Anyway, the maintainer and I have been exchanging emails and he will be releasing a new version of dmenu soon that will incorporate most if not all of the changes I suggested so it looks like my developer days are over. LOL. Anyway for consistency purposes he won't be including the two scripts that I did and I am attaching them here if anyone wants them. 
dmenuselect allows you to open apps or scripts in terminal and remembers what you chose last time
todo adds a nice vertical todo list with the ability to remove what you accomplished.  I find both pretty useful.

[VastOne]

^ This is your personal ChangeLog.... 

Well done getting your work to the developer and convincing him it is needed...

Thanks for this statmonkey!

[statmonkey]

I appreciate your thanks but let's not over state my role in this.  I learned a lot that's a fact and I think the maintainer was headed there anyway I just pushed him a tad.  The important thing is we all get a better dmenu out of the deal and perhaps gained the knowledge that despite my rudimentary skills anyone can contribute. Actually that is more of a reminder to me than anything else and I really need to share more than I have been.  Also reminding you VastOne that had you not given me the initial push here I wouldn't have done a thing.

[statmonkey]

Sorry, I have been out of the loop for a while with some project work.  I had this path issue resolved in my last build of dmenu so not sure what version you were running PackRat but I will take a look at it.  The default dmenu and suckless tools I built should source the path from the $USER .bashrc.  That being said I saw that Vasudev (the dev for dmenu) released a new version moving dmenu to the /usr/bin location and including dmenu-path in the build with stest.  I am not sure at the moment what the reason for this is but will contact him and ask.  I will also play a little.  I don't think it will work that way (dmenu should only call one or the other not both), but theoretically if both stest an dmenu-path are called you should be able to adjust the sourcing in dmenu-path.  Anyway, if you do an update and were using to Vsido dmenu you hot/keys etc will probably not work and there may be other consequences. 

[VastOne]

I saw that update from the dev come in today...

Hopefully your schedule lets you back to some normalcy!

Cheers!