Wow, sorry to be away. I hadn't noticed the activity, and I wouldn't want that to be interpretted as losing interest.
I've prepared this reply to sort out some of the confusion my previous post may have caused, and to help further flesh out the ideas I have in mind-- they'll benefit from your thinking as well.
First, I should say that I've downloaded your beta version and kicked the tires, thanks for compiling and sharing!
I had requested a "programmatic re-labeling," as it were-- not to the window, rather to the "Stay Productive" legend. I certainly value being urged to stay productive, but I think we can put that area of screen real estate to clever use!
If you'll indulge me, let's step back for a moment, and I'll show you the power I already see in Regalink, and what I'm driving at. Hopefully, it's a place you want to go!
I mentioned that "other programs may create URL.txt files," and that's why they need to be named on the command line. I say that because there's LOTS of ways to end up with a collection of URLs you want to visit. You could, for example, save a file from your browser's bookmarks. Or, you could screen scrape a page on the web. Or the results of a query, or... you get the idea. In fact, I see the world like this:
That's OK, Regalink doesn't really care where its input file came from, as long as it's syntactically correct. That's a beautiful thing, and it becomes the underpinning of my other requests...
Consider the commandline execution I requested. Those lines might look something like this:
Those would hopefully execute 3 instances of Regalink, like these:
This would be VERY powerful in terms of general desktop integration. You might remember my earlier note regarding "not caring if the URL is on the web, or local to the machine (that is, a file execution)..." Given these capabilities (and I think they are very close to your grasp), you could envision a future where while you sleep, some process gathers up or makes decisions on what URLs you should visit, and then pops up a Regalink window, properly named, with links and commands in a nice ordered list.
Personally, I think the date and time stamping may ultimately not be worth too much fuss, but certainly succinct display is warranted. 99.99% of the time, I'm sure that the "year" or "tenths-of-seconds" are not going to be needed. I would suggest that the information might not really be needed in its entirety, but I admit I could be shortsighted on this count.
Lastly then, let's consider the file format for the "URL.txt" file. Consider this file:
; OK, let's pretend that this is the contents of URL.txt
; First, some nomenclature. Look at the first character in each of the following lines:
; This is a "comment" indicator in URL.txt Simply skip the line when reading in.
# This is a "heading" line. When read, the list on screen has some heading displayed.
% This is a "separator" of some sort in URL.txt. When read, the list on screen has some separator displayed.
; These can be quite useful. At a minimum, it allows us to embed comments in URL.txt that might be useful
; to us, especially if we're generating URL.txt programmatically. For example, we might note these facts:
; The following URLs were gathered by a perl script munging an RSS feed (myHappyPerlScript.pl)
; The intended use is opening in Regalink.
; Since we're still pretending, consider this:
# Political Blogs
# Food Blogs
# Music Blogs
Maybe, just maybe, there's a way that such a file could look like this:
Now, I admit, this is all vapor at the moment, but you're really not that far away, and this is much more like the napkin I'd be drawing on if we were seated opposite each other at the pub, and turning over ideas on what this software could be.
Let me come up for air, then, and ask what you think, and which bits might be the next easiest to knock out? Great journeys are taken in small steps, after all.
Cheers, and thanks for your efforts!