Ben’s pculture blog

Last week I worked on getting the tablist to work right.  I would say I’m about 90% of the way through it.  I have the channel tabs almost working, the only thing needed is drag and drop.  Once I implement that, then I’ll work on getting playlist tabs and the static tabs, neither of those should be very hard since at that point all the platform-specific code will be in place.

One interesting thing is that the more I work with the widgets branch, the more I realize that once we switch over we can simplify the database a lot.  For example, when I was working with drag and drop, I realized a lot of the book-keeping we do in the TabOrder views can just be thrown out.  Also a lot of the data that’s setup in onRestore() isn’t needed anymore (like if a feed is blinking, or if it’s parent is expanded).  I really like that since it can simplify moving to not having the database in memory.

Next week I’m going to finish up on the tab list, then I guess I’ll move to the items list.

This week I mostly spent adding support for custom buttons and sliders to the widget branches.  It went along well enough, right now there’s playback buttons and a progress slider.  I think the volume slider will be trivial to add, I might have it before the dev call.  The system seems like it’s working pretty nice and it’s easy to customize.

Once I get the first pass done, I’m going to take a bit to make sure that they are accessible.  This mostly means making sure they accept focus and respond to keyboard input.  I think this will be very easy on GTK, but I don’t really know how it works on OS X, so that might take a bit of time.

After that I think I’ll work on dialog boxes for a bit, which shouldn’t take long, then move on to the left-hand tab bar.

Overall the widgets port seems to be moving steadily but surely every week.  It’s really satisfying to click on the play button and see my debugging printout.  Also, the new UI looks really nice, I can’t wait to release it to the world.

This week I kept chugging along at the widgets branch.  The begining of the week I spent trying to get the windows port to build since I was basically replacing the entire build process.  I also needed to rewrite my GTK/XULRunner focus fixing code in C++.  I’m not sure exactly what went wrong, but when I added a second thread to the mix subclassing windows procedures gave me segfaults.  I think it has to do with the python GIL, but I don’t really know why.

Right now I have code working on all platforms that displays a window with a web browser inside.  Now I’m working on layout code, which mostly means coding vboxes/hboxes/alignments on cocoa.

Also this week I talked with you all and several people on IRC about different ways to make background tasks less noticable.  I’m pretty excited to get that stuff into 1.5, seems like it’s not too much work and it could have a nice payoff in terms of user experience.

This week I continued my work on the widgets work.  I checked in code to the widgets branch to handle basic startup/shutdown and open a window.  It’s very simple, but it’s pretty cool to see that window pop up and miroguide.com show up.

At the begining of the week I implemented it in portable and on OS X.  The GTK/X11 implementation was about 2 hours or so.  The windows implementation on the other hand is going to be a real pain and requires basically trashing setup.py and rewriting it from the bottom up.

That brings me to one thing I want to talk about on the call.  If I’m going to be basically starting over with our setup script, I’d like to talk about using mingw as our main C compiler.  I’ve been thinking about how much of a pain it was to add support for the vista function calls and how it would have been a ton easier if we were using mingw. I’m pretty sure mingw has supported the calls for quite a while, and if it hadn’t it’s so much easier to upgrade it’s win32api package than it is to install a new microsoft SDK.  It’s been especially on my mind because I tried to install visual c++ 2008 express and it completely ruined my build environment.  I’d love so much to get rid of microsoft tools and just use free ones.

The main reason that we’re not using it is that the python docs say you should use the visual c++ 2003 to build python extensions.  I’ve done a ton of reading about it and it seems like the reason is complications from using a different C runtime DLL.  Python uses msvcr71.dll, but things compiled from mingw use msvcrt.dll.  Using different C runtimes can cause problems in a couple of ways.  The main one is trying to share data (for example a FILE pointer) from one runtime to another will cause very bad things to happen.  Then there’s more subtle errors, for example atexit() callbacks will only fire from one runtime.  However, all of the errors don’t seem to happen in practice so often. It seems like the main reason that people try not to mix compilers for peace of mind.  But the gtk DLLs are linked to msvcrt.dll, so it seems like we can’t get total peace of mind in any case.

Anyways, I’m not really sure of the ramifications, I’d love to talk on the call about what people think about this.

This week I spent most of my coding time trying to wrap my brain around Cocoa and pyobjc.  I figured it was going to be at least somewhat similar to GTK, but actually it’s completely different.  I’ve just been trying to get a window to pop up that displays miroguide.com, but there’s still quite a bit over my head.  Hopefully I’ll get it working in a few days, I think this first step is going to be the hardest.

In addition to coding, I’ve been spending tons of time trying to figure out how we’re going to make native widgets work.  Mostly it’s been pretty exciting for me though, since I realized that NSOutline/GTKTreeView work on very similar models and are actually much more flexible than I though.  I think they could work great for the item lists and tab lists and be super-snappy.
Lastly, I’ve been working on getting my unaccepted bugs down.  I think I’m finally in single digits now, this week is the week I finally get bugzilla to stop pestering me!

This week I’ve been up to my neck in web browser code.  XULRunner, WebKit, gtkmozembed, you name it.

My main goal was to get an embedded web browser working on windows, so that we can move forward with the widgets program.  The only one I could get working was XULRunner.  I thought XULRunner was a dead end for a long time, because I couldn’t understand the focus issues, but now I finally do and I’m able to get it working pretty much 100%.

When I had given up on XULRunner, I spent a while trying to get WebKit for windows to work, but I was never able to get it working.  I had a couple talks with folks on #webkit, and it seems to me that the windows port is not quite ready for prime time at this point.

There was a time when I was really worried that neither embedded XULRunner, nor webkit was going to work so I started thinking of alternatives.  The main ones I came up with were 100% XULRunner or embedded XULRunner using MFC.  I’m not really interested in either of those, but I guess it’s good to keep in mind.

The other timesink this week was another browser ploblem.  Drag and Drop stopped working on linux with xulrunner 1.9, mostly because they started doing error checking for the bogus values we passed in.  I spent a ton of time trying to get a good workaround, but in the end I ended up just checking in a patch that made our bogus values just a little less bogus.

This week I kept working on embedding xulrunner on windows with PyGTK.  I thought it was only going to take a couple days, and in fact I was almost there after two days, but then I ran into a huge tangle of focus problems.  Basically the focus is totally broken on my tests, it takes some random amount of clicking on the window to get the focus right, and I have no idea why.

I looked at the gtkmozembed source and remembered that they have a ton of hacks to get focus right.  Then I checked the moz-dev-embedding lists, and found out that most of those hacks don’t work on windows.  I’m trying to get in contact with some mozilla people, but in the meantime I’m pretty much stuck on the focus issues.

I think I’m going to just forge ahead and ignore this problem for now.  Hopefully I’ll get a good response and have a straightforward fix.  Otherwise, I can look into more radical measures like webkit, or just using XULRunner for all the UI stuff.  I don’t know, but right now I’m sick of trying to get those clicks working, so I need to move on.

So this week I mostly worked on experiments with getting Miro to work with native widgets.  Mainly I looked at if what I was planning to do was possible on windows.  This meant getting pygtk to work (simple), and trying to get xulrunner embedded in a gtk window on windows (a completely pain in the butt).  I’ve got xulrunner starting up and running, but I need a bunch of code to make embedding work.  Hopefully I can get that done in the next couple days.

I thought briefly about just using IE for the embedding, but it completely messes up the rendering of the miroguide.com, and I don’t think we want to have to support whatever version of IE people have installed on their machines.  I also thought briefly about sticking with xulrunner for the widget code, and it’s not totally out of the question, but I’m leaning towards using pygtk for most of the work and only using xulrunner for the actual HTML rendering.

At the beginning of the week I worked on a couple other things.  I made an emergency fix for 1.2.1 because the fix I added for that didn’t work for versions of windows without a newer service pack.  I’m getting really sick of the way that our app is packaged at this point, which is one of the reasons I’d like to switch to pygtk.

Also I worked on the sql database changes for a few days, basically it gave me something to work on while the widget stuff stewed in my mind.  I have code that’s close to checking in there, but I’ve stopped working on it for the moment.

I’m eager to get this widget stuff started, it’s going to be a very long-term project but hopefully we’ll have a fast, native feeling, and (even more) beautiful UI when it’s all done.

This week was pretty much all working on bug 9756. On Friday I tried to figure out what caused it, but without any luck. However, on Monday I asked some questions in the bug report and was able to figure out the cause. I spent basically all of today working on a fix.

The other main task I worked on was trying to implement switching between the different views that are in the new interface mockup with our HTML system. Eventually I just gave up on it though after talking a bunch with NPR and Andrew. As far as I can tell, it’s not possible without changing a bunch of things so I’d rather just wait for us to have widgets before we implement it.

Other than that I made the first baby steps towards the new database code, but I got pulled off of that pretty early on to work on other things.

I guess I’m going to be working on widgets now instead of Nassar. I’d like to talk a little bit on the call about how folks think we should go about this and especially if I should work on that first or the database stuff. Right now I’m leaning towards working on the database stuff first, because it’s a smaller project and I hope that the work will create a more flexible system which may help when I’m working on the widgets. Also, I was thinking that maybe I would just do the first step of the database work myself - changing it so that we use SQLite columns and tables - but hand off the work of actually switching our views to someone else.

I’m pretty happy that the 9756 seems to be fixed though, I would love to release 1.2.1 as soon as possible.

Last week I spent my time working on the fallout from my frontend-backend work.  It was actually not that bad.  Janet filed several bugs, but they all required one or two lines to fix them.  I also worked a few 1.2 bugs that I didn’t cause.

In between bugfixing I worked on trying to create a CLI frontend just to see if it could be done.  It was actually pretty straight forward.  That’s pretty exciting to me since it suggests it can be pretty easy to create alternative frontends.  Also I found out that the python cmd module rocks.

This week I hope to start on the database changes and do 1.2 bug fixing.