Recent blog entries for Alquimista

I should have known. I install KDE3.1 from CVS and the first thing that happens, Debian adds the first packages to testing.

18 Feb 2003 (updated 18 Feb 2003 at 13:18 UTC) »

Ha. And I thought it was going to be hard.

I won't lie: KDE is really complex. Waiting for it to compile would be boring if I had nothing else to do. But it was not really hard.

Resume: First thing I did was to clean my spare 3gig partition that I use to compile big things. Then I mounted it in /opt. Unpackaged qt there, compiled, ready; I can run designer even before the compile finished. Noticed that I had compiled it with the stock g++ of Debian testing.

Installed cvsup. Configured as indicated on the howto. arts didn't download at all. I was using KDE_3_1_1_RELEASE or something like that as tag. arts doesn't exist that way. Downloaded apart, using ARTS_1_1_BRANCH. Lost patience. Downloaded again kde-common, kdebase, kdelibs with KDE_3_1_BRANCH tag.

Recompiled qt after doing an 'alias g++=g++-3.2". It works, I can't say anything about secondary effects. Meanwhile, KDE refuses to preconfigure with 'make -f Makefile.cvs'. Resolved after linking ../kde-common/admin, just as says the howto.

Some hours later everything is compiled. Hacking together a .xsession finally KDE3 runs fine. But not without scaring me a couple times (that mean thing :)). To make it finally work, the .xsession ended like that:

export KDEDIR=/opt
export PATH=$KDEDIR/bin:$PATH
export KDEHOME=$HOME/.kde3

Probably one of this days I'll use HEAD tags...

Edit: added br tags

Installing a local KDE repository for development purposes, Day 1

First step: downloading qt-x11-free-3.1.1.tar.bz2 from trolltech. I wish myself luck and hope not to fill my hard drives before finishing the adventure.

KDE is great. Autocompletion out of the box (I mean, lineedit) is something good to have :)

On a not related note, recursion rules. $x_{n+1} = 1 + ax_{n}$!

Currently learning to program KDE. Close to porting to it: hacked together QTGears and a KDE tutorial, commandline and python extension work fine.

New year's day!

Here's the design for the intersection code. This is going to get more complex from here; keeping the code real clean is going to become a serious priority now.

  1. Intersection on 3d is very complex, but is going to have to be considered to future. Right now what's needed is a good 2d implementation, so I'll ignore the z coordinates for testing lines and will assign the average to the resulting intersection.
  2. Lines not on the same bounding box should not be tested.
  3. Lines that may or not intersect should be tested first for intersection with a cheap algorithm before expending on finding the intersection itself.
  4. Lines that are found to intersect have their distance to the cursor tested for a minimum.

Points one to three are easy to cache; such cache would then have to be updated after adding lines.

I'll take advantage of this chance to advertise a shameless plug to my project, Fandango. Testers are welcome, and anybody that can understand the current code is encouraged to improve into it, on particular on the python modules that are really easy to hack. I'll be available by mail to help, and the project page has already some basic documentation.

I've been reading about porting Fandango to libSDL.That will ensure portability and reduce the window code size. The problem is, the fonts library depends directly on XLoadQueryFont.

SDL_ttf is technically a good way to substitute it, but looks like the quality is not as good. I like better the crisp fonts that are produced by glXUseXFont.

Advantages. Replacing the window/keyboard/mouse management code for something much cleaner. Better event handling (?). Easier potential port to Win32 or MacOS X.

Disadvantages. Requires an extra library. Using the current font code requires pulling font data on an unelegant and less portable (read: still requires xlib) way. Probable hidden porting issues.

That's just planning, I'm not doing any real work before the holidays end.

Now that the END snap works for lines and line strips it's time to plan how to do INT snaps.

A naive approach to the problem would be to traverse all line-like entities, test for intersection and then test the results for distance to the click. With adecuate caching it may be feasible.

20 Dec 2002 (updated 20 Dec 2002 at 17:03 UTC) »

Well, I had a bit of fun testing the diary :)

I decided to make a call similar to cadget.clicks() called cadget.snaps() that returns a tuple [[xyz][xyz][xyz]] of the already snapped clicks. The clicks queue remains untouched.

Boring stuff today. I have commited the code to do vertex snaps in Fandango, but it still needs tweaks. It only finds a snap at a time. That complicates matters when drawing individual lines and having to snap both ends. I think that I'll do a parallel stack to iWindow::getClickQueue() that will return the snapped or clicked vertex instead of clicks only.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!