Archive for May, 2009

Trac attention

Friday, May 29th, 2009

So I’ve gone through and updated some of the bugs on Sigen’s Trac instance. The map editing and shape editing for effects and warps has been delayed to, well, whenever I can get to it. I don’t think that these are really all that important now anyways. Getting some sort of client up and running is more important than maps since they’ll just have to wait until after I get something down for the battle engine. However, even that must hold off for something even more important: documentation. Currently, there is some Doxygen written for the sigcore and sigmod libraries, but since sigcore is basicaly trivial and sigmod isn’t really used by anything directly, it’s not that useful. It’s documentation should probably be moved to sigscript and internal documentation put into sigmod. The editing app, Sigmodr, also needs documented. There’s a lot of stuff to do yet to really be polished. I’m not really sure how to do i18n (at least on the developer side) right. Artwork is missing (icons and a logo for the project at least).

I also updated the front page of the wiki so it isn’t the stock one. I hope that I can get the project some kind of visibility with the 0.2.0 release, but since I have yet to actually get it to run reliably on Windows, it’ll be a chore. Hopefully making it available will be easy and the KDE4 Windows installer will be able to handle it.

Posted in Sigen | No Comments »

Chrome, isn’t it shiny?

Thursday, May 28th, 2009

Warning: This is a rant.

I’d say not. I’m really not sure I’ll ever be using Chrome (at least according to this page). They forget one thing in their list of what not having a 64-bit version available means. You have to duplicate the disk space for libraries that I have 64-bit versions of already. So yes, you may have larger pointers and executables, but by forcing 32-bit, I am forced to take up lots more disk space. Just installing gtk2 here would be 19MB of space. This is much more than the difference between a 32-bit executable and a 64-bit executable for a browser. The difference in disk space for KDE 4.3b1 i586 and x86_64? 9201809 bytes (9.77MB). This is over 1.4GB of rpms for each (this includes debuginfo, srpm, binary rpms, and repodata for yum). So for installing a 32-bit version of gtk2 to be cheaper than just offering a 64-bit version (on-disk), the executable has to be (assuming linearity) around least 3GB. I don’t think that would be acceptable. In fact, why it’s 511MB (according to a quote in this article) is even beyond me. That’s 1/3 the size of KDE, so Chrome already sounds bloated beyond belief. So the arguments they list for not providing a 64-bit build are flaky. The most defensible one is the V8 not having x86_64 code generation, the rest are poor excuses.

Now, I know that disk space is cheap, but not so for my / partition, which I usually keep around 10-15GB. This is enough for all of the typical stuff I install, room for new stuff apps out, and a couple debuginfo packages. The only thing that tends to hit the limit is large mock builds and even then only after not clearing the cache and theres lots of old, unused packages there. I like to keep it minimal, and 32-bit libs on my 64-bit machines is usually a show-stopper to installing something these days.

Then there’s the decision of which look’n'feel to use. Now I’d prefer Qt/KDE, but it doesn’t really matter as long as you pick a side and stick to it. Sitting in the middle just makes you a weird application that doesn’t really fit on either side. Mozilla has a nasty habit of doing this (on Linux at least, Windows is already a misshapen landscape in this regard) and making me squirm when their apps fail to work with the other apps I use. Mainly, Firefox needs to grow some support for shared-mime-info and stop trying to be special. I can make GTK look like my KDE apps (though size hinting for widgets is off, that’s minor; the real miracle would be replacing the horror that is the GNOME file dialog with KFileDialog), but if an app chooses to use some of GTK and then custom draw other things, it’s going to look even stupider when the KDE theme is attempted on top of it. Don’t be a sore thunb on someone’s desktop. Theming and skinning suck, just deal with it and use the system colors.

Speaking of Firefox, the one-process-ever deal. I don’t like it. One window crashes and they all crash. I understand what Google’s doing with the one-process-per-tab, but I think it’s a little too much. One per window is enough and session restoration should cover the rest. Which Firefox has also had issues with. At times it has been one or two tab changes behind and forgotten history when restored. Generally makes that a pain. Konqueror has remembered form entry data as well, which I haven’t seen Firefox do yet (though it does crash less, ted.com was reliably doing it, but it’s Flash so there’s nothing anyone can really do). Ctrl+Tab is a disgusting key combination, but I have yet to find a way to get away from it. I like Ctrl+, and Ctrl+. better. They require moving two fingers, Ctrl+Tab requires rotating my hand. Yes, my shortcuts matter to me, but Firefox has them hard-coded it seems.

I think the browser wars are good. Keeping other vendors on their toes and having to make new things instead of settling with what’s done is good. The proliferation of JavaScript engines however, I’m not all that thrilled about. Hopefully there won’t be the need to do browser checks once things move onto The Next Big Thing. They suck and I certainly won’t be doing any favors for non-standard browsers. Custom extensions to the standard also suck for the same reason. WebKit also has its issues, such as not using system widgets and instead opting to draw their own and look different (at least in QtWebKit; I couldn’t care less about Safari or Chrome since I probably won’t be using them in the forseeable future).

By the way, I use Konqueror. It runs lighter than Firefox (12MB vs 29MB at startup with extensions that brings Firefox to just below accessible feature parity). It has no need for the basic extensions. Adblock, sane downloading, noscript, and on-demand plugin denial are all with it. The only major thing that is missing is some kind of GreaseMonkey equivalent. It Just Works with my other applications. No need to customize “Open With…” bindings and all that stuff.

Posted in Uncategorized | 4 Comments »

Much-needed update

Wednesday, May 27th, 2009

Okay, so I lost the old post half-way through the second paragraph, let’s see how much I can remember.

It’s been over a month since I’ve paid attention to this nook of the Internet. Another year of school ended, got my wisdom teeth removed, gotten into playing some Dungeons & Dragons, hacked a bit on Sigen, building KDE 4.3 beta 1, finally getting VNC working, and some other miscellaneous stuff.

I was able to replace 10,000 lines of code with about 1,500 lines in the tree widget in Sigmodr. It now no longer needs right clicking to add and delete items in a game. It has lost drag’n'drop and copy/paste support for now, but the maintainability of the new code is well worth the loss.

The map editor has had a few bugs squashed as well, though I may have to switch over to a new way of doing it since there’s a test case I hadn’t thought of that the current algorithm is choking on. To visualize the case, imagine a π and then placing that on a platform. There is now an outline and an internal area. The current algorithm screws up the internal outline since it doesn’t know that the other leg (on the same polygon) is the target; it only looks at the other polygon for a target point. So it’s broken and fixing it would take a lot of time. I’ve been trying to think of a data structure scheme which will nicely accomodate the vector idea I was tossing around even while making the current algorithm. A map would work, but I don’t want to have to fiddle with pairs and whatnot.

I’ve also built KDE 4.3 beta 1 for Fedora 11 (i586 and x86_64). I don’t know when they’ll hit the kde-unstable repo at kde-redhat. I have a list of bugs to submit, which I’ll work on submitting in the next few days.

The Kopete runner I was working on is still at the same position it was before, but after talking with Matt Rogers, it looks as though Kopete’s DBus interface needs to be fixed up and redone for it to work. This means that it will have to wait until KDE 4.4 and I’ll be learning myself some DBus goodness. It doesn’t look all that bad.

I would also like to announce that I have my server up with a public address now.It has HTTP and git services. The important URLs are:

Most of the git repos are there to keep old code in VCS if I ever hack on them again. The older stuff is scary, not really for the faint-at-heart.

Posted in Fedora, KDE, Sigen | No Comments »

Running into trees

Sunday, May 3rd, 2009

So this weekend I started hacking on the new tree for Sigmodr. It’s so far going okay, though there are some issues with juggling the indexes around, which is the most annoying part about Qt’s MVC (at least with trees, I haven’t touched the table models for a while). This new tree will be much more compact and easier to maintain. Instead of being strewn across a couple dozen classes, 2 files per class, it will be 3 or 4 classes with less than half the code since I can condense it all. The old tree is full of hacks and nastiness I didn’t like when I first wrote it, but I didn’t know any better then. Now that I’ve had more exposure to writing some models, they make more sense, but juggling indexes is still a pain.

I also got a KDE SVN account and committed the beginnings of a runner for Kopete to set the status of accounts and to be able to start chats. I’m currently stuck since in order to access Kopete’s accounts with libkopete, I need to fake having Kopete’s configuration file as the runner’s config. I may be able to use DBUS, but I’ll have to look at Kopete’s interface a bit more to see what I can use from that. The runner is currently in playground.

Posted in KDE, Sigen | No Comments »