What would you have done differently ?

I wrote this little utility a year or more ago in C. It's the first GUI application I even got to compile and do what I expected it to do on Linux or Windows. (I actually find it funny that my first successful compile of an application came on a Linux system) For the most part I just "winged it" through the whole project. I spent most of the time involved writing it looking for stuff which looked like it would help in GTK documentation and C manual pages.

SVN Trunk: http://code.google.com/p/picksel/source/browse/trunk/
Code to look at: http://code.google.com/p/picksel/source ... /picksel.c

It works. I've spent a good amount of time watching resource usage like a hawk to make sure it wasn't going to eat all of my memory. But I definitely winged it. There's a "3rd party" section with two functions emailed to me by someone who was having problems getting symlinks to work right, so I put those in there. I hadn't really "needed" them since I was always starting the application from the folder on my desktop, but it was nice to have them as they let me start using the application like a real application from my start menu.

In any event, anyone see anything they would have done differently ?
Why would you do it differently ?

If anyone's bored and would like to work on the project feel free to send me a PM.

I am no C pro but I do have a GTK project in distribution by debian (google seetxt at sourceforge for the homepage, for some reason ozzu is telling me I can't post links right now), which is pretty much the highlight of my programming career thus far .

Anyway, you may want to leave others a note about how to compile this, since I'm sure that there are actually real C pros around who simply have not worked with GTK and so will be unaware of the necessary linkage:


at least that is how I did it. Unfortunately, it seg faults right away. There are some warnings I imagine you are aware of:
warning: incompatible implicit declaration of built-in function...
many more of which will show up with -Wall. These are usually for GNU extensions, that is, non-standard functions that are part of GNU. You can get rid of the warnings by including the prototypes, eg:

The reason for this may be simply to draw the programmer's attention to the fact that these functions are GNU specific; I don't know if it has any further significance (but it may, so you might as well include them).

Also, I'd say use strtol() and not atoi(), atoi() is borderline depreciated for safety reasons.

The seg fault seems to stem from this:
Gtk-CRITICAL **: gtk_tree_view_set_model: assertion `GTK_IS_TREE_VIEW (tree_view)' failed
Which looks to me like a simple (lack of?) casting error, maybe in the next few days I will have more of a look thru to get it to work on my system (fedora core 10-64). From working on seetxt and testing it on various computers and having the debian people do the same, I know that C stuff can easily contain simple errors that slide by in one place (which is why you didn't notice and have to fix them) that then show up on system number two, or three, etc.

C programming is also definitely a real forearm work-out Makes you understand why they invented scripting languages. Anyway, it's probably a useful little project. Right now I use gcolorsel for this, which is slightly painful because I don't run gnome, and there is a crazy open file dialog that always pops up when it starts, and of course it doesn't magnify! So your alternative would be nice. Along those lines, one thing I would do differently is DON'T BILL IT AS UBUNTU GNOME. It seems to me this will work the same on *any* system with GTK. So call it a GTK app, most linux users understand that. For the ones that don't, you can add "compatible with Ubuntu/Gnome" since all gnome systems have gtk. But most "gnome apps" (such as gcolorsel) also integrate themselves in a number of ridiculous and unnecessary ways with gnome (I intensely dislike "integrated desktop environments" for this and other reasons) meaning you actually have to hack the system and/or source code if you want to use a gnome app in a non-gnome environment. So for people like me, when I see a phrase like "gnome application" or "written for gnome", unless I have absolutely no other choice, I just turn the page and forget it because it isn't worth the headache.

Anyway, my point there is that your app is portable beyond Ubuntu and gnome, so you might as well keep that clear for other linux users.

I just added a link to the SVN trunk where the makefile and glade files are. The compile string you posted is pretty much the same as in the makefile. I'm not sure whether you saw that before.

I labeled it for Ubuntu because that's what I have access to run it on and I don't know enough to tell whether it will run on anything else. I didn't want to say it will run on something I've never even used, let along tested it on.

I just now looked at this which went into a little more detail about atoi vs strtol. Good stuff.

I'll definitely have to look into that error you got there. I had a segfault happening when I clicked the X to close the window for months and never noticed it because I was expecting the application to close anyway and the settings had already been saved. I fon;y found it when I was starting the application from the terminal.

Ah. No, I didn't look at the makefile earlier. I've never used glade so I didn't realize it needed those xml files to compile (I assumed it created the source from xml). Anyway, it's all good now. Neat-o. I haven't played with it much yet, but thanks for that joebert.

If you want to use autotools to make add a configure/make/"make install" option for users who are used to that set-up, I can send you a few links that I used to figure out how to write the configure script for autotools, which there is not much useful documentation for IMO. Unfortunately, I can't paste them here right now due to my low post count ...