Emma's Software: Blog

First, no this is not an announcement of a Mac OS X version of ePDFView. It doesn't make much sense to me, since Mac OS X has PDF support built-in.

My idea is to use my notebook as my main development machine, so I need a way to continue working on my projects. That means that I needed to install GTK+, but I didn't wanted to use Apple's X11. What I did was install GTK+ version 2.10.1 which has native support for Quartz, Mac OS X's graphics subsystem.

I couldn't resist the temptation to compile ePDFView with native GTK+, and this screenshot is a proof that I managed to do so :-)

Of course there are some little bugs, both in ePDFView and GTK+'s Quartz backend, but the application is still usable (most of time...)

I'm still trying to (slowly) work on eGeki, but this small test makes a little easier to continue developement on ePDFView when the competition ends.

It's been a while from my last entry, I was waiting for my new MacBook to arrive. Since I'm a GNU/Linux user, I'm still trying to get used to Mac OS X's interface, but having a terminal is always a relief :-)

I'm also taking a rest of ePDFView to start a new small project with a friend: eGeki. eGeki will be, hopefully, our entry in this year's Four Elements contest held by GameDev. If things goes right, eGeki will result in a small graphical adventure that I will try to make work on Windows (contest's requirement), GNU/Linux and Mac OS X, using SDL and Squirrel.

The contest ends in November, so probably until then I'll not release any version of ePDFView. Sorry.

Oh, by the way, the 3rd PyWeek will be the week of September 3 to September 10,

As finally I've added print support to ePDFView I decided to release version 0.1.5 today.

Besides the print support, this version also handles Internet hyperlinks and is able to save document's copies. I've also fixed some bugs (thanks baze to report them!) and also some minor interface improvements; I'm very happy with the new keyboard navigation, thanks LoneFox.

Unfortunately, this time Moritz Heiber couldn't update the German translation for work reasons. I hope it goes smooth with your new destination. The French and Vietnamese translations were updated, as always, by Mr_Moustache and VnPenguin, respectively. Thanks to all.

Finally! I've added printing support for ePDFView.

Currently only CUPS is supported, although I don't see any problem with it as it's possibly the most used GNU/Linux's printing system. Of course, since it's my first time I add printing support to an application, there's still somethings missing like support for preferences or color modes (thanks baze for reporting them).

The print dialog is "strongly based" on Gnome's print dialog, although not that beautiful. I think it's pretty functional, though.

I expect to resolve the current issues and release version 0.1.5 this week :-)

Yesterday GameDev's Four Elements V contest began. In short, the aim of this contest is to make a game based around four elements.

I couldn't participate in the previous edition and I'm not really sure if I will participate in this one, but this time I feel a lot more motivated to do so.

I also found that the people behind the GP2X also started a contest. If I'm fast maybe I can make a single game for both competitions although I have no chance to win on neither, due to my ability to create only crappy programmer's art ;-)

Edit 2006-06-05: The Summer '06 72 Hour Game Development Competition is also going to be this July. I guess summer is a good time for a game competitions ;-)

Since I have a job I can't spend as much time in ePDFView as I want, so its development slowed down a lot.

This week end I was able to add support for URI links besides the already supported internal links. In order to do this, I also had to add a new preferences dialog asking to the user which command line to use to execute the web browser when such a link is activated. The default is to use Firefox because I think is the most extended browser in GNU/Linux desktop world.

I really don't know if this is really a good idea for handhelds users that are using ePDFView since I don't have any and can't test it.

I hope next time I write and update is to tell you that I have added printing support as it seems to be the most wanted missing feature.

Yay! Finally I was able to find a job after a month or so of job hunting.

My new job now involves software as well as hardware. The hardware part is the most exciting, as I never had a job dealing with hardware at this level (I don't consider tech support as a hardware job...).

The software part is like what I've done in my spare time. I also like it a lot, even though I have to use Qt. Nothing wrong about it, but I'm more confortable and used to making projects in gtk.

I do hope to have fun with this new job! ;-)

Since I have finished with the find bar, today I've released version 0.1.4 of ePDFView.

As I already said, I didn't include features such as selecting text or printing, but I think this version's greatest feature is that I have finally threaded most backend's operations, even though I had serious problems at the beginning.

With most operations running in a separate thread the interface feels much more responsive that it was on previous versions. At least now doesn't seems to be hung when the page is changed :-)

Since threading is generally such troublesome, I'm not really that sure if it will work as it should. I did my best to test it so as few problems as possible comes with this version but time and, over all, bug reports will tell ;-)

Long time no update!

During the past days since my last post I've been able to solve the threading problems that I was having. Or at least that is what I think.

I was creating a thread for each background job that the application needed, like opening a file or rendering a page. This made the application too complicated, since in nearly every class I was dealing with thread code. Now I have a simpler approach: I have only one threaded function that waits jobs to be enqueued and, once a job has entered the queue, pops them out and runs them. Of course that means that only one job is in execution at once, but I have found that most jobs don't take that long, except rendering pages.

I also have made the document classes follow the observer pattern, that way all GUI presenters can attach themselves to the document classes and wait for the document to send notify messages when the document's states changes. This helped a lot while separating the main window's presenter and the document page's presenter, although the SVN version was broken a long period while doing all those changes.

Now I'm trying to implement search functionality that will use a find bar similar to firefox's find bar. Currently I have implemented the search code in a background job that passes all the tests, but I think tomorrow I'll have the actual find bar.

I guess that when the find bar is implemented I'll release version 0.1.4 of ePDFView, leaving the selection options, print features and continuous mode for the next version.

In hoping to improve the user interface of ePDFView I'm trying to adding a little of threading so loading the document and rendering pages will be done in background.

The problem? Either I'm too stupid or threads are difficult (or both, which is more probable.) I mean, Glib has a great support for threading, but when I have a problem with the application (which seems random now) I don't know where to look to.

Also, adding threads to the application makes the automated tests a lot more difficult and slower: I have to wait for the document to load, which is done by a different thread so I don't really know when or how it will end. For now I put some sleep() statements which obviously makes the test slower than it should.

I only hope that I learn from all this :-)