Archiving Our Creations, Or, Making Sure We Still Have Culture in 2050 AD

Quintillus

Restoring Civ3 Content
Moderator
Supporter
Joined
Mar 17, 2007
Messages
8,422
Location
Ohio
As many of you know, over time resources disappear, and as time goes on, more links are broken. As such, Lanzelot and I have started an effort to archive old Stories and Tales using programmatic means, since manual archiving takes enough time that comprehensive archives have not been made.

Our goal is that even if the sites (often third-party) that stories use for image hosting go down, their contents will still be available in the future via this archive. You could think of it as a Wayback Machine for Civ, in the making.

Initially, this focus is on the most popular stories that are largely intact. You can download archieved stories here.

A list of archived & restored Stories is also maintained in this thread. If you would like to get a particular Story archived/restored, you may also make suggestions in that thread.

This thread here is now dedicated to the development of the archiving tool.

Original post:

Spoiler :
As any long-term member (or many short-term members who have tried to download old mods) can tell you, one of the hazards of the sands of the time on the Internet is that links break, sites go down, and eventually what was accessible is not any more. Having been a member of CFC for more than a decade, I've seen that happen more than a few times:

  • The Great Hack of 2008, wiping out about a year's worth of CFC Uploads
  • MegaUpload going down, taking mods with it
  • AtomicGamer going down, with the same result
  • Photobucket putting up a paywall, making many images (particularly in Stories and Tales) unavailable
  • Various ImageBucket links breaking over the years
  • Various smaller sites (including personal sites hosting mods) going down

It's also true that the average age of our creations is increasing. And while there's a decent chance that graphical mods, such as unit graphics, are hosted here and still available, beyond that it's become increasingly likely over the years that any given mod or story is no longer available. For stories, I would not be at all surprised if more than half are no longer fully available; for mods the situation is probably better, but there are scores that were hosted on AtomicGamer and its affiliates.

But archiving things is hard, and takes time. So while there are a few posters, such as Ozymandias, who have done a good job with it, no one has been able to archive everything, and those who have made an effort have tended to focus on one area. It's also not sufficient just to rely on CFC being backed up (though that is important), since many resources, especially larger ones, are hosted externally.

So, largely, when an external site has gone down, we've lost content. Occasionally the original author is still here, and re-uploads it, but as I can attest to, that takes time. More often than not, they've already moved on, or don't have the time.

--------------------

I don't have a silver bullet for mods, particularly externally-hosted ones. But this week I got around to creating a program that automatically archives Stories and Tales threads, saving them - including external images - locally. I'm sure it will still need work to work with all the stories. But I wanted to post about it, to demonstrate that this sort of thing is possible. I wish I'd had the technical know-how to do this a decade ago - my approach then was manual, and not scalable even with my greater amounts of free time then. While that involved manually downloading each image and putting them together by hand, my new approach can download an entire story automatically within a few minutes (depending on the size of the story and bandwidth).

My sample is based on Lanzelot's story The Republicans go to War, which just wrapped up. You can download an archive of the first page here. The program can download all pages, but the combined size (70 MB) is too large for my e-mail's file hosting. Unzip the archive, then open StoryArchive.html. If you turn off your network after downloading, you'll find that everything still works.

My main goal is to preserve the remaining stories before another popular image-hosting site goes down. But I can also see this being useful for those who will be offline for awhile, such as on an airplane.

The code for this program is here. Not super user-friendly yet, but I want the focus to be on the archival discussion, not the tools to do so, beyond that they can be created.

The same approach can be applied to other threads, as well.

---------------------

Thinking about the long term, how many of our creations will still be available in 2050? That's farther off than the Internet is old, but based on past experience, the most likely answer is "not many." While I'm not too worried about CFC itself - there are multiple admins, Thunderfall is already much less active than he used to be, and there are enough active users to step up if need be - all bets are off for external sites. The amount of content lost over the past 10 years alone sets a poor precedent.

That's why I think a focus on preserving our past (using an approach that can also preserve our future) should be a focus. Here's what I'm thinking:

  • Tools are created to help automatically archive resources where possible
  • An external site is created for hosting archived resources. Both tool-archived resources and manually-archived ones (where tool-based archives are not possible, such as external sites having anti-bot technology) are stored there.
  • A small team of individuals administers the archive - the inactivity of any one member should not render the resources inaccessible.
  • The archive site itself is properly backed up. Hard drives are cheap these days.
  • Ideally, a process is created where CFC resources can be updated when links break, using archived versions.

The last point is rather key. A common situation is that a mod link breaks, and the first post is stuck forever linking to a broken link. Even when someone re-uploads it, their post often eventually winds up a page or two from the end, and difficult to find. With stories, the images simply disappear over time. Having some way to restore these links significantly enhances the value of both mods and stories - although this will require CFC involvement. Having mods and stories archived externally, while not as convenient, would at least provide an option if that is not possible - and some archive is necessary for reliable restoration of links.

---------

Thoughts? Anyone else interested in helping with Civ3 artifact preservation? Please feel free to link in C&C or S&T as well; I've posted this here as a central location.
 
Last edited by a moderator:
I think it's an excellent idea. Thanks a lot for the effort! (And also thanks a lot for the honor of being the first guinea pig...! So it payed off that I spent the time to dig up the lost pictures and to finish the story...)

Let me add one more point to your list of events that destroyed a significant amount of Civ3 content: the CFC forum software switch from vBulletin to Xenforo last year... Some users (including myself) lost nearly all their attachments/uploads. So even though I never used an external site for hosting my pictures, all my content was lost as well.

I have now restored the Republican story, and fortunately I was also able to find a folder with screenshots and .sav files from the Asterix story (2011) on my old laptop. So one of the next free weekends will be dedicated to restore the Asterix story as well. With your tool, it would probably have been a matter of a few minutes instead of a couple of evenings of work.

I tried to download your code, but Firefox just gave me an error message basically saying it doesn't know what to do with this kind of link, when I clicked on the download button. (I guess I first have to install this "Atlassian" thing and download with that?) But before I do that, can you tell me in what language the tool is written? I was raised on Fortran and C, but I have also done work with "modern" environments like Java and Microsoft .NET... But unfortunately no experience in those fancy new scripting languages like Python, Ruby or nodejs... If C/Java/.NET can be used in your project, I could try and help. (I have done networking and XML processing in those languages and are fairly experienced in HTTP server&client programming.)
 
I'm glad you are happy to have been the first guinea pig! And the vBulletin --> XenForo switch is a good call out. I hadn't realized that it had wiped out a lot of attachments/uploads, but I have seen various broken links and formatting errors due to it.

I still have most of my most popular story to restore as well. I've been methodical about backups locally for the past 6-7 years (inspired by losing old Civ saves), but re-uploading is definitely still a pain, and not nearly as fun as the initial writing and uploading.

I haven't put any effort into making the code consumable in a friendly way yet - it's really a proof-of-concept at this point - but it's written in Java. If you're mainly interested in how it works, this file has the majority of the code. For running it, currently the most straightforward way to download it is via this link, and then Download Repository, which will download it as a .zip file. It uses the Java-standard Apache Maven to manage its one dependency and compilation. In the current unfriendly format, the URL to download from and the output folder location are hard-coded in the src\main\java\com\ajtjp\storyarchiver\StoryArchiver.java file, and after that is updated (it's pointed to your story currently), opening a command prompt at the top level and running mvn install will compile it with the new story location. This will create a ,.jar file in a new "target" folder, which can download a story by opening a command prompt there and running java -jar StoryArchiver-1.0-SNAPSHOT.jar

For my actual development, I'm using NetBeans, which will handle the compilation and Maven aspects automagically, and Mercurial for version control (which, other than the initial check-out, can also be handled within NetBeans). It know there are still some bugs to work out; for example it currently fails roughly halfway through choxorn's The Conquests, but I played Civ3 last night instead of fixing that.

In a day or two I can put together a compiled version with non-hard-coded values and a simple graphical interface to make it more straightforward to run.

For PDF generation, I'm opening my favorite browser and using its print to PDF functionality (I also tried Microsoft's XPS format, but can't tell a difference in quality yet and the size is twice as large).
 
Java is perfect for this job. :thumbsup:

If you want to, I can add a little Swing UI as a first project to get into it.

And I think I found a pitfall: java.io.FileWriter uses the platform's default encoding -- which is Microsoft CP1252 (= ISO-Latin-1 plus a few MS-specific addons like the Euro-sign €) on probably all of our Windows machines. However, the html pages here at CFC are encoded in UTF-8. As long as the page has only ASCII characters, everything is fine, But try downloading a page with Skandinavian, French or German letters, like the current one...

"In the original SGFN-08 we replaced C3C's spelling of German towns with the correct German spelling, e.g. München, Königsberg, Nürnberg and so on."

We better replace the FileWriter with an OutputStreamWriter(new FileOutputStream("filename", "UTF-8")) or similar.
 
That would be great if you feel like it! The downloadStory method, after being made public, seems like a reasonable entry point for the UI to call to kick off the program.

Good call-out with the FileWriter. That might explain some quirks I was seeing with the converted output of Chronicles of the Philosopher Kings VI: The Final Battle.

I have once again played a few more turns of Civ (and been distracted by the news) over adding more code.
 
Ok, I got started: installed Maven, JDK 1.8 and Eclipse on my home PC, and "mvn install" creates the shapshot.jar as expected.

However, running it via "java -jar xxx.jar" fails with the error message "no main manifest attribute in xxx.jar". Looks like the manifest file does not include the name of the class that contains the main() method. I've never used Maven before, so don't know how to instruct Maven to include that attribute in the manifest when creating the jar archive. Perhaps you can help out here?

Running the program via "java -cp xxx.jar com.ajtjp.storyarchiver.StoryArchiver" works ok, though. So I'm using that for now.

Once I have something useful, how do I check the code back in? Do I have to install Mercurial for that?
 
Another problem: when I debug the program in Eclipse, I always get "java.net.SocketTimeoutException: Read timeout" in line 105:
Document doc = Jsoup.connect(url).get();

The URL is still "https://forums.civfanatics.com/threads/pax-romana.88714/", and when I try to open that URL in Firefox, it loads in less than a second!
I have already deactivated my Windows Firewall just in case it may be blocking outbound connections from javaw.exe, but to on avail.

Update: never mind, the problem went away after a while?!? Do I need to understand that...?

Ok, I'm all set now to start coding and debugging! Enough for today...
 
You are right that I was missing the main class setting in the Maven configuration. I have now added that. I also added a lot of documentation comments, including pointing out things that are known to not be very smooth yet (for example, downloading a story will freeze the user interface until some refactoring is done).

Mercurial is needed for checking code back in. I usually use TortoiseHG if I'm not using the built-in IDE tools.

I'm not sure about the Read timout issue. At work, we sometimes have proxy issues when using Eclipse, but I've always thought that was due to the corporate firewall. I'm afraid I don't know why the problem went away, though.

I have updated the code on BitBucket with the pom.xml fixes, some refactoring, and a drastic amount of comments to get it closer to where I'd hope it would be in terms of being convenient for someone else to figure out. I would recommend updating the code (ideally, checking it out with Mercurial to make sure that works) before really starting on the UI; in particular some of the refactorings are designed to give it a better interface for downloading, so it could be called from a UI like:

StoryArchiver archiver = new StoryArchiver("https://forums.civfanatics.com/thre...-sure-we-still-have-culture-in-2050-ad.634540", "D:/Story Archiver Thread/", "Thread.html");
archiver.downloadStory();

There is still currently an issue where the .jar file doesn't contain JSoup and thus can't download, which I plan to look at later (I have things going on this afternoon), but it should be working well in an IDE.

Edit: For write access to the repo, I'll need to either add you to it (with an e-mail address), or you'd need to fork it and submit a pull request. I'm also open to the possibility of using Git or GitHub if you have a preference; I just tend to default to the current setup for my personal projects as I like Atlassian's tools and find Mercurial a bit easier to use. But I've also never had a personal project with a collaborator before.
 
I did two fixes so far:
  • Switching result pages to UTF-8.
  • If a thread consists of only one page, the program exits with a NullPointer in String page = pageNav.attr("data-page");
    (the Element pageNav is null, if there is only one page in the thread.)
I'll try checking out your updated version with Mercurial now, merging my two changes into that version and then checking it back in. That should be a good exercise for me to make sure I'm ready to go.

The read timeout hasn't occurred anymore since then. Probably some strange quirk with my firewall settings, e.g the firewall took some time before it was "really" deactivated...?!


PS: another question: I tried using Mercurial now, but it looks like something went wrong. After executing
hg clone https://bitbucket.org/QuintillusCFC/storyarchiver storyarchiver
it created two directories, both of which contain the StoryArchiver.java and Utils.java source files:
src\main\java\com\ajtjp\storyarchiver\
src\main\java\com\civfanatics\storyarchiver\
 
Last edited:
Edit: For write access to the repo, I'll need to either add you to it (with an e-mail address), or you'd need to fork it and submit a pull request. I'm also open to the possibility of using Git or GitHub if you have a preference;

I now signed up on bitbucket.org. My username: LanzelotCFC
And please no Git...;) I learned to hate it, when we had to use it for 2 years for a new project...
 
Added!

It's funny how we all have tools that we don't like using at all. For me, it's IBM's development tools, specifically their web server (WebSphere), and their customized version of Eclipse, RAD. They're both notably inferior to open-source alternatives, but the web server is particularly bad due to requiring manual configuration through a GUI on every machine, which can be very tedious and error-prone on large projects.

The civfanatics directory is the correct one. I renamed it to that this afternoon, since it's a CFC-centric project rather than a general personal project, but I forgot to remove the old directory in Mercurial. That is now done, so an hg pull should delete the duplicate one.

The changes sound good! I hadn't considered the lack of page navigation in one-page threads (so many of the stories are long).
 
I made a change to make the image downloads more resilient; in particular they will no longer cause the program to stop if an image is hosted on a site which no longer exists.

But more interestingly, I created a web site to host the (sometimes large) archives. After all, the utility is fairly limited if no one can access the archives in a few years when more image sites go down. Making it more accessible also provides a motivation boost. For now the site is extremely basic, but serves the purpose of being essentially a listing of the first few stories:

http://178.128.224.40/

I haven't bought a domain name for it yet; I'm thinking maybe civarchive.net? Could go with .com or .org as well.

Long term it would be nice to have things like sortability, ease of finding other stories by the same author, tags (to make it easy to find Always War or Demigod stories, for example), and so forth. But, beyond the necessity of being able to host the large files somewhere (and preferably somewhere that isn't also at risk of disappearing without notice), I think focusing on getting more stories archived should be a focus prior to making the website look like it was written more recently than 1994.

Technical details: Right now it's hosted on DigitalOcean in Canada, with 25 GB of space and 1 TB of transfer bandwidth per month. I went with it largely because I already have servers there, and it's enough space for now. Longer term, the 25 GB may well not be enough, and the 1 TB bandwidth might not be either. I've bookmarked a few other options to potentially address those. Hosthatch has an inexpensive option with 250 GB of space (HDD instead of SSD, but that should be fine), with the same bandwidth. Scaleway has a few inexpensive options with 50-100 GB of space, and with bandwidth limited at a Mbps rate instead of a total amount per month - at rates (200 Mbps) that work out to be much higher than 1 TB per month. And if we really wind up needing a lot of space or bandwidth, there are hosting options called seedboxes that are targeted at hosting BitTorrent downloads, such as Linux distro mirrors, but would work well for hosting a large archive as well, as they generally have lots of space and bandwidth for a low cost, at the tradeoff of CPU, memory, and flexibility.

This would also be a great use for the 3 TB hard drive I recently bought, but the upload bandwidth from my place is only 5 Mbps. Oh well. I'll keep a copy of everything locally too (and an automatic backup of the local copy) just in case there are ever any server issues.
 
I've now merged my changes into your new version, but when running it in Eclipse, cl.getResource("css.css"); returns null?!
If I copy the two css files from the "resources" folder into the "java" folder, it runs fine.

What will happen, if both of us make a change at the same time? I've been using Perforce for the last 20 years, and it handles the "concurrent change situation" extremely well. I just get a notice that the file has been changed by someone else, since I last synced it, can then merge the two versions with the click of a button and submit the merged version. (When we were forced to use Git, we invariably lost either our own work, or the other guys work, and sometimes even both of our work... Cost us days and days of redoing already finished work or trying to recover lost versions, etc. In the end we used our blackboard on the wall as a "lock table" to make sure no two persons would touch the same file at the same time... But even then Git found ways to throw a wrench into our gears, to make us shoot ourselves in the foot, and then laugh at us. :mad: In my eyes Git is completely non-intuitive and unstable. But I digress...)

Anyway, if you can give me some instructions on how best to handle this situation with Mercurial, it would be much appreciated. I have the feeling, that your change "to make the image downloads more resilient" came after I pulled the sources yesterday evening, and I don't feel like manually merging my changes into the sources yet again...
 
Hmm, I'm not sure, I'm comfortable with this yet...
Ok, I noticed that your last commit was 6h ago, and I had done a pull&update afterwards to get the deletion of the duplicates. So I was sure to have the latest version and decided to check in now.

First I tried "hg push". It said (I translate from German in the following):
Looking for changes...
No changes found.


So I thought, perhaps I have to tell hg first, which file I changed and tried "hg add src\main\java\com\civfanatics\storyarchiver\StoryArchiver.java". It said:
...\StoryArchiver.java is already versioned

Then I tried "hg commit", it asked me to add my bitbucket user to the config file and then popped up a window for the commit message, but otherwise it did nothing and said nothing...
"hg status" and "hg diff" aren't very helpful either:

D:\Sprachen\Java\sources\storyarchiver>hg status
? src\main\java\.classpath
? src\main\java\.project
? src\main\java\com\civfanatics\storyarchiver\StoryArchiver.class
? src\main\java\com\civfanatics\storyarchiver\Utils.class
? src\main\java\css.css
? src\main\java\css2.css


Why doesn't it list the pom.xml and the resources folder??

D:\Sprachen\Java\sources\storyarchiver>hg diff

D:\Sprachen\Java\sources\storyarchiver>


Please help... ;)
 
Ok, another "hg push" finally did the trick. My commit is now visible on bitbucket.

Unfortunately it reverted your try-catch around the getHttpConnection() ...! :wallbash:
Sorry for that! I hope you can fix it? (I'm afraid of only making it worse, if I try... This starts reminding me of my time with Git... :backstab:)

Edit: ok, I fixed it myself. Wasn't too hard. But still I don`t know, why it let me do it...
 
Last edited:
I think it looks good. Other than a curly-bracy that moved up a line, I don't see anything unintentional when comparing what I had and the latest commit.

The ? files for hg status means that they are not versioned. Which, other than perhaps the src/main/java/css.css and css2 files, is okay, as they're all compiled or IDE-specific files. I can add them to the ignore list so they won't show up in hg status all the time.

The workflow that I've found tends to work best for synchronizing remote changes (which in my previous experience with hg has always meant from my desktop to my laptop or vice-versa) is to first make sure all your changes are committed, and then do an hg pull. This should fetch all the remote changes and integrate them (but if you haven't committed your changes, it will put them in a temporary branch that needs to be merged in with your local... this is probably my least-favorite part of Mercurial. Hence why I try to always make sure I don't have uncommitted changes when doing a pull). Then, if the changes can't be merged automatically, a manual merge can be performed. Finally, an hg push should push your changes to BitBucket.

However, I'm wondering if it might not make more sense to use branches. The idea being, if you create a branch (using hg branch), you can work on a piece of functionality until it's ready, push that branch, create a pull request from this page (https://bitbucket.org/QuintillusCFC/storyarchiver/pull-requests/), and then BitBucket will guide you or I through the process of resolving any conflicts needed to put it into the main branch. In essence, by working in a branch that no one else is working in, it avoids the risk of conflicts due to me working in the same area, until you are done and the code is already on BitBucket, ready to be merged in. If you then wanted to work on something else, you would go back to default with hg branch default, and could then create a second branch from default for the new changes (or you could create a branch off of the first branch, if your next changes depended on the previous ones). At some point, to fetch either my changes or your changes merged into default, you would want to hg branch default, and do an hg pull, to have an updated default branch.

On the whole I suspect that would reduce the amount of merge pain, since neither of us would be making changes on the same branch at the same time. When conflicts did arise, they would be visible on BitBucket in the pull request system, and we could both go over them and make sure things look okay before taking action.

I've never used Perforce, but have had experience with changes being overwritten by other developers. In my past experience, Subversion was the worst for that, but I've had it happen with Git as well. And admittedly, Mercurial is somewhat similar to Git, though I found the learning curve to be less steep. I think most of the times code was overwritten, what wound up happening was that there was a conflict due to working on the same branch, and someone tried to resolve it without fully understanding what the other developer's changes were, and also with somewhat unintuitive tools (I know the Eclipse Subversion merge tool that the other developers on my project used did a poor job of highlighting differences and didn't make it easy to see the big picture of what had changed). And particularly if the developer didn't do a diff of what they had changed at the end, wiping out someone else's code could go undetected. By using separate branches, not only will we not step on each others' feet directly, but when we do have to merge branches in and there are conflicts, we'll have a nice UI visible to both of us that makes it easy to see what changed, and thus to notice if it's showing something changed that we didn't intend to change.

I will have to look at the cl.getResource("css.css") thing. Unfortunately I don't know of a good way to generalize loading a resource from inside a JAR and from a compiled development version at the same time, and it's entirely possible that Eclipse and NetBeans use slightly different classpath settings, so the program expects the CSS files to be in a different place for each one. But having one copy in src/main/java and another in src/main/resources isn't the end of the world, since these will most likely not change in the future, and seems like an acceptable work-around for now.

Edit: Went ahead and created a branch for a small change I hadn't pushed yet; the pull request is here. It adds a less verbose console output option. But as importantly, it demonstrates the process, and shows the convenient diff view. In this case there are no conflicts, but if they were we could see them from that view as well.
 
Last edited:
Re Perforce: in the 20 years I've been using it, I haven't experienced one single case where someone's change got accidentally overwritten. And on some of the projects we've been working in teams of 10. I think this says something about the intuitivity and foolproofness of the system... :D
In the project where we used Git, not a week went by, where not someone either lost his local (not yet submitted) changes due to "backfired pull", or overwrote his colleagues' changes in the depot due to a "backfired push/merge"... Our impression was that instead of helping the developer with the daily tasks of code revision and instead of keeping him from committing stupid mistakes, Git just let us shoot ourselves (and each other...) in the foot, and afterwards laughed at us...
It's a different philosophy and I guess it depends on what you are used to. Git seems to think in terms of "branches" and "features", while Perforce thinks in terms of "files" and "changes to these files".

I don't have much free time at the moment, so for now I'd like to keep things as simple as possible and concentrate on the code instead of on the tools. I've created a new file that contains the necessary GUI classes, and I won't need to touch the StoryArchiver.java file for a while. Once I'm satisfied with the UI, I'll just add the new file to the project, and then we can switch the main class in the pom.xml.

Also I'd like to spend some more time on making myself familiar with that jsoup library. That seems to be a very powerful tool for HTML processing indeed! I'm really impressed how with just a few lines of code you managed to parse these complicated thread pages here at CFC!
 
It sounds like it may indeed be a case of different philosophies. It's fairly accurate to say that Git thinks in terms of branches, which are often used for features. Git also very much has a philosophy of being flexible, in a Unix sense. Like you can combine a bunch of Unix commands do to powerful things, so can you do the same thing with Git commands. The tradeoff being, unsurprisingly, in complexity, learning curve, and ability to make mistakes when new to it. Some may take the number of upvotes on Git questions on Stack Overflow as a sign of its popularity; to me it seems that (while it is popular) the number of questions with thousands of upvotes more indicates the difficulty of learning it. Mercurial's general philosophy is similar, but it tacks a bit more towards having refined tools than having flexible tools.

But there's enough complexity (and in general I also prefer to focus on the code) that I'm certainly not an expert on either one. I can usually untangle messes that my team finds, but every so often am still stumped and have to call in a real expert or find a relevant post on the Git mailing list. It sounds like given your team's record with Perforce, perhaps it is worth the cost if it can avoid the time sink (and occasional defect-due-to-deleted-code) that can occur with other version control systems.

I like the GUI focus idea. I'm particularly curious to see how someone else's Swing GUI looks; I don't use many Swing UIs that I didn't build myself these days.

JSoup is a pretty cool library. It basically lets you use JQuery and CSS style selectors, but within a Java ecosystem and thus with access to all the other options that entails, including saving results to disk. I first used it about 4 years ago on a work project, and I've continued using it since then on both personal and work projects.

I've uploaded another parsed story, SirPleb deity with Palace rank exploit. That one went smoothly. Like Bamspeedy's game, my progress was drastically slowed by reading the thread. Technically it's in the HOF forum rather than Stories and Tales, but it's certainly worth preserving.

I'm also thinking it may be a good idea to separate a "development" thread and a "results" thread.
 
I'm particularly curious to see how someone else's Swing GUI looks

Don't expect too much... I'm neither a GUI programmer in general, nor a Swing guru in particular. Last time I used Swing was in 2006. (So I'm rather using this project to get back into it a bit...)

Anyway, if you want to take a look at a first crude UI, you can start it with
java -cp SNAPSHOT.jar com.civfanatics.storyarchiver.ArchiverUI

(java -jar will still run the original StoryArchiver.main() method.)


Strangely enough, it just prints the "Success!" message from copyCssFiles, creates an empty html file and then does nothing, when run as jar. In the IDE it works perfectly.
But too late now to figure out what's wrong when running from the jar...
 
Well, it looks perfectly good enough to me! I particularly appreciate that the progress bar is already functional. The SwingWorker and slight updates to the StoryArchiver class are a good way to get that working without the UI being frozen.

I made a minor fix to accomodate avatars for usernames which contain characters that aren't valid for file names, and have added World War I... in 2051 A.D.!?!? to the list of archived threads.

Also realized that Geocities is another site that was used for image hosting by some stories... that brings me back a ways, and makes me wonder whatever happened with the Geocities archive.
 
Top Bottom