[arch-projects] Two small projects
Ok, I had my break from coding last night. After having spent some eight months on the same project, I'm looking at some really small ones to scratch little itches i've developed. To be honest, I doubt anybody else would be interested, but I wanted to present the ideas. If people are interested, it means I'll put more work into it, and may affect my choice of languages. ;-) First, I've been looking for a CLI weather station. This started when I used XFCE4 for a while and it had the neat little weather applet. Now I'm using WMI. I wrote a simple script that uses PyMETAR (http://www.schwarzvogel.de/software-pymetar.shtml) to download weather, and I run this with WMI remote in my status bar. The problem with this solution is that METAR data doesn't seem to be quite as reliable as weather.com data, at least, not in my area. To that end, I found "CurseTheWeather" (http://opensource.hld.ca/trac.cgi/wiki/CurseTheWeather) an ncurses based weather app that includes a weather.com module I can use for the same script. There's another problem with this solution though, and that is that it doesn't allow me to easily get the forecast. What I want is an app that allows me to get the current weather conditions on the command line, using a formatting string very much like the format of the date command (man date). However, I ALSO want it to provide me with CLI AND GUI options to view a five day forecast. I haven't found any programs that do this. The GUI version is more important to me; I want to have current conditions on my WMI status bar, and have the forecast available in a window at the press of a key. So I'm planning on writing a script that does all this. If anybody was interested, I'd go the full mile and implement everything I just described. If nobody is interested, I'll probably skip the 'formatted like date' command and do the formatting inside the script and stuff like that. Depending on whether or not anybody is interested, I will either do this in Python, using the weather.com module from CurseTheWeather, or will do it in Groovy, writing my own Weather.com data parsing unit from scratch. I lose either way, really. I hate doing GUI work in Python. But I also hate working with XML, and weather.com data is in XML; CurseTheWeather has already taken care of messing with the XML. But I'll probably use Groovy for that unless other people are interested -- if they are, I'm sure most people would be more likely to use a Python app than Groovy one. My second mini-project is probably about a half hour's work, so lets call it a subcompact mini-project. I've noticed all good text editors allow you to access the console, either directly, or via a plugin that simulates a console within the editor. I think this is kind of dumb, I'd rather use a terminal on the side and not have it run by the editor. Keeps things neater and smaller. The only thing is, I love being able to change to the current buffer's directory. For example, in JEdit, if you use the console plugin, you can type cd ${d} to change to the open buffer's directory. If I use an xterm on the side, I can't do this. That's what I aim to fix. Here's how I propose to do it: I'll write a JEdit plugin that writes the location of the current file out to $HOME/.currentbuffer or something like that. Then all I have to do is add something like B=$(cat $HOME/.currentbuffer) to my ~/.bashrc, and I can type cd $B any time I want to go to the directory of the current buffer. So the only hard part is writing a plugin for JEdit. By hard, I mean half hour's work. ;-) Again, NOBODY is interested in this because they don't use JEdit, but I thought it might be interesting to present the idea, since some people might theoretically want to use the same idea with their chosen editor, and it would make sense to settle on a filename (ie: $HOME/.currentbuffer). More importantly, somebody may know that such a mechanism already exists, and can tell me a better way to code it for JEdit. :-) Dusty
with their chosen editor, and it would make sense to settle on a filename (ie: $HOME/.currentbuffer). More importantly, somebody may
Yeah! and then when you have two JEdit's open, they'll compete with each other over who is in $HOME/.currentbuffer! ;P Wouldn't it be better to have JEdit start an xterm within the current buffer directory? Or do you not like starting more xterms? What about using screen? You could get JEdit to start a new screen window in the current buffer directory and then ctrl-a n to it in your open, seperate xterm. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
with their chosen editor, and it would make sense to settle on a filename (ie: $HOME/.currentbuffer). More importantly, somebody may
Yeah! and then when you have two JEdit's open, they'll compete with each other over who is in $HOME/.currentbuffer! ;P
I have alias jedit='jedit -reuseview' in my ~/.bashrc, which basically means, there's only ever one JEdit running at once.
Wouldn't it be better to have JEdit start an xterm within the current buffer directory? Or do you not like starting more xterms?
That might be useful for one or two commands. I like to have one or two xterms open, tiled around the JEdit window by WMI. I generally have something going on in several directories (pushd is my best friend) in two xterms -- maybe docs in one dir, code in another, etc. So I may want to change to the buffer directory in an xterm that's already open, not open a new one. Basically, I'm finding that current editors are designed with the editor being supreme, and terminals are slaves to it. I'd much rather decouple them such that the editor is slave to xterm, or better yet, so the two can act as peers.
What about using screen? You could get JEdit to start a new screen window in the current buffer directory and then ctrl-a n to it in your open, seperate xterm.
Hmmm. That's an interesting thought. Its interesting for the working in several directoryies problem too. I haven't used screen yet, maybe its time to try. Dusty
Dusty, if you have jedit start up a screen instance, then you could also make it pass commands to the screen terminal for you. You should be able to change the working directory seamlessly in such a fashion.. If you start a screen session, you can use the following command from another terminal to pass things to it. Note: The carriage return is necessary, otherwise it just puts it on the line. screen -X stuff "cd ~ " Maybe it would be easier to have your jedit module interact with a screen session, ie..you change buffers in jedit, and it automatically sends an appropriate command to a named screen sesssion, changing its directory as needed. I don't recall offhand how to interact with a named screen session, but it is possible, and not that hard if I recall...it still uses the -X syntax, but there is another flag... On Thu, March 17, 2005 10:03 am, Dusty Phillips said:
with their chosen editor, and it would make sense to settle on a filename (ie: $HOME/.currentbuffer). More importantly, somebody may
Yeah! and then when you have two JEdit's open, they'll compete with each other over who is in $HOME/.currentbuffer! ;P
I have alias jedit='jedit -reuseview' in my ~/.bashrc, which basically means, there's only ever one JEdit running at once.
Wouldn't it be better to have JEdit start an xterm within the current buffer directory? Or do you not like starting more xterms?
That might be useful for one or two commands. I like to have one or two xterms open, tiled around the JEdit window by WMI. I generally have something going on in several directories (pushd is my best friend) in two xterms -- maybe docs in one dir, code in another, etc. So I may want to change to the buffer directory in an xterm that's already open, not open a new one.
Basically, I'm finding that current editors are designed with the editor being supreme, and terminals are slaves to it. I'd much rather decouple them such that the editor is slave to xterm, or better yet, so the two can act as peers.
What about using screen? You could get JEdit to start a new screen window in the current buffer directory and then ctrl-a n to it in your open, seperate xterm.
Hmmm. That's an interesting thought. Its interesting for the working in several directoryies problem too. I haven't used screen yet, maybe its time to try.
Maybe it would be easier to have your jedit module interact with a screen session, ie..you change buffers in jedit, and it automatically sends an appropriate command to a named screen sesssion, changing its directory as needed.
It is a thought. I've got a plugin that will do something (anything -- I could make it play a game of Go if you like...) on a buffer change. The thing is I still want to be able to access the current buffer from within basically any xterm, or possibly even a normal console, not just one specific xterm or screen session. I think I'll stick with my original plan. Got about three minutes work left for that. Gotta love these small projects! :-D No more of this 8 months on the same project crap!!! (Anybody laying odds yet on how soon it will be before I start hacking Ensmer again?) Dusty
just one specific xterm or screen session. I think I'll stick with my
You do realize that a screen session can span multiple xterms, right? -- If you understand, things are just as they are. If you do not understand, things are just as they are.
just one specific xterm or screen session. I think I'll stick with my
You do realize that a screen session can span multiple xterms, right?
yes and no... I knew that, but I forgot. ;-) I might try it later, when I get bored... for now, I've got it doing everything the way I originally planned. Almost. I ended up having to use alias cdb='cd $(cat $HOME/.currentbuffer)' instead of trying to set an envar, because I found out if I put B='$(cat $HOME/.currentbuffer) in ~/.bashrc and then ran cd $B, it wouldn't work if the contents of .currentbuffer were changed, because the command is expanded at the time .bashrc is sourced. I don't know of any way to get around this without using an alias. I thought of using single quotes around the variable declaration, but then I end up having to use eval in the shell... cdb is less work to type than cd $B anyway. :-P Later I'll play with screen. But this is enough coding for today... tomorrow I'm going to do the weather thing in groovy and SwingBuilder. Fun times fun times. Anybody try Ensmer? anybody got a $200 000 a year job lined up for an easily bored Java programmer? Dusty
anybody got a $200 000 a year job lined up for an easily bored Java
On Thu, March 17, 2005 1:53 pm, Dusty Phillips said: programmer? heh. Good luck. I would settle for 50K a year for this easily bored, out of work, programmer. Most of the jobs a java programmer would find are j2ee backend stuff, using tomcat and jakarta and jBoss. In fact, you might try http://www.jboss.org/careers I am sure they would like to hear from Mr. Java. *wink*
anybody got a $200 000 a year job lined up for an easily bored Java programmer? Try contract positions... you can start at $70k or so doing contract positions...
participants (5)
-
Aaron Griffin
-
cactus
-
Dusty Phillips
-
eli
-
Jason Chu