CCP should really invest in a real HTML renderer. WebKit is really easy to integrate after all… Plus it would be orders of magnitude faster. But alas, that is not the case and registration is broken.

On the upside, this does allow me to pose an interesting question. What else would you like to see for registered users? New tools? A clean up of the corporate web hosting? Better security through the EVE API?

One feature I’ve been mulling over is wallet order uploads and/or transaction pulling. Either see your own orders while you’re offline and aggregate the statistics into a much better pricing model for the market. The current approach of using posted orders is flawed as it only provides a glimpse into what all commodities are trading at. After all, an order is not a transaction.

Thoughts?

Stay tuned in the next 3 days

Be back soon.

Edit: We’re back up

For example, to add a simple TableLayout() to a form:

class Form1(yyafl.Form):
    name = fields.CharField(label = "User name", required = True)
    email = fields.CharField(label = "Your e-mail address", required = True)
    hidden = fields.CharField(widget = HiddenInput, default = "123")
    _layout = yyafl.layout.TableLayout()

and to render the form to HTML:

# Render using the layout specified in _layout above.
content += f.render()
# Or invoke the layout explicitly
l = yyafl.layout.TableLayout()
content += l.render(f)

yyafl Layout()s also understand decorators:

decorators = { '*' : MarkRequiredDecorator(),
    'name_field' : HighlightDecorator() }
layout = yyafl.layout.TableLayout(decorators = decorators)
layout.render(f)

Decorators can change attributes and wrap fields in markup blocks. In the above example, the ‘*’ signifies the decorator should apply to all fields, and the HighlightDecorator should only apply to the field called ‘name_field’.

There are still some not yet implemented ideas:

• It doesn’t generated the <form> blocks yet, you need to roll your own.
• Field reordering and grouping isn’t supported by the default layout engines yet, though you could write your own.
• No AJAX form support (though its coming!)
• Automatic CSRF prevention forms.
• Error message printing in the form.

You can find these latest changes in the Git repository linked from the main yyafl web page.

In short, qsgen is a pure Python functional wrapper around Mako templates and the Pygments library. It lets you build a hierarchical set of .html pages and associated base templates using Mako, which will be transformed into static pages for serving on the web. In addition, it also includes support for Pygments syntax highlighting in-line with the HTML or even with source code sourced from separate files.

I’m using qsgen on both www.stackfoundry.com and tomeapi.com. If you feel making a dynamicaly scripted website just in order to display some simple content is silly, or feel the complexity and headaches of a true CMS system outweigh the benefits, then qsgen is for you.

(qsgen is very similar to a similar script called Maehan which I was using for many years. Consider qsgen a more feature packed and cleaner version of the old Perl Maehan).

We’ve hit some instabilities recently, but so far been able to track them down. Sorry about the small bursts of downtime. If you do notice EVE-Central.com not responding, feel free to send me an e-mail just in case I haven’t noticed it yet.

For the technically curious, we’ve hit the following issues:

1. Not checking ulimit -n for the gang of cherrypy servers. Ran out of file handles, didn’t recover well from that. Now we have plenty of file handles to go around
2. Hit a bug in the tradefinder route planning software, which caused it to spin forever trying to compute routes to Black Rise. Once again, didn’t self-recover from that. There are still some questions on why it caused the gang of cherrypy instances to go belly up, but thats another story.
3. Hit a bug in cherrypy’s own FileSession code, which could cause deadlocks. Applied a patch and we’re back in the running.

We value our visitors and want to keep EVE-Central.com going strong.

I’ve been using both KDE and Gnome on Linux for many years, and also use the Redmond user-interface (aka Windows). I also own a Mac. The Macintosh (OS X) and Windows are similar models, and Gnome and KDE are even more similar to Windows. Now, I am not saying that either interface is unusable, but it is an inefficient choice if you fall into the categories above.

Granted, the classic window management paradigms are very familiar. I won’t say natural, since computers are really not natural, they’re a learned behavior. Computers only feel natural when they operate in a similar fashion to other computers you’ve used or seen in the past. The problem with this user interface paradigm is becoming apparent as screen sizes grow (and shrink!). Your desktop is simply far too large to use properly in its overlapping window mode. Plus all the mouse work moves you away from your primary user interface device: the keyboard.

Many program designers have noticed this. They’ve moved away from the nightmare of MDI (multiple overlapping windows inside of your overlapping window), and developed docking elements. The toolbar you can dock and move. The properties editor on the right. You can’t (generally) overlap the dockable elements. But in all cases, the elements are on the side or around your document or main view. Stuff stays put, is intelligently placed, and doesn’t get in your way constantly. Why can’t a window manager work the same way? But it can! Enter the Tiling window manager.

I like StumpWM, which is a tiling window manager modeled after ratpoison (and all other tiling managers before it). Its command set is a good mix of GNU Screen and emacs. Its also written in pure Common Lisp. There are other tiling managers out there, such as my second favorite, XMonad, which can even work flawlessly in Gnome and KDE (or mostly flawlessly anyway). XMonad has the advantage of automatic layout modes which StumpWM currently lacks. I didn’t particularly like Ion3 or WmII: the multi-monitor support is not as developed as StumpWM), plus Ion3 open-source development could be at risk. .

I’ve been using StumpWM for a couple of days. I am trying to quit Gnome cold-turkey, and so far have been successful. All of my applications work. The few gnome specific management applications I used I’ve managed to replace (such as NetworkManager for the laptop). My environment is lighter without the 50 background processes Gnome uses for automagic abilities (HAL, DBUS, etc). It doesn’t suffer the “users like simple, so lets not complicate stuff” philosophy Gnome uses in several places (an example: gnome-screensaver vs xscreensaver). Plus, I can use the keyboard almost exclusively, only touching the mouse to use certain applications. All window operations are entirely keyboard driven.

But if you’re not trying to quit Gnome completely, both window managers can show the normal Gnome panel for you. One thing you’ll have to scrap is the Desktop paradigm - you can put a picture on your root window, but the cluttered mass of icons isn’t available - you’ve put something far more useful there instead. Your applications.

It may seem scary at first, but I encourage you to try a tiling manager. Give yourself several hours of dedicated time. Will yourself not to switch back to the old familiar interface. Print out the quick reference or the whole manual, just in case you get lost in how to move around :). Its well worth the effort.

Enjoy!

On another note, I’ve learned the virtues of making sure the environment the server was running in had enough available file handles

We’re back in operation. If there any any problems, feel free to contact me in-game or by email. I try to pursue the forum thread, but its low on my reading and daily check list.