Quick Update - NGtk

To those of you who have read my previous blog post regarding NGtk, here is a quick status update:

• NGtk works. Tested the XLib and NCurses backends on several linux distributions, and tested the WinApi backend on many versions of windows. I have a calculator app working with keyboard and mouse support.
• Keyboard focus is crappy, in all backends. Currently, I just tell all the widgets to listen to keyboard events. This is not something that is hard to fix - an hour or two.
• In backends with custom drawings (XLib, NCurses), the widget state isn't considered when drawing (so the widget looks the same all the time (if it's visible)). Not a bug, but could use some fixing. Base code for fixing that is already there.
• Clicking on disabled Widgets in the WinApi backend causes the mouse event to pass to the parent container (instead of being sent to /dev/null). Does anyone actually care about this? Can this do any harm? Anyway, the nice guys at Stackoverflow suggested a solution that should be easy to implement (but it's not top priority at the moment).
• Removing widgets from their container isn't tested well enough. That's not a bug, but I simply can't gaurantee good behaviour

Also, here are some good things:

• It works!
• It doesn't crash
• It doesn't leak memory (take that Gtk+!)
• Valgrind is generally happy
• Did I mention that it works? :P

I handed in NGtk to my proffessor, which means I'm now on my own with this project. Expect release 1.0 soon (my submission was titled 0.99). For those who want to take a look at the API usage already, you can take a look at the tester program: main.c (forgive me for the ugly macro in line 204, there is already a way around it in the code on my computer).

It is useable already (you can get the link to the project homepage from the main.c link), but I deeply recommend waiting for me to solve the above technical issues.

By the way, I did 40 km of bicycling in the city last friday (October 14th) in the Sovev Tel-Aviv event. It's the first time I participate, and I really enjoyed. Riding the bicycle on the busiest highways in the country and then along the sea shore together with other hundreds of people, is a great experience. So, if you can participate next year, I highly recommend that you do so ;)

Lessons learned from Writing a RayTracer

As I promised in my post about finishing my ray-tracer, I'm publishing the math equations I used in order to save some time for other people, when doing the intersection calculations.

You can find the document here: The 3D Equation Sheet

And here is a list of ridiculously annoying bugs, that I encountered during writing the ray-tracer. Although some of these seem really trivial, I'll list them in hope that they will save you some time when you write a ray-tracer. Even though these seem trivial, I know that some of them are bugs that other teams also had.

Common Bugs:

• When you shoot a ray from the eye and find an intersection, make sure the item is actually in front of the eye and not behind it!
• When the ray from the eye intersects with a point, and you shoot light at the point, make sure the light is on the same side of the surface as your eye - so that you won't see light on the other side on opaque surfaces!
• When calculating the intersection with a cylinder, which has a limited length - if the first intersection is "too far" from the origin of the cylinder, the second intersection may actually be in range! So check both...
• Rays of light should be shot from the eye of the camera, and not from the image plane of the camera! (It matters when checking if an object is behind us or not)
• When building the plane where x=6, the equation is x-6=0 and not x+6=0. Trivial, but not noticing this missing minus wasted an entire day for me…

Some thoughts on hunting bugs (Software in General)

I don't tend to complain too much, but it was annoying as hell to track down this bug, so I though I'll share some of the joy with you =) This post is mainly for software users (not GIMP-specific) as it should give you an insight on how to track the exact cause of a bug, and so make better reports and make it easier for the developers to fix the bug =)

Developers may also enjoy this post - thinking about this bug and how I tracked it, it is in fact a very funny bug :D

Help Us Help You! A short guide on reporting (GIMP) bugs

Hello,

After a recent increase in the amount of bugs which are reported on the GIMP bugzilla, I thought it might be a good idea to give some helpful tips about reporting bugs in GIMP (and in general in most open-source programs) - these will help us the developers to help you:

• In case of broken functionality, please try to:
  
  • See if you can reproduce the problem. If you can't reproduce it maybe it's not a bug.
    Try different scenarios to reproduce the bug (i.e. try reproducing it with different images or with similar settings of the tools/plugins/etc.)
  • List the exact steps which are needed to reproduce the bug. If we don't have the steps, we won't be able to see the bug ourselves.
  • Tell us the exact version of GIMP (you can find it in the Help->About menu)
• In cases when GIMP or one of it's plugins crashes, we'll need more technical details about your system (in addition to the details about broken functionality):
  
  • The name of the operating system you are using, and it's version (for example "Windows XP service pack 3"/"Ubuntu Linux 10.04")
  • For advanced users: try to provide a stack trace. To do this, launch GIMP from the command line, with the flag --stack-trace-mode=yes. Now when GIMP crashes, you'll see a question in the terminal asking you if you want to print a stack trace. Print it and attach it to your bug report.
  • For regular users: Launch GIMP from the command line (if you know how to), and if any error is shown when GIMP crashes, attach it to your bug report.
    
• Enhancement requests are not bugs.
  If you have an enhancement request you can post it on any of the following places:
  
• GIMP Developer mailing list: (see this page for more details)
• GIMP Developer IRC channel: irc://irc.gimp.org/#gimp
• GIMP User-Interface Brainstorm blog (For enhancements/suggestions for the user interface only and not for general enhancements)
Enhancement requests can be filed as bugs, but only after they were approved as a feature that should be included in GIMP. To get feedback on your enhancement request, use the developer mailing list or the developer IRC.

Finally and most important of all: Check if the bug was already reported. Unless you are using a development release, it's very likely that the bug you encountered was already reported by someone else.
You can search for existing bug reports using the search form on the bugzilla page of GIMP. Try entering some key word related to your bug and see if it was already reported.

For more information about submitting bug reports to GIMP, see the GIMP bugs page.

For your convenience, here is a list of commonly reported bugs of the last month:

• Bug 623563 - Text tool crashes Gimp
• Bug 622608 - GIMP crashes when clicking any scroll bar from combo boxes
• Bug 606247 - Crash using rectangular select tool with fixed aspect ratio on Windows XP
• Bug 624089 - Copy-paste doesn't work (GIMP 2.6.10 - Resolved and fixed)

Thanks for reporting bugs and thanks for taking the time to read this post - it will help us help you! =)

Edit 13:27 IDT (GMT+2) 27.07.2010:
To make it clearer (as it was pointed out by peter sikking): The GIMP UI brainstorm blog is only for enhancement requests for the UI - i.e. ways to make the user interface better. It's not for general enhancement requests.