Halberd - Actors, Part 2

At the end of last month, Halberd's current iteration had its first birthday. I think that makes this my longest and most successful attempt so far! As I mentioned in my original post about Halberd, this has been a recurring project, something that I wanted to do for years but never managed to complete. Seeing a milestone like this is pretty nice!

That's enough celebrating though, it's time for dialogue.

Dialogue

As you might guess by when this is coming out, I missed my mark by about a week. Between taxes, a birthday, and a pixel art collab, I put a few too many tasks on my plate and the date slipped. I finished the feature, but then some health problems kept me from actually posting for a while.

It's been done for a while though! Dialogue trees can be displayed via trigger, and can have test boxes, choices, and even call triggers mid-dialogue. This obviously helps a lot on the storytelling end of things, making a coherent plot that lacks dialogue isn't easy.

The Editor

Right now, the dialogue editor is pretty bare-bones. It's just a property grid wrapped around a dialogue tree, with no special checks or previewing. As always though, the important thing is that it just works. Like all of Halberd's editors, I'll be making multiple polish passes over time to improve usability.

She's a fixer-upper

I think this is a good moment to also remind everyone reading this: This is the gain I was expecting to get from the propertygrid. Being able to will functioning simple asset editors into existence with next to no effort is what made the months of work worth doing. From now on, these basic 'propertygrid editors' are probably going to show up a lot when adding new features due to how fast they are to produce.

Frame Job

Another thing that you probably noticed in that video is the UI. There are still a couple of bugs to work out, but the system's in place and it's now possible to make a much nicer-looking interface.

The main goal that I was working towards with the UI was full layout customization, but right now it's restricted to just skinning the frames around various elements. It's a pretty standard '9-slice' setup, without any fancy bells and whistles, but it works.

Next Up Is...

Something different. I'm going to be changing gears a little, so that will wait for its own post.

Singularity: It's the Little Things

It's been a few weeks since I wrote about some of my old mistakes working on Singularity, and I think it's time for a little follow-up. I've implemented all of the changes that I mentioned (and they work), so I'll be discussing two "smaller" features that I've been working on and what I've learned by working on them.

Look, Ma, no Feedback!

One big problem that I've had in this new version of Singularity is how opaque it is about everything. Before I started working on it again, there was no way to see if any feeds failed to load, or where feeds pointed to. As a result, a feed could go down and silently fail for months while you were none the wiser! Since I'd identified this problem before I started work again, I was already planning to do something about it. To keep things simple, I'm just making the text in the feed sidebar stand out more for now.

So that's the first piece of this puzzle. However, there remains one big problem: What do you do when you know a feed doesn't load? I knew that I had a large number of broken feeds, but without somewhere to see the url it would be difficult to know if the feed had moved or been deleted, or if it was just a parser error.

I'm still mulling over the best solution to the problem. For the moment, I've created a properties page for feeds that contains info like the title and url. This works fine, although it could still use some polish. Another feature that I'm considering is an 'update status' indicator that could display detailed update progress and error messages. Either way, it's clear that Singularity needs to provide more feedback when things fail.

Lesson Learned: Detailed feedback can be very important, and not just as polish!

Getting Organi--Wait, Wrong Series

I'm nearly done with a new feature that, apparently, is one of the most important things to add. When I started rewriting Singularity a while back, I wanted to add folder-like entries to the sidebar so that users could organize their feeds. This seemed like more of a "would be nice" feature than an absolutely vital one, so it was left in a half-finished state.

Boy, was I wrong with this one. I decided to dedicate the weekend to finishing the feature, and it turns out to be a complete game-changer. I didn't expect it to be important, because I mostly just checked my feeds via the 'All Feeds' view. However, I had my logic backwards. I was checking the 'All Feeds' view because there was no other way, not out of preference. I figured this out after sorting all of my feeds into collections, and seeing a result like this:

In the left image, you know nothing other than the fact that there are 3 unread items of some description. What are they? How long will it take to read them? Do I care right now? The program has no answer for you, because the feeds with new items are hiding under 100 others. Even if they were at the top, you could have 30 feeds with one update each. Instead of hunting around, the most obvious solution is always just to click 'All Feeds' and read through everything.

The picture on the right gives much more info. Right off the bat, you know that 3 of the new updates are news articles. If you're about to head out then you probably don't want to check them yet, and you don't have to. It suddenly makes a lot of sense to check the categories that interest you, and leave the stuff you don't want to check for later. I'm glad to have this new feature, but I'm kicking myself over how many months I suffered without it.

Now that it actually makes sense to check things that aren't 'All Feeds', I've also added a small quality-of-life feature: Item views now display the feed/collection that they correspond to. It's a minor thing, but it's nice to have.

Lesson Learned: Just because the user always does something doesn't mean that it's the only way they ever will. Some habits may be a result of weak design.

Conclusion

For the first time in quite a while, I feel happy and optimistic regarding Singularity's future. My last rewrite ending halfway put me in a spot where I was unhappy with the result, but the polish and new features feel like a much-needed breath of fresh air. My goal of a new release by the year's end is starting to look much more realistic!

DFGame: Glade-ing Along to Victory

I planned to take a break from DFGame, but I happened to be in the mood to play around with the editor module. I ran into some issues while working on a new demo, and ended up having to do a few hours of research to get things working. Then I thought to myself: "Gee, someone else is bound to have this problem. Maybe I should write about it!"

What's New?

Sometime last year, I learned how about this cool feature in Vala, and started using the Glade UI editor with my software projects. However, it was only recently that I learned about a way to add custom widgets (such as DFGame's editor widgets) to Glade for graphical editing. Naturally, I had to give this a shot for the new and improved DFGame!

Let's discuss what went wrong, and how I solved these problems.

Problem 1: Nothing Happens?

It took quite a while for me to actually get any new UI elements to appear in Glade. There were a couple issues that caused this, primarily thanks to the documentation being rather vague about about how templates work... at least until you notice the tiny "next" button. Let's look at the example widget catalog that the documentation shows:

<glade-catalog name="foo" library="foo" depends="gtk+">
  <init-function>my_catalog_init</init-function>

  <glade-widget-classes>
    <glade-widget-class name="FooFrobnicator" generic-name="frobnicator" title="Frobnicator"/>

    ... widget classes go here
  </glade-widget-classes>

  <glade-widget-group name="foo" title="Foo">
    <glade-widget-class-ref name="FooFrobnicator"/>
    ... widget class references go here
  </glade-widget-group>

  ... widget groups go here
</glade-catalog>

(Borrowed from this page)

The difference between "name", "generic-name", and "title" isn't immediately obvious. If you look at a later page, there is an explanation:

• "name" is the name of the widget's class in code. It also seems to be used for class references in widget groups later in the file
• "generic-name" is used internally, I guess? Still not 100% sure on that one
• "title" is what the user will actually see in Glade

Unfortunately, this still wasn't enough because there remained an underlying problem to address: I write my Gtk code in Vala, but Glade only cares about GObject C. For the unacquainted, Vala acts as a wrapper language of sorts, and gets converted to GObject C for compilation. This means that there are two more things to adjust:

First of all, the class names are different. C lacks namespaces, so in order to provide them Vala adds each namespace onto every class that you create. In my case, this meant changing "Viewport" to DFGameViewport.

Next, there's a less obvious issue. Vala generates something referred to as a "get type function" which does something? I assume it either returns something that represents the object's type, or it returns an instance, but I don't have enough experience with GObject to know for certain. Glade overrides this function to create placeholders, but it apparently guesses the function name based on the "name" value that's passed in. In my case, I had to pass in the function name explicitly in order to make the catalog work. This is probably just a quirk in Vala's naming conventions, I suppose.

Once that was out of the way, Glade finally displayed my new viewport widget for DFGame and all was well, right?

Problem 2: Nope, That Doesn't Exist

As any seasoned programmer will tell you, life is never simple.
The fixes above were enough to let me create the UI for a new demo, but once the time came to actually test it out the UI wouldn't load! Instead, I was left with a cryptic message:

"(demo_editor:24355): Gtk-CRITICAL **: Error building template class 'MainWindow' for an instance of type 'MainWindow': .:3:4733 Invalid type function 'df_game_viewport_get_type'"

...???????!!?!??!??!?!!!??!!?!
The class was there. I could see it in the code. The library was definitely getting linked. So why then did it fail? Given a good couple hours, I was unable to answer this question. Luckily, the internet came through for me. All I had to do was slip in a single line of code at the start of the program

typeof(Viewport).ensure();

...and that was enough.

Takeaways

 This little experience further cements my thoughts regarding Gtk and many GNOME technologies, and I thought I'd discuss that briefly before as this post wraps up.

I like working with Gtk, Vala, and so on, but I think many of these technologies share the same problem. At the same time as GNOME works to streamline the design of its software and simplify things for normal users and new devs, there's this weird dropoff point where most docs past the beginner tutorials assume that you understand the technology stack and just need a quick reference.

The result is (presumably) "intermediate" devs like myself getting lost and confused after their gentle start suddenly drops out from under them. Thankfully, I ran into most of those issues a couple years ago, but occurrences like this one remind me that they still exist.

So I guess today's lesson is...maybe I should try writing a couple mid-level Vala/Gtk tutorials? Maybe GNOME needs more acknowledgement of their newer users and non-C APIs? Beats me.

Halberd Update 4 - Watch this!

It's been too long since my last Halberd update, but rest assured: I've been hard at work.

The Asset Registry

The registry can automatically tell when an asset has been changed outside the editor, and can prompt the user for more information.

I was been aware for a while that if I didn't create some method for handling assets and their relationships with each other, I was going to be in a world of hurt later. Over break, I spent a lot of time considering my options and came up with the asset registry.
The asset registry is a special container that records assets and assigns numerical IDs to them. The engine can report changes to the locations/names of registered assets, and the registry will change accordingly. Then, assets that depend on them can refer to them with their ID, and never have to worry about moves or deletions. Whenever you make some sort of connection between an asset and another, the depended asset is automatically registered (unless it exists in the registry, in which case the ID is returned). This makes managing assets extremely simple and straightforward.

New Editors

Adding a reference to an asset is quite simple, thanks to my generic asset-selection widget

For a long time, I've had to make most assets by writing config files, DFEngine style. This is a horribly slow, boring, and imprecise way to actually produce a game, so I've started making views in the editor for designing and editing various game objects. So far, I've finished the first pass on the Actor editor and I've started on the Sprite editor. I've got a lot of work on my plate, so progress here has been a bit slow.

I've also added a tile selection pane to the map editor. Not only can you choose specific tiles to place, you can also add new tilesets to a map and save them into the map file as well! I made this before the asset registry, so it needs some adjustments in order to fall in line with the rest of the asset editors. The tile selector is also a bit slow sometimes. I'll need to look into this in the future.

The Logging System

One thing that I've wanted in my engines for a while is a better way to log information and errors. After taking some time to work out logging in Halberd, I think I have a decent system. Using variadic macros, I've made logging fuinctions that can take arguments in the same way that printf can. This alone is a huge boon, as far as getting information goes. On top of that, I've added a simple way to add a callback function for logging. I'm not using any at the moment, but once I get the chance I'll be adding popups for error messages and a logging window to search, filter, and examine messages from the editor.

DFGame

Of course, what real good is such a nice log, if I can only use it for a single project? As I mentioned in my 2015 retrospective, I want to have a few basic libraries to make development simpler. I've started work on DFGame, a game engine utility library, and so far I'm happy with the results. Much of my resource handling and logging code has been added already, and I'll be adding much more in the near future.

By doing this, I've been able to rip several files straight out of Halberd and into DFGame, which has the added benefit of making Halberd's codebase just a tad smaller and simpler. I'm hoping that in a couple of months I'll have enough in there to give me an easy jumpstart on any new game projects.

Let's talk about engine architecture

In my last post, I might have said some thing about "getting back to making games". As you can clearly see, I've yet to do anything of the sort. In fact, I've now missed the Global Game Jam for the second year in a row, which was a tad disappointing. In fact, I couldn't blame you if you were to think "What gives, Hugues? What on earth are you doing?"

Now I could just say that I've been swamped with schoolwork, and I wouldn't be wrong, but that's not a very honest answer. In truth I am..... *drum roll* .....rewriting DFEngine. Yes, again.
I know what you're thinking, and I know rewrites aren't usually worth doing and waste lots of time and resources, but I think this one's a bit different from my usual follies. To explain why, though, I'll need to give a bit of background.

On the subject of Software Architecture

When designing software, most devs like to throw around the word architecture around a lot. But what is architecture, in the context of software development? The meaning is much closer to its origins than you might think. To sum it up neatly, software architecture refers to the general layout and structure of the code. This is a higher-level concept, meaning that it deals more with the overarching design rather than the specifics of each implementation. In other words, the architecture is the frame that any given program is built around.

If your architecture is bad, you might not necessarily notice or care at first. Your program will run fine, and it'll do what you want. However, the problems will begin to emerge as you try to expand and maintain your code. It's a little like building a house where the foundation and supports aren't well placed: Just because it doesn't immediately turn into a pile of toothpicks doesn't mean it's safe, as you'll realize when you start building an extension to it. If an application's architecture is well designed from start to finish, then fixing bugs and adding new features is much simpler.

There is a way to fix bad architecture, at least in theory. Through a process called refactoring, you can move around and rewrite smaller sections of code to match a new design without breaking existing features. It's still a difficult and time-consuming process, but it's generally way simpler than a full rewrite. However, refactoring is only at its most effective as a preventative measure, where you fix the problems before they become serious. The goal is to gradually make things run smoother, not turn the entire structure upside-down.

Back to DFEngine

As you might have already guessed, the current design of DFEngine was not well put together. It has some kind of structure, unlike the abomination that was AMAZE's original engine, but it's inherently flawed in several ways. To return to the house-building metaphor, AMAZE's engine is a pile of rotten planks and rusty nails that someone has arranged in a vaguely shelter-like fashion, and current DFEngine is a house that looks okay on the outside but secretly violates about 13 different safety regulations. You could go in and try to sort things out, but the problems are so deep-rooted that it may be cheaper just to demolish it and make a new one. I'm still at a point in DFEngine's development where I can afford to do that, so I think it's the wisest decision. After all, if the engine already has issues and it's not even finished yet, things will no doubt only get worse from here. On top of that, I had several game ideas floating around that required certain features that simply didn't exist in DFEngine, and wouldn't have fit with the existing structure of the code.

So far, things have been going fairly well. It's been a slow process, because I am loathe to make the same mistake twice in a row, but things are pretty solid so far. I would post some screenshots, but I haven't finished the rendering code yet so there won't be much to show for a few weeks.

Next time, I'll talk about the new engine and how it works.

Singularity Version 0.2 Released

 If you've been following this blog recently, then you'll know that I finished off the newest version of Singularity last week! If you're interested in messing around with it, you can download the source codefor the release here. That said, if you're just looking for a feed reader, then you should probably wait for the next release. This set of updates brings major stability improvements, and adds a number of 'must have' features, but still lacks some of the polish and smaller features that you'll find in other applications.

Now that I've got that out of the way, here's a quick rundown of what got added in this version:

• Added support for downloadable attachments.
• If there's room, multiple items can sit on the same row.
• Additional work is no longer required to get Singularity running properly once it is installed.
•  Added a 'Welcome Screen' that appears when your database is empty, prompting you to subscribe to some feeds.
• Singularity can now periodically check your subscriptions for updates while running.
• You can also manually tell Singularity to check for updates.
• Added settings!
• Also added a feed-specific settings pane to override application settings on certain feeds.
• Replaced the automatic clearing with a more powerful rule-based system
• e.g. "Delete read, unstarred items after 5 days",  "Star unread, unstarred items after 1 month", etc.
• Improved how command-line arguments work, making them work like they do everywhere else.
• Also added flags to display help and enable verbose output.
•  Added a 'mark all as read' menu option.
• Singularity now asks for confirmation before deleting feeds.
• Added an 'about' dialog.
• Moved the feed adding dialog to a pane.
• This addition doesn't actually change or improve anything, but it'll allow me to add some nice stuff later down the line.
• Items can now be starred/unstarred.
•  Updated the update status emblems to be higher-res.
• Fixed a ton of bugs, some of which were quite major.

So there you have it, 3 months of bug fixes and improvements. Now that the push for 0.2 is over with, I'm going to be taking a break from this project for the most part. I need to get back to making games, after all! Singularity will still be receiving occasional small fixes and improvements as necessary, of course, so it's possible that some smaller releases will be popping up from time to time.

Lastly, I should probably remind you that this is my last weekly post. As I explained here, the 'post once a week' model doesn't seem to be working out for me, and I think it's leading to worse content overall. This means that you probably won't be hearing from me as much here, but I plan on spending more time and effort writing each individual post. Hopefully, I'll eventually find a good balance. For now though, I must ask you please continue putting up with the constant changes.

Singularity Update 11

Changelog

-Moved the feed adding dialog to a pane. This doesn't do anything yet, but it'll let me do some nice things later. -Feed content is packed together a bit better now. -Blank authors/dummy dates don't show up anymore. -Items can now be starred, and starred items can now be viewed. -Singularity now actually downloads attachments when the attachment is clicked. (This uses, and thus requires, wget. I may look into an in-application solution at some point.) The old style(opening in a browser) can still be used, by changing a hidden setting in dconf. -The default location for downloads can be changed in the settings. -You can make Singularity ask for a location to download to, or have it download to the default location automatically. -Added Feed-specific settings, which can override the application settings. Currently, these only affect downloads and rules.

Somehow, I managed to finish everything off of my todo list before the New Year. It wasn't easy, seeing how I didn't do any work last week because of Christmas. 0.2 isn't quite ready for release yet, however. There are a few things that I want to test/improve still, but I think I can safely make a release within a week or two. When that happens, I'll give a rundown of all the new features, just like last time. The main new features here are things that are generally boring but required, and a few major bug fixes. This means that Singularity now has most of the necessary features for it to work nicely, but is still largely unpolished. Hopefully, 0.3 and 0.4 will feature more polishing and 'quality of life' improvements. Anyways, it'll probably be a while before I start working seriously on Singularity again. It's been far too long since I worked on games, and I have some fun stuff coming up that I can tell you about soon. Maybe I'll even get back to my tutorial soon!

Singularity Update 10

Changelog

-Command-line arguments now use more standard syntax. -Added a menu entry to mark all viewed items as read. -Singularity now asks for confirmation before deleting feeds. -Added settings for how attachments are handled, but they don't do anything yet. -Added an 'about' dialog to display information about singularity.

Well, as you can see I'm back! Unfortunately, this update is mostly full of simple, boring stuff. I wanted some lighter tasks to get myself back intothe groove of things, so I knocked off a few simple features from the v0.2 list. My original goal was to release by the end of the year, but it's hard to tell if that'll happen. Assuming I work my butt off and nothing truly awful happens, I'm probably ok, but you can never know with these things. I'm glad that my estimate was in the right general ballpark though. So far, I'm pretty happy with the progress I've made on the project, although I'll probably stop updating for a long while after 0.2 hits.

Singularity Update 8

Changelog

-Items should now be marked as read more reliably. -When you aren't subscribed to any feeds, Singularity now displays a 'Welcome Screen' that prompts you to subscribe to some. -Added a Settings pane to set userthe preferences. -Singularity can now periodically check for feed updates. You can disable this/change the interval from the settings pane. -Fixed a serious bug where feeds could end up with the same id.

Settings

Getting settings into Singularity is probably the #1 culprit for why I haven't made any updates during the past few weeks. This particular feature slowed my progress down considerably, mostly because I needed to do a ton of work to even start seeing progress. At this point the settings pane is mostly empty, and it looks awful, but the hard part is over now.

Down the Road

It's been over a month since 0.1 came out, and you might be curious as to when I'm going to release 0.2. For once, I can answer that! My current goal is to finish singularity 0.2 by New Year's Eve, and release it soon after. Last week, I layed out my goals for 0.2 on Singularity's Github page. The list is pretty long so I'm a little bit worried, but I think I can manage. My goal for 0.2 is to take the base I created with 0.1, fix some issues, and then build off of it with some of its more 'essential' missing features, like the aforementioned settings pane. Currently, it looks like 0.3 will try to make the application act nicer on other systems, as a build up for an eventual attempt at getting it provided as a package in one or two distros. We'll see about that, of course, but I'm hopeful.

Singularity Update 7

Changelog

-Added an experimental feature to make feed items fit together nicely. However, it probably won't make it into the release. -Fixed a bug where you couldn't add feeds anymore. -Made a change to the install so that it doesn't require extra work. -Moved the location of the default css and status emblems to /local/share. The default.css file in ~/.local/share/singularity will override it, letting you customize your view a bit.

A Fitting Change

This week, I tried to change the way that items are arranged. Using the css 'flexbox' feature, you can make things fit together in different ways depending on how much room they take up. The result is ok, but pretty underwhelming. Flexbox won't resize content to make it pack more efficiently, so anything containing text will take up a full row. I'll probably need to mess with this a bit more before I include it. The other issue is that the items that get packed into rows aren't all marked as read correctly. This is probably for the same reason that this issue occurs when the view scrolls too rapidly. This issue is starting to become a bit more serious, so fixing it is probably the next thing I'll get to.

The Clearing

Just the other day, old items were cleared for the first time. This was a day I feared slightly, since I wasn't sure how things would go. Considering that, I'm happy to announce that the results of that were mixed, but promising. It looks like any feed that had updated during the one-month period was correctly cleared, and nothing more occurred. Any feed that hadn't was also cleared, but then every item in it was reloaded. This is precisely what I was afraid of, but it looks like the issue might only happen on my end. I added the feeds when the feature was still a bit glitchy, so I think that's what caused the issue. Unfortunately, it's hard to say until next month comes around, and things get cleared again. If the feeds fail twice, I'll have to start testing and fixing things more aggressively. Anyway, this event reminded me that I still need to add a 'clear all' button. Hopefully I'll be getting that in before 0.2.

Singularity Update 6

Changelog

-Added basic support for RSS enclosures. -Made some improvements to the feed adding dialog.

Adding Feeds

When I released Singularity last week, you could already add feeds to the program easily enough. However, there were a number of small annoyances concerning this. Originally, I had the dialog hide itself when you did anything with the main application, but I found it to just be an annoyance. Finally, I've gotten around to letting it stick around. Additionally, the url input on the popup was accepting extra lines, resizing the dialog when when it got long urls, and just generally being a pain in the butt. This has been fixed. However, these changes are just temporary. I plan on redesigning some parts of the UI based on my own experience using the program.

Redesign?

Right now, Singularity has most of its screen space taken up by a web view. If you're trying to read some updates, this is great, but any other action renders the area completely useless. Thus, I've decided that most of the UI that was going to be put in dialog boxes is going to go there instead. That way, the space won't be wasted. I haven't tried this setup yet, but I think it'll work much better than what I'm doing right now.

Singularity 0.1 Released!

It's been almost a full month since I started rewriting Singularity, and almost a year and a half since the project was originally announced. This makes Singularity my longest running (regularly updated) project. That's partly why it's such a relief for me to announce the very first public release of the software! All of the project's source code is freely available on Github, under the GNU General Public License.

For those of you who aren't aware of what this is all about, or perhaps have forgotten, here's what this is all about:

Singularity is a simple GTK-based RSS reader. Development was started when Google first announced that Google Reader was being shut down. The project has come a long way since then, with 3 major releases(although this is the first public one), each one featuring a codebase rewrite. The first release, 1.0, was little more than a basic proof of concept. The entire app spanned only two code files, was filled with strange and arcane workarounds to simple problems, and was developed in a very short span of time. Regardless, it did its job(somehow). Afterwards, I felt the need to try and turn Singularity into a halfway decent piece of work. This led to version 1.5, released fairly soon after the 1.0 release. This version was much better than the last, and is the longest-used version so far. However, it wasn't very well designed, had a fairly large number of issues and missing features, and slowly acquired quite a bit of cruft. When I revisited the project this summer, I considered working with the code that I had. However, After spending some time reviewing it I decided it was best to get a fresh start. To that end, I rewrote the whole thing again, and even rolled the version number back to 0.1. That brings us to today. I've used 0.1 for a couple of weeks, even as development continued, and I think I can safely say that it doesn't have any massive issues. There are still bugs, and there's much more to be done, but it's a decent start.

Here's what features are in this version:

• Subscribing to/unsubscribing from feeds, and getting updates.
• Viewing specific feeds, or just reading unread items
• automatic deletion of old items that have been read (This is the only thing that I haven't tested thoroughly. It should work fine, but I'll know in a week or two if it doesn't.)
• Partial RSS, Atom, and RDF support.
• Partial custom themes

The list is pretty short so far, but it's a solid start. The most essential parts are all there, and now it's more about improving quality than just getting the thing to work. At this point, updates will probably be a little infrequent. I've got plenty of other projects in mind, after all. Of course, I'll probably never drop support, since I rely on this app myself. You can rest assured that I'll be keeping this thing in working order for a long time to come.

Singularity Update 5

Changelog:

• Upgraded to use a newer version of WebKit
• Links now open in your default web browser
• Fixed even more bugs regarding parsing and such
• Items are now marked as read when you see them, not when they are loaded into a view

This is starting to get a bit silly, so I'm releasing Singularity before the end of this week. Already, this version of Singularity greatly exceeds my expectations for a 0.1 release, but general nervousness and an inability to call the version done have held it back. I'm going to figure out licensing, stick it up on Github, and post the link up here. Hopefully, it'll be done in a day or two. At worst, I'll finish before next Monday.

Singularity Update 4

Changelog:

• Added support for RDF feeds
• Tested 252 different feeds on Singularity, currently 251 of them are correctly handled.
• Fixed a ton of issues when trying to get/parse feeds in various situations.
• Added icons to the GUI that display the load/update status of each feed.

I really want to release Singularity as it is. I really do. At this point, the old version doesn't even compare to what I have now, and I'm starting to get antsy. However, there still remains one obstacle before I can put out a release. Currently, clicking on links will open the contents in the same view that's being used to display feeds. Obviously, that's a bit of an issue. The old Singularity doesn't have this issue, but it has a bad habit of opening embedded content in a browser window. It's a small annoyance, but with larger feeds it can get quite out of hand. I want to find a better solution before I release this version, since being able to actually open the links that come in is (obviously) a very important part of the software. Once I figure that out, I'll be set to release this version. This time, it's good enough to provide publicly as well. I probably won't post another update on this until the release, but I also expect the release to come next week so it shouldn't make any difference. When that post DOES come, I'll give a general round up of what's there and talk about the future of the project a bit.

Singularity Update 3

Changelog:

• Atom parsing now works about as well as RSS
• Missing data files are now created, and missing configuration files now have their settings replaced with default values.
• Started working on an auto-delete feature, to remove old items

Sorry for the short (and late) post. I'm rather sick, so getting work done is difficult right now. Hopefully I can get back into the swing of things in a few days. That said, Singularity is almost ready for a 0.1 release, similar to what I did with AMAZE. I want to finish the auto-delete feature first, however. Right now, it isn't working too well.

Singularity Update 2

Changelog:

• Created the initial UI
• Feeds now update on startup. Note that there are two differences from the previous version: First, the updates don't freeze the UI anymore. The second major difference is that the feeds should no longer have to update in order, but instead update all at once. This should speed up the update process as well.
• Feed items can keep track of when they were downloaded, so that later I can have them be deleted once they've been around for a while.
• Added buttons to the UI for adding and deleting feeds. This was one of the biggest missing features from the old version, so I'm glad that it all works.
• Deleted feeds aren't fully expunged until the application exits, so that I can easily add an undo function later.
• Started initial work on Atom parsing

These past couple of weeks have been great for Singularity. For some reason or other, I feel really excited about the project and I've been super productive on it. At this rate, I can probably put out a public build by the end of next week. The main thing that I need to do at this point is testing. If I migrate all of my current subscriptions over to the database for the new version of Singularity, it'll probably be a pretty good measure of how well the application works. There are some crashes here and there, but most of the common bugs are gone, and I have the others sorted out somewhat. Now that college has started again, my productivity will probably take a hit, but I'm quite confident that I can finish this soon thanks to my current momentum.

Expect a minor release soon!

Finally, here's a screenshot of the work in progress UI:

Lots of placeholders still, but it's already a bit better than
how the old version looked.

Updates: Singularity is DONE! Sorta.

It's been a bit too long since my last post, but I have some great news. As if you hadn't guessed from the title, Singularity v1.5 is now complete enough to that it'll do for the moment. I can now move on to AMAZE, and spend the next couple of weeks testing it out and looking for bugs. There are several features that I wanted to add, but they aren't too urgent.

Updates: Almost there, and another game jam

First off, I thought it'd be good to mention that the next version of Singularity is almost in working order. While there are a good few things left after getting it up and running, The end is very much in sight now. I think I may be done by the end of this week, in fact!

As the title may have alerted you, there is another game jam coming up that I plan to participate in. In one week, I'm going to participate in the new 7-Day Fishing Game Jam. I've never made a game about fishing before, and getting another game under my belt would be nice. I'll probably be posting most of my updates throughout the week in my thread, and I'll of course be putting up a development album on Google+ again. I've decided to reuse the character from A Wheelie Good Time here, and I'm finally giving him a name: Doomsday Darren.

Singularity: Progress and Goals

One of the biggest accomplishments of the past 3 weeks was completing version 0.1 of Singularity. It took a while, but I've gotten rid of most of the major bugs, leaving it in a stable, working state. Here's what I've added:

1. Singularity also automatically checks for updates every once in a while, displaying a system notification when you have unread items
2. Slight graphical improvements to the feed view
3. Entries now display their author(if provided)
4. Most feeds ought to be correctly parsed now, even the ones that are improperly formatted

One big issue remains, however. It takes an absurdly long time for Singularity to start up. This is because imports aren't done in a separate thread at the moment, and the program must wait until they're finished to continue. I have a solution in mind, but it's not showing up until the next version. I'm also planning on restructuring both the code and the interface for v0.2. In the meantime, though, it works well enough.

Singularity: Progress!

So, I mentioned last week that I was working on database integration. Since then I've made massive strides in the development of the application! Here's what's new:

1. I added the ability to subscribe to feeds. When the program starts up, it quickly checks for updates to any subscriptions you have. It also displays a list of subscriptions, and this lets you quickly access them.
2. Subscribed feeds store their entries offline in the SQL database. When checking for updates, the program also downloads new feed entries. The main advantage of this system is threefold: First, it lets you read feed updates offline(though content like pictures and video won't load). Second, it makes loading up a subscribed feed(which you'll probably be doing all of the time) lightning fast, since it doesn't need to get the data from a server. Third, it allows the program to store old entries that would otherwise be impossible to get.
3. Some bad news: Feed data eventually leaves an rss feed, and there's no way to access older stuff. That's one of the main reasons I decided to make my program download feed entries. The final version will also update regularly if left running, although I haven't added that yet. Of course, it may be possible to miss updates if the program isn't run for a long time. However, it ought to be able to detect this, and direct you the site that the feed is associated with. This is the best solution, considering that I want to keep the program independent of any web services. After all, it only exists because of one ending.
4. You can now see when an entry was posted, and entries *should* be displayed in chronological order.
5. I've begun work on parsing Atom feeds. It's a gigantic pain, and I really wouldn't mind punching whomever designed it, to be perfectly honest. Still, it sort of works. I can't get the content displaying right yet, but at least I can provide a link and post date.

All in all, it's been a very productive week. The next three weeks probably won't see that level of work, but it's still great to see progress on something.

EDIT: Oh crap. I just remembered my little sprite quota. I think I may have missed it last month. This month should be different, though; I have a ton of spriting to do for my Game Tech final project.