Teaser: Project NGtk - Native Gui ToolKit

Recently, I wasn't exactly active in GIMP and other projects. The main reason for that is an open-source university project I am doing as part of my studies, in the course Advanced Topics in Operating Systems. I believe pictures can demonstrate better than words, so take a look:

Click on the image to view it in fullsize

Project NGtk is an extremly light-weight library for creating GUI's on different platforms. It includes the following features/concepts:

• Has support for the following widgets and events:
• Button (stable)
• Labels (stable)
• Text-Entries (stable on 2 of 3 platforms)
• Windows (stable)
• Mouse up/down/click events
• Keyboard key type events, with translation from key code to ascii
• Works on the following platforms:
• Windows - Uses native Windows widgets via the windows API.
  For this backend, the only dependancy is the windows libraries which already ship with Windows.
• Unix/Linux Terminal - Any terminal which NCurses works on (which should be most modern terminals). This means you can also use this via SSH without X11-forwarding! Unlike many curses applications, NGtk includes full support for mouse cursor in the terminal.
  For this backend, the only dependancy is NCurses, which is shipped with most (if not all) modern linux distributions. NCurses supports a large variety of terminals.
• Xlib - Any operating system which has an Xlib (X11) client library. This means graphical Linux/Unix work environments.
  The only dependancy for this backend is an Xlib implementation, which is shipped with all modern graphical Linux/Unix environments.
• Gtk+ wrapper - Support planned for near future. This will practically be a simple API wrapper to give API consistent with other NGtk backends.
• 30 KB for the core library + 30 KB for each "adapter" (backend library). Just for comparision, Gtk+-3 is approximatly 4 MB (130 times bigger), not including it's dependancies.
• Written in C
• Object-Oriented structure - NGtk uses a very small C object system that was written as part of this project to make it easy to rogram, and without requiring C++. The object system is easy to learn and well documented.
• Display "Resolution" Independant - Forget the term pixel, as it doesn't exist in NGtk. Since NGtk is meant for a wide amount of platforms, such as the terminal (where a the smallest unit, a "pixel", can actually be a whole letter), NGtk will handle sizing of widgets itself. You can specify logic layouts, but no need to actually specify a size for widgets. There is a built-in interface for accepting custom made layouts (anything from grids, relative sizings, etc.), and writing new layouts is easy.

As you can see, NGtk doesn't have any real dependancy - the only dependancy it has is the existance of the graphical system that you wish to use. It is also not a replacement for Gtk+/Qt/etc. - it's targetted only at people who want very light-weight GUIs (both in features and in actual library disk size), and want to acheive maximal support. The NGtk goal is to achieve a state where every platform with a compiler will have an NGtk backend that will work on it without requiring any library which isn't already on the platform.

The first stable release of NGtk will happen this week when I hand in the project to my university. You can already find the project source by googling it, but I do recommend waiting for the official stable release.

Regarding my GSoC project: no I haven't forgotten. It won't make it in time for 2.8, but I will work on it as soon as I can hand in NGtk to my proffessor. Sorry to disappoint the people who wanted to see it soon, but it just won't happen...

Rescuing data from my dead laptop

Unfortunatly, my laptop's sort of "died" yesterday. The usual procedure in such cases is to rescue your data, and then send the laptop to a service laboratory. However, rescuing the data was a bit harder than I expected it be... I'm using a dell laptop with windows 7 x64, and here are the steps I took:

1. Create a Windows 7 system repair disc (using my brother's laptop)
2. Boot the laptop from the repair disc
3. Run Startup Repair - didn't help
4. Run Windows Memory Diagnostic - which produced the lovely warning:
   Hardware problems were detected. To identify and repair these problems, you will need to contact the computer manufacturer.
5. Complain about my crappy luck
6. Re-boot the laptop, and in the boot options menu choose the Diagnostics tool
7. After running the diagnostics, I got a more detailed error:
   Error Code 0123
   Msg: Error Code 2000-0123
   Msg: Memory - integrity test failed
8. Googling that error shows that it will require reinstalling/replacing of my (RAM?) memory

So, that wasn't so bad. The problem is now, how to get the data out? Here is where things became tricky:

1. Boot the laptop from the repair disc
2. Connect a USB disk on key (8GB, FAT32 file-system)
3. Open the command prompt supplied in the repair disc and start copying files
4. After filling the Disc-On-Key each time, I emptied it on my brother's computer

And here it all goes wrong:

1. Got an error of a file which is too large for the given file system. I had a 4.35 Gb file of a virtual machine hard disk (VDI file). The maximal file size for FAT32 file system is 4Gb-1b :P
2. Format the Disc-On-Key, and choose an NTFS file system
3. Copy the big file and continue happily :)
4. Got another error - file is too big. Got this for a 9Gb file which represents the hard disk of another virtual-machine.

Now, we have a problem. The largest USB storage device I had is 8Gb, and in this minimal windows recovery environment I don't have any tool to split files!

After some thinking, I remembered that 7zip can create a split-zip, i.e. one zip that is split to several small chunks. Even better was the fact that 7zip has a command line portable version! So I quickly downloaded it, and went back to my dead laptop to try it. But, it didn't work... Apparently, in the repair disc, the files required to run 32 bit executables over 64 bit machines are simply not installed, and the command line version came only in 32 bit...

After scratching my head, I went back to browse my homework folder from the operating-systems folder. I remebered that we wrote a splifile utility in C, which uses only windows commands (for example, CreateFile instead of fopen). But, my version of Visual Studio is the Express edition, and it didn't have the 64 bit compiler...

So, I downloaded mingw64-w64 and went to compile my program. After some struggles with problems regarding unicode programs (solved here), and some other problems, I finally managed to get it compile. I went to back to my repair-disc boot, and it worked!

It took me several hours to solve all this, but I finally managed to do this. I don't have many complaints to microsoft or dell - the diagnostic tools were really easy to use and the repair disc booted without any problems. It's just too bad that the people at microsoft didn't think a split file utility is necessary when trying to rescue data... Overall, I began this procedure with great pesimisem, and I finished with a smile and no lost data :)

Regarding my GSoC - this will prevent me from working several days this week, since it's still the last week of the semester, so I still can't sit in front of my desktop computer. I'll make up for the lost time later somehow.

My name is Antivirus. I hate Robots.

I have a confession to make - I’m using an antivirus on my Windows 7 computer. This word may seem unfamiliar to some Linux users who claim they don’t need it, and to some Windows users who claim that these stuff are viruses themselves. It never did any trouble, and it did save me several times, but today it was just an annoyance.

I was programming a game for the course I took in Computer Graphics. When I ran it, it exited before the first line of code and I got the following series of warnings:

The error messages

My first cynical thought was “Great! I programmed a virus!”. My brother’s reaction was “Wow – your code sucks so much that an antivirus recognized it as dangerous”. So, I rebuilt the executable (after the antivirus kindly removed it for me :P) and then I tried to scan it. The result was “No threats found”. I got the result for all the libraries and files used by my program.

After scanning lead to a dead end, I tried to comment out my code and remain with a simple hello world program (which still loads the same DLL’s) – and I still got the error message.

So then I tried to google for help about this error in my antivirus and I found out that it’s generated by a dynamic protection mechanism, which unlike traditional antiviruses, does not check the signature of my files.

So, what on earth was going on? An “Hello World” program which does nothing was causing a problem because of it’s dynamic behavior, while other programs which used the same libraries were OK? That does not make any sense.

Took me 30 minutes to figure this out:

• The theme of the game was robots. Since it was the Visual Studio version, the logical name for the executable was VSrobots.exe.
• The word robot is often used for describing certain types of viruses and malware.
• The only difference between this program and others which used the library, was it’s name.

So, I renamed the executable “HelloWorld.exe” and a miracle happened – it ran perfectly without any warnings from the antivirus.

Conclusion: Don’t name your executable files after things which may sound like viruses. Otherwise ****** Antivirus will block them :P

Note: I didn’t mention the name of the antivirus, to save some troubles that may raise because of it (mainly flame wars and other similar stuff regarding which antivirus is better – I have seen many wars like this in the web). Therefore, please refrain from posting the name of the antivirus in the comments, even if you recognize these dialog boxes.

Compiling (Pre-Packaged) GIMP on Windows!

Finally, after all the promises, I'm proud to announce that I finished the Guide for compililng (a pre-packaged version) GIMP on windows! The technique is using MSYS and MinGW, and without Cygwin - which means it's a native windows build!

What does it mean Pre-Packaged? It means a source package that you download from the website, and not the latest one from the version control system (Git in GIMP's case). Pre-Packeged version are not exactly the same you get from Git, and they passed an additional step that makes the compilation a bit easier. The additional steps for compiling the Git versions will be posted (hopefully) later this week.

On which version was this tested? On GIMP 2.7.1

The guide can be found here.
Update - fixed a small mistake which caused some stuff to be extracted to the wrong place.