Go forward in time to September 2005.
When Oralia sets herself to the task of perfecting a dish, she succeeds.
Today she made pescado al acuyo for the third time, and it came out incredibly good. We have an acuyo plant in our tiny garden; it has big leaves that are the basis for the flavor of the green sauce. What made this time better than the others is that the fish was now wrapped in banana leaves for baking, rather than plain aluminum foil. I guess the banana leaves also added to the flavor. With a few drops of lime juice, it was perfect.
My wife is not a hacker, but she sometimes manages to find a hairy bug. She'll even photograph it.
Nov/21/2005 will mark the tenth anniversary of the GIMP. It was announced at 3:00 AM on comp.os.linux.development.apps and other groups. (Remember way back when Usenet was useful?) I feel like old people who don't remember their own birthdates.
Kids, come sit on Feddy's lap and he'll tell you stories.
The GIMP has been tested (and developed) on the following operating systems: Linux 1.2.13, Solaris 2.4, HPUX 9.05, SGI IRIX. Currently, the biggest restriction to running the GIMP is the Motif requirement.
A few more versions were released until the famed GIMP 0.54 release, which is the last version that used Motif. GTK+ didn't exist back then!
Future plans ------------ During Christmas break we encountered Photoshop 3.0 and discovered the "joy of layers". This functionality was deemed absolutely necessary and will part of the next release of the GIMP. This will involve major changes to many parts of the GIMP and is not expected to be ready for several months. The other major item being changed is a reworking of the interface (and perhaps the dropping of Motif!).
Before GTK+ existed, the GIMP used Motif. Since Motif was proprietary, the GIMP developers could not distribute it. So, they distributed a statically-linked version of the core GIMP binary. Random hackers without Motif licenses could only write plug-ins with very simple user interfaces: the GIMP cleverly exported some functions that plug-ins could use, and the core binary would draw a few widgets for them.
int dialog_id;
int row_id;
int frame2_id;
int row2_id;
int col_id;
int temp_id;
dialog_id = gimp_new_dialog("Page Curl");
...
frame2_id = gimp_new_frame(dialog_id, row_id, "Curl shading color");
row2_id = gimp_new_row_group(dialog_id, frame2_id, RADIO, "");
temp_id = gimp_new_radio_button(dialog_id, row2_id, "Use color color");
gimp_change_item(dialog_id, temp_id, sizeof(do_curl_color), &do_curl_color);
gimp_add_callback(dialog_id, temp_id, radio_callback, &do_curl_color);
temp_id = gimp_new_radio_button(dialog_id, row2_id, "Use background color");
gimp_change_item(dialog_id, temp_id, sizeof(do_curl_background), &do_curl_background);
gimp_add_callback(dialog_id, temp_id, radio_callback, &do_curl_background);
...
static void
radio_callback(int item_id, void *client_data, void *call_data)
{
*((long *) client_data) = *((long *) call_data);
}
After 0.54, a long time passed until the next release. Some people were getting impatient.
>Yeah! v0.54 has been around way too long now. >And the new development versions look so cool for >a few minutes and then they crash. >If these gimp guys are a bunch of sadists who >like to tease people to the maximum then they >are very effective at it. Well, it looks to me like the Gimp developers updated their Web page, although you shouldn't believe the "last updated" dates that they put up on there. They are hoping to get a new release out soon. Oh, and the 13 Dec 1996 developemnt version of the Gimp is also available (and doesn't require Motif! :*).
But even with the delay, others people were gracing the GIMP rave reviews.
I have been playing with that GIMP program and all I can say is that it rocks. We no longer ``need'' an Adobe Photoshop port to Linux. GIMP has it all.
I got involved shortly after the 0.54 release, and started writing plug-ins.
Note the following in the screenshot above:
In 1998, the GIMP got its own newsgroup.
Wow, a new newsgroup! I see no other postings, does this mean I'm the first here? I hope I can contribute in the future. I have used Gimp for about a year and now have a project going on. The purpose is to make a button generator accessable from the web where users can create their sets of images. I do this with the Perl-Fu.
Some early evidence of the GIMP in the making:
1995/Apr/06: Peter starts as a POV-Ray junkie. Weren't we all at some point?
BTW, the performance can be spectacular. There's a group of 20 hp 9000 workstations that we distribute to and images normally render in 3-4 minutes. I'm not talking simple images either. For example, the "not at all real" scene included with the pov distribution took 3 minutes to render in 800x600 resolution.
1995/Jul/16: Peter implements the basis of the GIMP.
Well, I'm currently writing an application that uses plug-in modules. The technique I use is to use pipes to handle communication and to use shared memory to pass large data structures back and forth.
1995/Jul/29: ... asks about features that people want in an image editor...
Suppose someone decided to write a graphical image manipulation program (akin to photoshop). Out of curiousity (and maybe something else), I have a few (2) questions: What kind of features should it have? (tools, selections, filters, etc.) What file formats should it support? (jpeg, gif, tiff, etc.)
1995/Aug/03: ... needs a larger monitor...
I need (want) one that can do 1280x1024 at greater than 75 hz.
1995/Oct/07: ... becomes an X junkie...
As an example of the speed you can get: I can get 45 fps at 640x480 at 16bpp on my p5-133 w/ Matrox Millenium under Accelerated-X.
1995/Dec/14: ... bashes Motif...
... the file selection dialog causes a seg fault ... Oh yeah, I've also check into other Motif's...they don't have this problem. (ie Static binaries work fine). If you are listening MooTiff people, this is not the way to keep customers.
And as an annoying teenager, I spent a good while trolling on comp.graphics.apps.photoshop.
If most people who are testing GNOME 2.11 are using jhbuild or other methods which are not a system install, then gnome-vfs plus HAL will get less testing that they should. Gnome-vfs is pretty resilient in that if it cannot initialize its connection to HAL/DBUS, it will fall back to using FAM-based monitoring for its volume monitor. With a default jhbuild, gnome-vfs won't be able to connect to DBUS since it will look for /home/foo/jhbuild_build_dir/var/run/dbus/system_bus_socket, which of course doesn't exist.
Heads up: I just updated gnome-2.12.modules in jhbuild to use these branches: glib-2-8, pango-1-10, gtk-2-8. So, a lot of things will get rebuilt. If you know of a low-level platform library that has branched but has not been updated in the jhbuild moduleset, please update it!
Jim King of Adobe has some great presentations on various topics like color management and PDF internals. The presentation on color management is particularly interesting.
I'm now back from vacation. The first few days involved moving to our new house. We had gone back and forth quite a few times in the car before that, taking with us books, CDs, and amorphous trinkets like lamps, flower vases, and clothes. This left only the big furniture to be carried over by the moving van.
Our house is just outside of Xalapa, close to the tiny town of Las Trancas. It's a bit closer to the port of Veracruz by just a few kilometers, but the weather here is actually different. We are at a slightly lower altitude than before: here, it is a bit warmer and a bit more humid. On Sunday there was a norte in Veracruz, or an incoming current of wind from the north. As a result, it has been raining the whole week.
My brother Axel came to visit all of last week. He is a resident doctor on his first year, so he has a metric shitload of work: taking this vacation was a good rest for him. He spent a good amount of time relaxing on our ridiculously comfortable couch and playing the guitar.
We went to Veracruz twice with Oralia. Veracruz and the surrounding areas always mean great seafood, good ice-cream, swimming in the sea, and basking in healthy doses of skin cancer-giving sun.
On Wednesday I took my brother for a day and a half to ride our bikes around the lovely town of Tlacotalpan. This is close to Alvarado, a fisherman's town where there is great and cheap seafood. Axel ordered a huge vuelve a la vida, or "come back to life", which is shrimp, oysters, crab, and octopus all together; it of course goes with hot sauce and lots of lime juice. I had a humongous arroz a la tumbada, which is red rice baked with seafood and epazote herb.
Riding around Tlacotalpan is quite pleasant. It is a little town where absolutely everyone rides a bicycle; you even see old people and very young children in bikes. It was too hot to do a long ride, but we still managed to reach a few minuscule towns with funny names.
The last time Oralia and I went to Alvarado, we found a wrecked fishing boat. By now it has grown plenty of vegetation in what used to be the deck.
Our house is in a very quiet neighborhood. During the day, you rarely hear a car go by. At night, you can only hear the crickets outside. A lizard will visit the house every now and then, and it will also take to visiting our couch.
Adrian Likins and a bunch of cool people have set up a wiki on troubleshooting and debugging on Linux.
Starting today, I'm going on a two-week vacation. I'll be back on Wednesday Aug. 24. During that time, Oralia and I will move to our new house or die trying. Also, we'll get a visit from my brother, which makes me really really happy.
I've spent a hectic week fixing cancellation in gnome-vfs, as it can leak file descriptors — some Novell software really doesn't like it if file descriptors remain open. I ended up massaging most of the code for asynchronous operations, and learned a lot about gnome-vfs's threading model in the process.
Gnome-vfs has support for cancellable asynchronous operations: you can request that a file be opened in the background, or that a directory be read, and you can cancel the operation if it is taking too long. For example, you could do this:
static void
load_directory_cb (GnomeVFSAsyncHandle *handle,
GnomeVFSResult result,
GList *list,
guint entries_read,
gpointer user_data)
{
GList *l;
for (l = list; l; l = l->next) {
GnomeVFSFileInfo *info;
info = l->data;
printf ("Got file %s\n", info->name);
}
if (result != GNOME_VFS_OK)
printf ("Finished listing\n");
}
{
GnomeVFSAsyncHandle *handle;
gnome_vfs_async_load_directory (&handle,
"file:///home/federico/large-dir",
GNOME_VFS_FILE_INFO_DEFAULT,
1000, /* items per notification */
GNOME_VFS_PRIORITY_DEFAULT,
load_directory_cb,
user_data);
sleep (5);
/* Took to long; abort the operation */
gnome_vfs_async_cancel (handle);
}
You can start async operations in the main thread, and cancel them from the same thread. Gnome-vfs uses a thread pool to run the actual operations in the background.
The problem with the old cancellation code is that it had a big race condition: if you canceled certain operations at certain points in time, the code could leave file descriptors open.
The new scheme is like this:
The GnomeVFSJob is the internal structure that corresponds a user-side GnomeVFSAsyncHandle.
Each job may have a running operation, which is its op field, and is of type GnomeVFSOp. If there's no running operation (for example, if the last operation already finished running), that field will be NULL. In the diagram, solid arrows indicate mandatory pointers; dashed arrows indicate possibly-NULL pointers.
You can launch a new operation by, say, open()ing a file, or requesting a read() on a file which is already open. The job creates a new GnomeVFSOp structure and puts it in its op field. It is of course illegal to launch an operation if a job is busy — you must cancel the running operation first. Each operation object has a field which points back to the corresponding job.
When a worker thread picks up an operation, it executes it. When it is done, it creates a GnomeVFSNotify structure which points back to the corresponding operation. It queues an idle handler (dispatch_job_callback() in the gnome-vfs code), which will run in the main thread. The idle handler will pick up this GnomeVFSNotify structure and let the user code know about the result of the operation. The job's op field then gets reset to NULL and the operation is destroyed.
The interesting part is when you cancel an operation in the middle. The only place where gnome-vfs can process cancellations without race conditions is back in the dispatch_job_callback() idle handler itself: that's when it can really knows that the worker thread is done. There's a mutex involved, of course, but the important part is that gnome-vfs must delay cancellations until the idle handler in the main thread.
When you cancel a job's current operation, it moves from the job->op field to the job->canceled_ops list. Later, the idle handler will notice that the GnomeVFSOp corresponding to a GnomeVFSNotifyResult was canceled.
A job structure is not freed until all its canceled operations have received the corresponding notification, that is, when the canceled_ops list has become empty.
I think I'm done with this patch, but as with anything involving threads, it needs a lot of testing.
In several places in GNOME, including the games which require several tiles with multiple frames for each tile (e.g. same-gnome animations), we store sequential frames in a long horizontal image. It turns out that this is inefficient, since the a single frame is likely to span many memory pages in the decoded image. OpenOffice's icon strips probably have the same problem.
Go backward in time to July 2005.
Federico Mena-Quintero <federico@gnome.org> Fri 2005/Aug/05 12:58:21 CDT