27 September, 2005
Slat without ClanLib, KDE without clothes
I got around to removing the ClanLib dependency in slat last night.
It really needed doing for a lot of reasons, but mainly because it was silly requiring a games library to run it, especially when it used a version much later than that supplied with most distros.
I'm a KDE user, so I very nearly went for an interface in KDE/Qt, but finally decided on plain X with imlib, for the widest compatibility.
Eugh! It's horrible dealing with GUI stuff at such a low level. I felt dirty looking under KDE's skirts.
Anyway, so far everything is going OK. I have a beta version (0.4b) for people to try, just to make sure this works in other places before I go any further.
One thing that's really annoying me is the behaviour of Imlib_paste_image. It seems to go very very strange for a while when it's first called. It does return, but doesn't necessarily do anything. And it messes with the timing of everything else. This part is commented out (on line 174 of theremin.cpp), so there's no extra cursor to show the rotating point right now.
Anyone that feels like it, please have a look. I'm a bit stumped. Just uncomment the line and see what happens.
You wouldn't use gnome for a standalone app, you'd use GTK.
It's just bloat and unnecessary dependency otherwise
also how about it only making sound if the mouse is clicked, and fading out when the mouse is released
more importantly though i compiled slat but it segfaulted immediately:
spark@stealth:~/slat$ ./slat
Segmentation fault (core dumped)
this is because the pics arent in /usr/share, you probably want to #define them out, and also check the error condition :)
other than that it looks cool
As for the SDL thing - It's worth thinking about if X doesn't start playing nice.
Oh, and I quite like the click for volume on/off, with fade idea. I hadn't decided what to do with the other mouse buttons yet. I wanted to use the scroll-wheel to cycle through other waveforms, but that's about it.
I'm also thinking about adding more configurable layers between actual and percieved mouse position - so you could specify an amount of lag, note-hugging, or inertia, for example.
i still think you need to #define the picture locations and other stuff in a config.h though, its dead easy, and you should always check return values for error, even if they should never occur in a correct install of the software
as for parameters, its a good idea, the program is a bit boring at the minute.
i'd probably bind loads of keys for increment/decrement of each parameter, with a primitive onscreen display, as widgets are a bit fiddly anyway (especially if youre using the mouse primarily for position) and you're not using any widget set. You could maybe do the onscreen display by toggling images like xmms does
And as for not trapping those errors - it's just an accident that there aren't more of them. This thing has just evolved and so far, quality control has been a matetr of running it and clapping when it stays on the screen.
I suppose the sensible thing to do now would be to hold features and really tie down what I have.
<< Home