Foxkit Vector Icon

So after doing nothing for a while I started thinking a lot about a logo for Foxkit.

I've never been very artistic, but I had a nice vision in my head for the logo (more so icon), so I started thinking about how to make it using vectors art. I downloaded Inkscape and got to work trying to figure out how to use all the tools, and since I've spent lots of time watching multiple people use Illustrator (the vector equivalent to Photoshop) over many years, I had a general idea what the tools should be able to do.

After quite a bit of experimentation and failure I eventually got the basic outline of what I had in my head. With quite a bit more failure I eventually got it colored (although not exactly the same as I wanted, but good enough for now).

You can find the Inkscape SVG on kde-look.org ( http://www.kde-look.org/content/show.php?content=87252 ), later I plan on making it the default icon for Foxkit (so it should appear in the Git repository before long) although I'm always open to alternatives (preferably something with a similar feel... I really like the Fox at the bottom :P).

New Tabs, Development

Earlier I got links that request a new tab to work, I still got one minor (possibly unrelated) problem to work out and I think I'll have most of the features I want for 0.0.6, though since I just made a release I'm gonna wait a while for the next one and try to finish the cmake stuff and maybe have a tiny config dialog.

The last couple of days I've been reading various Qt Quaterly articles and have found them extremely informative (especially the one about designing APIs), several of them will definitely help in the future.

The more I work on Foxkit the more problems I'm encountering and the more I have to twist the API and internals, often undoing various things I'd previously done in the process. That may seem like a bad thing, but it's actually a good thing, as I've actually be solving the problems (and learning from my mistakes) and the API has been improving (some) from my changes.

The original way I had it setup couldn't handle the needs of a real browser, but it's slowly getting to the point where it actually takes only small modifications to get things working. I tried a few ways to solve the problem with links that wanted to open in new tabs, the first was an attempt to use signals with a non-void return type (can't do that), then I tried to give it a single argument, a pointer that the slot would set to the page it'd create which would result in a blank tab, lastly I slightly modified how tabs were created, I moved most of the code into a function that took a pointer to a webView and did all the connecting/inserting into the tab bar which made it easy to solve my problem.

The webView::createWindow() function would create a pointer to a new instance of a webView object then emit a signal with the pointer as one of the arguments, the slot in the foxkit object would take that pointer and do exactly the same as if it'd gone through newView (as newView does the same thing as the createWindow() function.

This prevents code duplication, and code duplication is Very Bad. Not just because it has a (generally trivial) impact on performance, but because I'll update one version of the code but forget to update the other and then have no clue why things are breaking :P

All-in-all I'm extremely happy with Foxkit, I'm not to the point where I'm gonna ditch Konqueror/Opera, but I'm actually getting to the point where that seems reasonable.

0.0.5 Released

I just released Foxkit 0.0.5, you can get the source from the Google Code Page.

Right before the release I was working on trying to get windows/tabs opened by Javascript to work, but the changes were getting to the point of creating a lot of extra complexity and even then it was causing other functionality to result in seg faults so I ended up just reverting all the changes. Later I'll have to think some more about a better design that'll be able to handle this situation (unfortunately signals can't have a return value which I had forgotten).

Depending on how long that takes it might just be a release just on it's own, or if it's easier than I expect I might also work on trying to get error pages to work properly then release 0.0.6. For 0.1.0 I wanna get both the javascript tabs/windows working properly and error pages working okay, along with a couple more things I think up along the way.

Edit: Finishing the cmake files so that it'll actually install would be a good thing to also do :P Shouldn't really be that hard, just take some time looking through the documentation or some other project's files at worst.

Getting close to 0.0.5, my first bugfix!

First Fix from the Google Code Issue Tracker

So last night I noticed that I had the first issue added to my Google Code page for Foxkit (from someone other than me). The issue was about nothing happening if trying to browse to a website that used a self signed SSL certificate, so I fired up Foxkit and (surprisingly) found normal SSL websites worked, although going to my personal website's SSL version didn't work (the cert if for a different domain than mine, the domain of my hosting provider which the SSL version simply redirects you to).

I looked around the docs for QtWebKit and quickly found out what signal I needed to connect to, and posted a reply to the issue saying what all I figured I'd need to do to properly support SSL errors, then went to bed. Some time after waking up this morning I decided to get to work on SSL error handling, and before long had a version that'd work with my website (although I couldn't think up of any self-signed sites to test it on) and commited a fix that'd add the basic support needed, and followed on the Issue tracker marking it as Fixed (but not Verified) about 14 hours later. All-in-all, I think 14 hours is a pretty good turn around.

(no one mention that I only noticed the bug report a month and 13 days after it was posted :P I didn't think about the fact that I wouldn't be notified when issues were added so wasn't watching it!)

Approaching 0.0.5!

So I'm quickly approaching what I want for the next release, and actually really have everything I set out for when I readjusted my goals with the first post. I'm planning on making the release by Friday at the latest, but hopefully will get it out early in the week. If it wasn't so annoying to create the tarball with all the things I needed and only the things needed I'd probably make the release now... but I guess I'm just trying to push that off for a little bit :P

So far I'm extremely with how Foxkit is shaping up, this is the first project I've seriously worked on and kept up with, I've ran into lots of problems, including a nasty memory leak/crash thats been around and known since the first release or so and finally was fixed yesterday, and have learned quite a bit about problem solving, software development, C++, Qt, KDE, and that I could actually do this. After the 0.0.5 release I'm wanting to add support for alternative cookie jars, as right now they'd be extremely useful for me, having to manage multiple Google accounts is a bit of a pain in the you-know-where.

New Blog, Foxkit's current status

It has been quite a while since I last made a release of Foxkit (KDE-Apps page, Google Project's Download Page), but the Git repository is still alive! I've done quite a bit of development since the 0.0.2 release, including adding support for Cookies (and the start of support for multiple cookie jars), better tab handling, massive amount of code cleanups, and lots of other things I long since forgot.

I'm hoping to release the next version of Foxkit sometime next week, probably with a 0.0.5 version number. So far I've done a pretty lousy job of following my roadmap, but hopefully in the future I'll be more flexible with it, and maybe try to switch to time-based releases (maybe once a month?). I've decided the only show stopper for the next release will be to have Foxkit's cookies stored in a better place than /dev/shm (generally a tmpfs filesystem on Linux... trashed when the system reboots), theres probably a KDE directory that stuff like thats supposed to go into. After this next release I'm wanting to add support to query Solid to check to see if the network is up or not, as well as add error pages (silent errors are evil!).

Edit: Just commented the change to use KStandardDirs::locateLocal("appdata", "cookies.db"); instead of /dev/shm/cookies.db :P