Fruitbox

It’s out, in a lot of places! Google it.
Voice selection is in, but ’save to mp3′ is still missing. Hopefully it’ll be there in the next release.

It’s out! Where? Head over to CodePlex!
http://www.codeplex.com/clipspeak

It’s out, ClipSpeak 0.9!
Head over to CodePlex to check it out: http://www.codeplex.com/clipspeak.

ClipSpeak is a lightweight text-to-speech tool that speaks text you copy to the clipboard. It’s small, and tries not to be in the way, keeping user interfaces and interaction to a minimum. I intend this to be a quick and easy tool to use when you need something read aloud.
Right now it just sits in the system tray’s icon area, reading whatever you copy to the clipboard with the currently selected SAPI5 synthesizer in the control panel’s speech dialogue.

I intend to have the first release up on CodePlex within the next month.

ClipSpeak at CodePlex

Flimag hasn’t had much progress since my last post. I’ve been poking around at this thing and that and thought about things now and then. This project is quite difficult, and requires much time, so I’ve decided to work on something else for awhile. Check out the post above!

So I’ve been looking at this thing and that, trying to figure out what to use for Flimag, and I found out that Windows Vista finally has a compositing window manager, Desktop Window Manager. With composition, windows are drawn separately into buffers, and this sounds like it could be very useful for a screen magnifier. I believe many of the Linux magnifiers use this methodology.

A Screen Magnifier Using “High Level” Implementation Techniques.
This is yet another great paper, not relying on DirectX overlays!

In Prolog, it is very easy to make a predicate that tests whether a string/list of given length is a palindrome, and thus, since we’re talking Prolog, this predicate can be used to generate all palindromes of a given length!
I wrote this in SWI-Prolog, and it depends on the lists library.
Call pal(Alphabet, Length, L), where A is a list of allowed symbols (the alphabet being the most obvious one), Length is the length of the palindrome and L is a palindrome fulfilling the constraints.
The idea is the following: For L to be a correct palindrome, we first check that L has length S, then we say that each element (letter) has to belong to the alphabet A, and finally we state the fact that reversing L will yield L itself, simple enough.

:- use_module(library(lists)).

pal(A, S, L) :-
    length(L, S),
    maplist(mymember(A), L),
    reverse(L, L).

mymember(A, E) :- member(E, A).

The predicate mymember is used so that maplist works the way it should.

The Keybuoy!
If you drop your keys in the water, they’ll float right back at you, this is the Keybuoy! (did I spell that right).

I laughed so much while listening to this:
Daily Giz Wiz 149: Keybuoy

So you want more visitors to your website, homepage, weblog, blog, blogsite, webpage, bloghomesitepage, whatever?
I got an answer to the question: Write about how to increase website traffic!

What a wonderful recursion.

Here’s a very interesting paper:
Full-screen magnification for Windows using DirectX overlays [PDF]
This is exactly what I’m after, so now I’m trying to decide which tools to use. Managed DirectX, SlimDX, OpenGL, …?

ZoomText 9 är för närvarande långsamt, trögt, söligt, segt, … sa jag långsamt? Vad gör man åt det? Man köper en ny dator med två, fyra, eller rent av åtta kärnor, och hoppas på att ZoomTexts prestanda ska förbättras, men det man möter är ingen trevlig syn.
Vid uppstart kommer ZoomText 9 att se till så att alla program som är igång (och de du kommer starta) inte kan använda mer än en kärna (CPU 0). Vilken smidig lösning på prestandaproblemet!
Jag kringgick detta genom att använda ett program som sätter processortilldelningen och ser till att inte ZT kan ändra det. Get and Set Affinity heter det.
Tillslut valde jag ändå att gå tillbaks till ZoomText 8, som verkar vara för gammalt för att ens känna till flera kärnor. Ha!

What is it?
Flimag (pronounced fly mag), the fast and lightweight magnifier is a screen magnifier for Windows. Right now it is just an idea.

What is so special about it?
Flimag is intended to be different than e.g. ZoomText and MAGic. Its main purpose is to be fast, responsive and compatible, providing a lightweight alternative for people who just needs a basic full-screen magnifier that is fast and works well with other applications.

Why not use what is available?
The big magnifiers out there certainly have many nice features, but they are slow, doesn’t keep up well with new technology, require immense system resources, and in addition to that they might disable graphics acceleration and maybe even secondary cores on multi-core systems. The architecture they use is old: There should be better options today.

How will Flimag do it?
The big magnifiers out there use custom device drivers they hook in between the GDI and the graphics driver, and I intend to stay away from that. I have not yet decided on a replacement, but right now I am looking at using hardware overlays. Doing so would have the benefits of very little overhead and working hardware acceleration (since that is what it uses anyway).

In what language will Flimag be written?
Probably C#.

Will Flimag be open-source?
Yes!

When will the development start?
Yes folks, this is the hard one. I have already been thinking about this project for about a year now, so who knows. Every now and then I am experimenting with something related to this, and that is the way it is going to be for a bit longer, until I feel I know enough about the underlying technology.

Do you have ideas? Suggestions?
Know the Windows API?
Know a lot about DirectX/OpenGL?
Contact me!

Those lists are everywhere.
So here is my take on the computer programmer/scientist one:

1. No one understands what you are saying (see point 4 for ONE possible explanation).
2. You realise it’s pointless to try changing the world, because you don’t have the source code.
3. When facing the concrete problems of daily life, you think to yourself: “If only this had been software…”
4. You sometimes speak in 256-bit Rijndael, just in case!
5. The following strikes you as funny in an odd way: See point 5.
6. Who would use Java and coffee in the same sentence?
7. You think of your life in terms of if-conditions…
8. …Wait! Switch statements might be more efficient in this case, really!
9. You make stupid lists like “You know when you’re been a computer programmer/scientist for too long when”.
10. When something is broke you turn to your trusty old debugger.
11. You immediately realise this is a binary number.
12. You know how to pronounce Knuth the ‘right’ way.
13. C# is your favourite key of music.
14. You think of how to hack your own IDisposable pattern.
15. You think this list ends at 15.
16. Or maybe not, cause there are 16 digits!
17. You occasionally use phrases like: modular decomposition and finite state machine.
18. When you do something wrong you realise you need to overlook your exception handling.
19. When you participate in any sport involving catching balls, you try to avoid the ball, because you don’t like exceptions.
20. You wonder if your body employs mark-and-sweep garbage collection.
21. You know it’s difficult to do two things simultaneously, but you do know that if you switch between them really fast no one will notice.
22. You agree on at least five points of the above.

Expand the list by commenting on the post!

One of the first things I did in C# was to rewrite an application that I previously wrote using C++ and the Win32 API.
It is a magnifier that works in a window of arbitrary size. It works by taking a portion of the screen defined by a square with the mouse pointer at it’s top-left corner (in my example, a 200 by 200 area) and copying it onto a form, stretching it as necessary.
This is what I did:
1. I create a new WinForms application in Visual Studio.
2. In the properties window of the form, make sure double buffering is enabled.
3. In the class public partial class Form1 : Form I add the following member:
private Bitmap bmp = new Bitmap(200, 200, PixelFormat.Format32bppArgb);
I also add an additional using-statement: using System.Drawing.Imaging;
4. Finally I override the OnPaint event to do what I want, and to cause an immediate invalidation of the form:

protected override void OnPaint(PaintEventArgs e)
{
Graphics pgfx = e.Graphics;
pgfx.CopyFromScreen(Cursor.Position.X, Cursor.Position.Y, 0, 0, Screen.PrimaryScreen.Bounds.Size, CopyPixelOperation.SourceCopy);
pgfx.DrawImage(bmp, 0, 0, this.ClientRectangle.Width, this.ClientRectangle.Height);
this.Invalidate();
}


Not very useful, but neat!
A bad thing right now is that the form continually repaints itself, despite the fact that this might not be needed. A possibility would be to only repaint the form when the mouse cursor moves, although that would cause problems with other things in the area that might change, a progress bar for instance.