debian breaks gourmet recipie manager

debian auto updater [the gnome panel and synaptic, apt-get,etc] keeps updating gourmet to a broken version.

the debian file out on the net for release 13.7-1 is STABLE. the latest version IS NOT. I cannot speak for windows, as GTK has SEVERE issues that crash gourmet in windows.[usually when importing, sometimes when exporting]

ALL feature work like they are supposed to in 13.7-1, however I don't believe this is the same version for windows.
UBUNTU has issues, use this for DEBIAN ONLY!! This may be why.

WHY the app wasn't written with Tkinter or variants thereof, as activestate offers multi-platform UNIVERSAL GUI py sources available is something to take up with the author. we have always know that implementing unix [GUI] on top of windows or OSX has its issues.This is where the MEAT of these bugs are,not the source, but GTK.

Check your tracebacks.You'll see it.

Im hoping GTK for linux isn't so buggy, but I have seen NASTY NASTY issues with gnome, so I cant say that for a fact.Personally, I think that use of X interfaces and widget sets on top work much better.This is how Tkinter is implemented.There are numerous book on the subject.

Im working on Delphi[FPC GUI] for this, but this will take some time.I need to understand the file formats first.I do know python and will try an implementation as well.Lazarus has better support on OSX and win32, if you can cross, which I can. [FINALLY.]

Its a KNOWN python issue with Tkinter in OSX.Forget who, I think apple, causes Tkinter to [runaway] the application.Python is implemented.

[open] Delphi would be our better bet.

Anybody know how to read the nutritional DB files? I know they are in typed format, just not sure how to read them.Also any PasJPEG,[ I know about the Lazarus IDE for this, I need it for command-line or console apps], hints or samples would help.I cant seem to implement PASJPEG at all, with any P compiler.

Dont get me started on C.[WHY not C/C++? OBJ C? .NET? ETC...]

Some know C programmers how to code, most dont.Looks like brainfuck language to me.Most of the C I have looked at either is buggy, poorly implemented or has NO logic.How you can code with no logic beats me.Dont ask for C unless you can write it.Again, Java, on your own, though I would not be opposed to it.

 Most basic libs are implemented on both C and P. Its the C programmers that have caused most of these heap or GPF errors in the past.A good programmer knows better. I hold nothing against someone who knows C well, but most people I know don't know it WELL.I never cared for it.

Im not using assembly, either, the goal of the project is cross-platform.

If you want it in C, as nowadays it is possible to use C or P libs interchangeably,do it yourself.

you can use C libs like so in Lazarus:

procedure addXtoY :external :clibs
['clibs' or whatever the command is, you see it with Pascal GTK implemented...]

I however, would not be opposed to linking in C code [like the following procedure] IF its documented properly. NO im NOT using GTK directly like that, because of the bugs listed earlier.that was an example.

anyone with ncurses help on C is appreciated, I understand FPC implements the same[as crt.tpu], but how do you get dialog boxes and such? [hence the need for ncurses to do a 'make menuconfig' on the linux kernel when compiling it]
Is this a variant of the TVision units expanded for UNIX? I know what TVision is, but its DOS console and x86 only.

anyone with console experience on OSX is welcomed, I've had issues with getting the console to update the screen correctly when using crt.tpu, and 'ncurses' Im told is invoked as crt.tpu on Lazarus/FPC.

Ideally I want a GUI, but you have to start somewhere.