Advogato blog for Alquimista

19 Feb 2003

Wed, 19 Feb 2003 05:15:06 GMT

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

Tue, 18 Feb 2003 13:07:57 GMT

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

18 Feb 2003

Tue, 18 Feb 2003 03:36:23 GMT

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.

13 Feb 2003

Thu, 13 Feb 2003 10:28:14 GMT

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}$!

27 Jan 2003

Mon, 27 Jan 2003 20:34:08 GMT

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

1 Jan 2003

Wed, 1 Jan 2003 12:11:42 GMT

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.

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.
Lines not on the same bounding box should not be tested.
Lines that may or not intersect should be tested first for intersection with a cheap algorithm before expending on finding the intersection itself.
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.

27 Dec 2002

Fri, 27 Dec 2002 01:40:58 GMT

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.

23 Dec 2002

Mon, 23 Dec 2002 19:59:10 GMT

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

Fri, 20 Dec 2002 16:45:25 GMT

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.

20 Dec 2002

Fri, 20 Dec 2002 03:56:45 GMT

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.