Fixing Qt appearance under XFCE 4.8 (aptosid)

On my aptosid setup running Xfce, Qt apps don't honor the GTK appearance setting without some help. The post at http://forum.xfce.org/viewtopic.php?id=5605 provides a solution that worked for me:

# echo 'export GTK2_RC_FILES="$HOME/.gtkrc-2.0"' >> /etc/profile.d/qgtkstyle.sh
# chmod 755 /etc/profile.d/qgtkstyle.sh

then logout and back in.

With Xfce taking on increasing importance since the introduction of GNOME 3, I hope this will work out-of-the-box in the near future.

frEDA SPICE 4: KiCad component repository

I have created a Mercurial repository for my KiCad SPICE component libraries at https://bitbucket.org/mithat/kicad-spice-library. At the moment it covers the same components as the PSpice library that ships with KiCad but renamed and drawn to be more consistent with IEC specs. I will add controlled sources and other SPICE primitives as time and necessity allow.

frEDA SPICE 3: KiCad components

KiCad ships with a small library of SPICE components (installed as /usr/share/kicad/library/pspice.lib  in Debian). It's nice that it does because it lets you do some basic testing with little investment. However the library has a couple shortcomings:

1. Many SPICE primitives are absent (e.g. controlled sources).
2. Some of the components could look better (i.e., more consistent with IEEE or IEC specs).

So, yesterday I began to implement a new library based on the existing one. As soon as it's anywhere close to complete I will publish it in a source code repository somewhere.

frEDA SPICE 2: ngspice

Out of the gate, my frEDA SPICE effort hit a small stumbling block. It turns out that (for reasons that are not clear to me) ngspice in Debian testing and sid is available only for amd64 and in stable only for i386. (You might also note that ngspice is considered non-free in Debian.) And of course I'm using testing i386.

So, time to compile. To get config to complete without errors, I had to install a bunch of {something}-dev dependencies, but once I had all the dependencies in place it seemed to compile and install just fine.

Next step, integration with KiCad.

frEDA SPICE 1: motivation

I've been getting back into analog electronics design, and related to that I've decided to try to use libre EDA tools as much as possible--an effort I've opted to call frEDA, for free Electronic Design Automation. The interpretation of libre in this context is, "as libre as possible for getting the necessary work done."

When it comes to circuit simulation, SPICE is really the only protocol that will work for my needs. So any solution I contemplate must be if not itself a SPICE implementation then at least fully SPICE compatible. And if there's anything like a classic libre toolset for this, it might be gschem from the gEDA project and the ngspice SPICE engine. (Lots of people seem to like gnucap as well, but it's not SPICE-compatible.)

gschem is capable of some really nice things, but I've decided instead to see how well a KiCad and ngspice pairing works. This is for two reasons:

1. gschem isn't officially supported on Windows--and while I use Linux as my main OS, I know plenty of people who (need to) use Windows.
2. Inasmuch as I have begun using KiCad for PCB layout, it would be nice to avoid having to learn and maintain a new schematic capture tool just for SPICE.

So, the current (pun!) workflow looks something like:

1. Pick a SPICE engine, probably ngspice.
2. Do some experiments to see if there are any nasty gotchas using it with KiCad-generated netlists.
3. Make a library of basic SPICE components for KiCad.
4. Frosting: Investigate tools for drawing SPICE generated output.

I will post updates as anything interesting develops.

Fixing CodeBlocks AVR build problems on Debian Wheezy

This might be a bit off-topic, but I didn't know where else to put this.

I spent a good part of this evening trying to figure out why I could build AVR projects in CodeBlocks using an old profile (i.e., personality) but not a new one. When I tried to compile with a new one (even on a different machine), the compile would generate a

/usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or directory

error.

By comparing the old and newly created profiles, I was able to figure out that new profiles were setting default include directories for building indiscriminately versus not at all for the old profile. The following seems to fix things, but to be honest I have not tested a wide variety of AVR builds nor have I tested any other kinds of projects. But I can't see why it should mess anything else up.

1. Open Settings > Compiler and debugger... > Global compiler settings
2. Under Selected compiler, select "GNU AVR GCC Compiler"
3. Select the "Search directories" tab
4. Select the "Compiler" tab
5. Select the /usr/include entry and click the "Delete" button
6. Right next to the "Compiler" tab, select the "Linker" tab
7. Select the /usr/lib entry and click the "Delete" button

AVR builds should now succeed. This fix should work with additional profiles you add as well as to the default.conf profile.

Lightweight Qt-based DE?

The last couple days, I've been wondering if it might be possible/worthwhile/stupid to build a Qt-centric lightweight desktopish environment. In other words, something to be to KDE what Xfce/Fluxbox/Openbox are to GNOME.

Today, I decided to do a bit of Googling and discovered Egg Window Manager, Qt Window Manager, and R Window Manager. I've yet to try any, but it's nice to know that there are people working on this.

Update [2012-01-12]: Reader CTown points out Razor-qt--a Qt-based desktop environment--is available as well. It's apparently a member of the QtDesktop project. It's worth pointing out that Razor-qt uses Openbox by default, and Openbox, while being a really nice WM, uses GLib--a GTK+ dependence. But maybe in combination with  one of the WMs above ...