I've been using Windows a lot more since I went to work at Medsphere, and the one thing that bothers me most frequently is the lack of a very useful terminal. I've got the Cygwin rxvt terminal installed, and it's been pretty good except that I sometimes have like three or four of them open and Windows doesn't have virtual desktops like I have on Linux, so it's a pain to find the terminal I want. But now I ran across this open source terminal app called Console. It supports tabs and works with any shell program, like the default crappy Microsoft shell or with Cygwin's bash. It also lets you customize the colors and the opacity of the window, which is not as big of a deal but possibly still of interest. (23:42)
So Mike Kestner was awesome enough to fix gtk# bug #79993 the other day. Everyone at Medsphere is so excited! (23:30)
Medsphere OpenVista CIS Open Source
Yeah, I know Pete and Brad have already posted about it, and both of them have said more about it than I really could, but I want to post anyway! The place I work, Medsphere, has released the source for the OpenVista CIS client. It's very exciting for me to be a part of this project and team, and it's great to get to work on open source software. I've had the privilege of getting to work with really awesome hackers (Anthony, Bailey, Brad, Cesar>, Jon, and Pete), getting to work with Mono and gtk#, and being able to do some hacking on GTK+ itself (next release should have some noticeable improvements for Win32!). Of course, as much as I've been learning and hacking GTK-Win32 internals, I would love to see all the hospitals using this software use it on Linux. :)
As Pete already mentioned, Medsphere is interested in hiring more gtk# hackers. As a fairly new person there, I think it's a great place to work and I think everyone there is really awesome. If you're interested in working somewhere in a Gnome/GTK/Mono type environment, email Pete or Brad. (03:56)
GTK is certified clean of adware/spyware!
Yes, I'm sure to everyone out there this is the great news you were waiting on the edge of your seat for the past few years. GTK is finally certified free of adware/spyware by Softpedia!
Tim Janik received an email from them, which he kindly posted to gtk-devel-list for us all to enjoy.
Your product "GTK+ 2.10.7 Rev A" has been tested by the Softpedia labs and found to be completely clean of adware/spyware components. |
I've been trying to do some Win32-related hacking in GTK. I got a couple theme patches for notebook rendering approved, and I've got a patch up for review that fixes an issue with windows not receiving enough expose events when they're being resized. Now I'm trying to understand and fix some issues related to modality and transience of windows. That's a pretty difficult bug though. Somehow I've managed to get Windows XP to have multiple titlebars highlighted as though the windows are focused, although only one of them is focused in the taskbar. I hate Windows.
I've also been fooling around with Ruby a little bit, and I installed Rails yesterday. I was initially deceived by its inclusion in Ubuntu's apt repository. Apparently if you want to use Rails on Linux, it's easier to just install RubyGems and install Rails and its dependencies through gem. The instructions on the RubyGems site was a little bit inaccurate for installation to your home directory, though. You need to make some environment variable adjustments:
export GEM_HOME=$PREFIX/lib/ruby/gems/1.8 export RUBYLIB=$PREFIX/lib/ruby:$PREFIX/local/lib/site_ruby/1.8 |
There are some problems with using the version of Rails that's included in Ubuntu's apt. Like missing very important features, like ActiveRecord and Initializer. (04:56)
Jean-Baptiste Note has taken my latest cross-compile build of GTK 2.10 and created a Windows installer. If anyone is interested, check it out! Thanks very much to Jean-Baptiste for that.
He points out that it doesn't work under WINE, but neither have any previous GTK builds for Win32 so I guess nobody will lose sleep over that. It apparently doesn't detect the version of Windows correctly or something and assumes that it is in Windows 95 or something. (02:25)
I've been looking into GConf a little bit, trying to figure out how best to optimize for things like metacity when they're starting up. I went ahead and implemented the batched queries interface that's described in the IDL sources but was never implemented for some reason, but that's not really the entire solution. It seems like there is something not happening as expected in the client-side caching when you preload some directory.
Metacity preloads keys from /apps/metacity or whatever, so you expect it will recursively preload all the keys. But when I trace the CORBA method calls I see something like this:
So, it looks like the client is not caching all the values recursively. I'm not entirely sure yet, so I'm going to investigate some more in the next couple days. (16:35)
GTK Win32 Cross-compile doc update
To anyone who is using my GTK cross-compile docs, there is a small update. The gtk.immodules file was incorrect and has been fixed. Thanks to Jean-Baptiste Note for catching this and reporting it. (04:05)
Brad Taylor and I have been working on getting GTK to cross-compile for Win32 on his system also. We found a couple places where my process only worked for my system but we fixed them and I've updated my docs so that hopefully anyone can reproduce this.
I've posted my instructions online now, because a number of people contacted me after my last post about this and were interested in building GTK for Win32 also. So, I would like to hear from people and find out if this worked for others. If you have problems with it on your system and find a solution, I can add that to the docs.
I also want to move this over to live.gnome.org sometime. That seems like a more appropriate place for it. I'll try to do that later this week.
Once again, a big thanks to Tor Lillqvist and everyone on #gtk+ who helped me with getting this stuff going. (01:06)
So I sat down and invested some time into building GTK 2.10 on Windows today, with help from Tor. I think Tor usually builds it on Windows using MSYS or Cygwin or something, but I managed to cross-compile from Linux and it seemed to sort of work.
There isn't really any good and up-to-date documentation online for how to build GTK on Win32, so I made a log of every step of my process so that this can (hopefully) be reproduced by others. We're never going to get any of the Win32-related bugs fixed if nobody can build it. :) So my next step is to start over from scratch in a different target directory and turn my log into something more concise (there are a lot of trial and error steps in my log where something didn't work and I had to go back and try something else). And there are a few steps where I had to hack configure scripts directly, and I'd like to be able to figure out real solutions to those steps. (08:17)
I've been getting back into Gnome related technologies recently, for various reasons. I started looking into Gnome's accessibility project, like ATK and atk-spi. It's pretty cool, I think. I had long ago started to work on a speech recognition interface for Gnome using CMU Sphinx and a Bonobo interface. It never got further than occasionally being able to recognize when I say "hello" and display a popup "Hello, world!" dialog. But it was cool. (17:14)
Also, as I mentioned before, I was doing some GObjectification stuff for Øyvind Kolås on Horizon, and I think I mentioned my GPGPU framework that I started. I didn't put too much time into that before because I was preparing for auditions mostly, but since the Dallas Symphony audition is over (and I didn't win!) I have more hacking time. I am planning to take the Kansas City Symphony audition, but I don't feel stressed about that in the way I did for the last three auditions. I think the Dallas audition really helped me chill out with audition preparation.
So I am inspired to get back to work on the GPU framework. I'm making a lot of changes in the design, although none of them are really all that major in how the framework will be used. Mostly this is abstraction stuff so that different backends could be plugged in (e.g., I'm working on a default OpenGL backend.. but you might make an OpenGL|ES backend, or even a DirectX backend if you were so inclined).
Since Øyvind is getting so far with the new canvas model for GEGL and is getting ready to work on integrating with BABL, I feel like I need to step up my work on this now and get at least some basic unit tests running. Hopefully I'll have something ready to upload into the Subversion repo soon (Gnome is about to migrate from CVS to svn, and should be finished with that migration by the time this is ready to upload). (17:14)
I'm hacking on my Gtk# app in Windows right now, because Visual Studio is amazing. I couldn't seem to get pixbufs to load from relative paths, because I couldn't figure out what the present working directory is on anything in Windows, so I started fooling with the resource manager. This is a very cool thing. You can put strings or images or whatever you want in there, then access it from your app as Properties.Resources.Foo. Very nice. However, if you're using images then they're obviously stored as a System.Drawing.Bitmap, and Gtk# wants to deal with things as a Gdk.Pixbuf. So here's a quick snippet of code to deal with that:
using System;
using System.Drawing;
using System.Drawing.Imaging;
public Gdk.Pixbuf CreateFromResource( Bitmap bitmap )
{
BitmapData data = bitmap.LockBits( new Rectangle( 0, 0,
bitmap.Width, bitmap.Height,
PixelFormat.Format24bppRgb );
IntPtr scan = data.Scan0;
int size = bitmap.Width * bitmap.Height * 3;
byte[] bdata = new byte[ size ];
Gdk.Pixbuf pixbuf = null;
unsafe
{
byte* p = (byte*)scan;
for( int i = 0; i < size; i++ )
bdata[ i ] = p[ i ];
}
pixbuf = new Gdk.Pixbuf( bdata, false, 8,
bitmap.Width, bitmap.Height,
data.Stride, null );
bitmap.UnlockBits( data );
return pixbuf;
}
|
So I started testing out Monodevelop for hacking on my resurrected Ludwig van. It's pretty nice, I think. Obviously it's pretty far from Visual Studio, but it's not bad. The big new thing in the latest release is the integration of stetic, the user interface builder.
Maybe I'm retarded, but I just can't ever seem to save time by using these UI builders. Glade was okay, but so far I can't figure out how to use stetic in any remotely useful way. In this respect, I don't feel that Visual Studio is much further along because its UI builder is pretty useless too. But as I said, maybe I'm just retarded. (04:42)
I started developing support for COLLADA in neoengine, in the form of a converter. Mattias convinced me that it's probably pointless and unwise to bother trying to make runtime support for it.
I'm taking the route of using Sony's COLLADA DOM library for now, at least as a starting point. I dislike the design of it, but it's the fastest way to get support.
One of the biggest motivations for this was knowing that NVIDIA's upcoming tool, FX Composer 2, is going to support COLLADA documents. This will hopefully give us a very excellent material editor, at least for Windows platforms. Depending on how they design it, it would be awesome if we can get it to run on Linux. This may be possible via Mono because FX Composer 2 is being rewritten in C#. It very likely may still be impossible, depending on what external libraries they P/Invoke to. Then there is also the other obvious issue that we don't have Managed DirectX on other platforms. (02:29)
I'm trying to help Øyvind Kolås out a little bit with Horizon, the little drawing app he's writing for the Nokia 770. I'm beginning by converting the code over to be based upon GObject right now.
The canvas tiling architecture might lay a foundation for future work in gegl, which is the main reason I'm interested in this. I have some a big interest in doing some work on gegl, but it needs a lot of foundation work done on it before I can really begin working on the stuff I want to do. First it needs a new imaging framework, which will involve integrating babl into it for pixel format/image space conversion, and integrating whatever new image tiling stuff is made into it. (08:20)
I've been hanging out at my mom's house in Texas during winter break, and I took some time to do some hacking on Ludwig van. I ditched the C source code entirely and have been rewriting it using C#. The beginnings of the music notation layout engine are working horizontally, but it's not doing any line-wrapping yet. There are still a lot of issues in the layout engine, but it's coming along. I have a lot of work to do on the glyphs, and that's going to consume an enormous amount of time. The glyph rendering itself is working flawlessly, and without a doubt the quality of the on-screen glyph rendering is much, much better than either Finale or Sibelius already (thanks to Cairo, of course).
I'm probably going to stop programming on it again for awhile, because I have a lot of stuff that needs some intense practice. I have to finish learning the rest of Bartok concerto next semester, and that's a bitch. But when I get Ludwig van further along, I'll start making more posts about it and show off some nice screenshots. (05:33)
A few days ago I finally received my 770 from Nokia. This thing is absolutely fantastic! I haven't had much time to play with it yet because I have been playing with the orchestra in Sarasota this week, and unfortunately have been driving back and forth almost every day. The screen on this thing is fantastic, and I had no trouble getting online using the 802.11bg adapter. Next stop: handheld Ludwig van! (21:38)
A few days ago I started working on a new GObject-based framework for doing general stuff on the GPU. It's in the very early stages so far, and basically allows render-to-texture and readback of the textures. It's not very portable yet, in a couple different ways. Right now the test programs require X11, and won't work on Windows or Mac. That's pretty minor, is easily fixed, and doesn't really matter that much anyway. It's also not very portable between different types of video cards yet, since it depends upon FBOs (and makes use of PBOs if they're available). And while I was at it, I don't check for support of rectangular, non-power-of-two textures since any video card that does FBOs and PBOs will also support that. So, basically this code will currently only run on NVIDIA cards.
I'm just now about to start working on the shader support. There are two possible approaches here. The first is to find the best existing shader and use it. The second approach is to have some general data structure describing the shader, select a shader target, and generate the source for it (GLSL, HLSL, ARBvp/ARBfp assemblies, etc) at runtime. This is sort of what libsh does, although since it's a C++ template metaprogramming library it generates the source at compile time. The obvious advantage of this approach is that you jump through a few extra hoops to write your shader, and it gets generated into any target you want and you don't have to write it multiple times. The obvious disadvantage is just that it's hard to implement, and that it conceivably doesn't generate the highest-performing shader code. For my purposes, I don't necessarily need the highest-performing shader code so this isn't a problem. However, I also don't care that strongly about the multiple targets. I'd be willing to write one shader a couple times to support different GPUs if necessary (e.g., one shader for SM3.0 and one for everything else). Also, I'd rather go with the easier-to-implement approach so I can have something working sooner rather than later.
This is my first step to World Domination! (05:05)
I finally got my first engine update in a long while into the cvs server. Hardware occlusion queries are now implemented for Direct3D and for OpenGL. I'll get a nice looking test program into cvs soon as well.
Right now I'm hacking on support for Xinerama multiscreen displays in Linux so that the device enumeration will be more sensible. Right now it's detecting my system as a single 3200x1200 display rather than two 1600x1200 displays. One thing that's really impressive is that I don't notice much of a performance loss when it's rendering across two monitors like that. I haven't tried it in Windows yet, but I know that using Direct3D you'll instantly get forced into software rendering mode if you use the second monitor (whether you're spanned across the two monitors or not). (16:00)
Fooling around with Mono and C#
I've been fooling around with C# some more. Microsoft sent me a copy of Visual Studio 2005 beta 2 on DVD recently, and I've been using Mono on Linux. I'm really interested in getting back to work on some music notation goodness, but this time using a better language. There's no way I'm going to try to use C. That's just stupid.
I'm totally cool with using C++, but everyone else I talk to thinks that's completely insane. I have no interest at all in using Java, and I am wanting to avoid using something like Python as well. I don't really know why that is. In every other language binding, GTK has really felt like just a "language binding" between C and whatever language it is. For some reason, Gtk# feels more integrated. (04:00)
Keeping my hands warm with C++ code
I always feel really cold at my office. Even now during the winter while it's snowing outside, our air conditioners come on. I guess the office would get sort of warm with all the computers here or something, but when air conditioning comes on during the winter, I get cold. Especially my fingers and my hands. What do I do to warm them up?
Another thing we have at my company is a plugin for Visual Studio called IncrediBuild. It distributes builds across the network so that all the computers in the office will compile your code. It's like distcc, but for Visual C++.
This really comes in handy to help my cold fingers. Whenever I get too cold, I do an often extremely unnecessary clean and rebuild of the entire project. This kicks the laptop on the left side of my desk into action, and with the extra workload its fans come on and start pumping out lots of heat through the vent on its right side. I just put my fingers up next to the vent. It's wonderful. (14:02)
Support for OpenGL Shading Language went into cvs several days ago, and it's working perfectly. I'm happy that's done. I started working on a command-line utility for working with chunk files and needed a nice way of doing argument parsing, so I started working on a template-based method of handling them yesterday. There are still a couple things in the design that need to be worked out, but it's mostly very good now I think. It fits very well with the existing application framework too. (21:50)
First off, I wrote a couple days ago about the new NVIDIA SLI technology that was revealed but I questioned whether it would improve more than just fillrate, like Alienware's Video Array technology. Well, I got a response to this question from someone at NVIDIA and he said it definitely will.
Next, I wrote about the new NVIDIA drivers for Linux yesterday. They installed easily, of course, and I've got GLSL codee almost ready for NeoEngine2 now. As soon as that's working, I'll post some results. (15:43)
I finally decided that SuSE is not for me. So I downloaded and installed Fedora Core 2. Since I used Red Hat Linux starting back around 5.0 or 5.1 all the way through Red Hat 9, Fedora seems very familiar to me. And I used Fedora Core 1 for awhile, and mostly liked it.
The most obvious problem is that it seems that Fedora and NVIDIA don't get along very well so far. Fedora Core 1 decided to ship Linux kernel 2.6.0, and NVIDIA's binary drivers hadn't been updated for kernel 2.6 yet. That was not too hard to work around using the minion.de patches. Now with Fedora Core 2 they have enabled the new 4k stack size in the kernel, and apparently the current NVIDIA driver release only supports 8k stacks. This time the solution is to recompile the kernel with 8k stacks, which is more involved than the last solution, or to use the "nv" driver, which sucks and is not useful for what I do, or to wait for the next release from NVIDIA, which isn't really an option either. So I built a new kernel with 8k stacks. So far I have still not been able to get the NVIDIA driver to work on this install though.
The next problem is beginning to worry me, because it happened in both SuSE 9.1 and in Fedora Core 2. The system seems really slow and laggy. Typing text results in a laggy cursor, the mouse pointer is moving very choppily, things like that. It happens when I'm doing anything in another window, like compiling my software or making some Oggs or even just downloading some files. Things that shouldn't be slowing my system down at all. This is an issue that did not happen on my Gentoo installation. The major things that have changed are the fact that I'm now using a 32-bit install instead of a 64-bit install, the fact that I've added a second SATA hard drive (the exact same model), and the fact that SuSE and Fedora have their own kernel configs. I'm going to copy my kernel config from Gentoo and try it out later in Fedora and see if that helps any. I already added the low-latency "preempt" option during the 8k stack build, but I see no difference yet. (23:53)