Basically, they are planning to drop a bunch of linux stuff and focus on osx.
Fork is already planned, but I hope they revert most of the C++ code introduced in 1.4 .... It's silly to have cupsd requiring libstdc++ (i hacked it out once, but cups is a difficult beast that I try to avoid)_________________Check out my github repositories. I may eventually get around to updating my blogspot.

Thanks, now that I've read up on what's happening, it could be a fantastic development, if it spawns the right type of fork. But I guess CUPS is such a monster it could need someone BIG to sponsor it... here's hoping._________________If you have or know of a good gtkdialog application, please post a link here

"I consider C++ disgusting"
+1
Thanks very much for sharing your educated opinion about gtk1 and other commnets above

Speaking of C++, it seems to me that both QT and wxWidgets apps tend to become unbuildable very quickly once they become unmaintained. Have you guys noticed this? Is it something to do with being written in C++, or is it because g++ or the toolkits or something just have poor backward compatibility?_________________If you have or know of a good gtkdialog application, please post a link here

Yes it is because of frequent changes in the C++ standard and/or lack of binary-compatibility between different versions of the C++ libs.

If you have a program written in C and compile it against a certain version glibc it will usually run on a machine with an older version of glibc within some limits or on a machine with a newer glibc. With programs that use libstdc++ this is rarely true. At compile-time, the differences in the code show up. Since I don't like or read much C++, these kinds of erros get on my nerves -I try to avoid stuff that uses C++ whenever possible.

If you look at the release notes for gcc (where libstdc++ originates), it becomes apparent. In nearly every release, there is some deprecation(s) and new compliant behavior that breaks code.

I'm not a C++ fan either ... Note its absence in the title
Glib has object code if that is all you want, but I have found uclibc++ without rtti or exceptions (otherwise you need parts of libstdc++) to be a good alternative for building C++ code to be much smaller.

I want to allow the gui interface to act as a server by only doing a printf to stdout for callbacks (callbacks are functions that get called when the user does something, or something occurs) and monitoring stdin for action events from the client.

This will allow a single generic interface to manipulate internal widgets from any programming language that supports streams (I can't think of any that don't)

The problem is that in C everything reads in as a long string, but I wanted a snippet that could read from stdin (user input or pipe or redirection) and parse the string into the same format as main's argc and argv so that I could use some of the same functions to operate on them.

Here is a snippet of what I came up with so far (note that multiple separators will cause the next arg to get skipped ... todo - until then only use 1 space, tab or newline)

Have you thought about using Peter van Eerten's gtk-server? It supports any programing language that can write and read fifo - and a slew of ther interfaces, including TCP. It also compiles to a gtk1 version. All gtk widgets are available. You just have to know how to call them. The URL is here: http://www.gtk-server.org/.

I have and I even ported some of the ksh and bash srcipt to work with busybox ash and hush, but you must know a lot about gtk in order to program with it. You may have noticed that I like to simplify things to the point where they are usable by the masses. The other side to what I am trying to do is abstract the basic widgets in such a way that I can use multiple backends (gtk1,2,3 and libagar are planned so far)

BTW agar is written in C, cross-platform and has a permissive bsd license (which works well for me since I do a lot of static multicall binaries and I am licensing all of my work as permissively as possible)

I can certainly understand glade users wanting to use xml files rather than compiling C code. XML allows us to separate the program's behavior from the program's appearance. It allows the coding team to work concurrently with the GUI team. It also makes visual changes a breeze.

I played around with bacon a bit, but found that I just hated the old basic syntax. But even old basic was better than trying to write GTK in proper C, with its horrid pointer syntax and casts. (for example, *(char***) yuck!)

So I reworked one of the bacon example programs (glade_demo.bac) into C, without the miles of wrapping code that bacon includes. Instead I abused the preprocessor and made an easy-to-read almost python-like syntax that anyone can live with. The bacon/tcc compiled executable for this program was 40K. The plain tcc version executable was 4K. (tcc also compiled it in less than a second)

Though if you're so concerned with speed and size of GTK, why not just use John Murga's murgaLua? FLTK is super fast and Lua's syntax and extensibility is first rate.

I can certainly understand glade users wanting to use xml files rather than compiling C code. XML allows us to separate the program's behavior from the program's appearance. It allows the coding team to work concurrently with the GUI team. It also makes visual changes a breeze.

so does gui-gtk.c but then you can also have gui-agar.c, gui-qt.cpp and gui-fltk.cpp... a proper make file will only rebuild the changed code, so recompiling is quick (one file is recompiled - the slow part, and then all the objects are linked - fast in comparison) one side effect is that the young programmers that typically get stuck with the gui parts learn "actual programming" through exposure - they actually can see the callback functions etc... and may realize - "hey all of these on_button<*>_clicked are basically doing the same thing - I could just use a generic on_button_clicked callback"

Quote:

I played around with bacon a bit, but found that I just hated the old basic syntax. But even old basic was better than trying to write GTK in proper C, with its horrid pointer syntax and casts. (for example, *(char***) yuck!)
.
So I reworked one of the bacon example programs (glade_demo.bac) into C, without the miles of wrapping code that bacon includes. Instead I abused the preprocessor and made an easy-to-read almost python-like syntax that anyone can live with. The bacon/tcc compiled executable for this program was 40K. The plain tcc version executable was 4K. (tcc also compiled it in less than a second)

Yes, pretty much every C programmer has the same complaint and the determined ones create their own form of low-level object system out of macros and/or a small library of functions

Quote:

Though if you're so concerned with speed and size of GTK, why not just use John Murga's murgaLua? FLTK is super fast and Lua's syntax and extensibility is first rate.

from my experience, fltk is not very good at building dynamic guis (kind of important for a gui toolkit, but maybe I just overlooked something) - it is left to the programmer to deal with low level stuff like resizing on a resize event, so it appears to be targeted at embedded environments where this is uncommon - except that fltk and libstdc++ would be much larger than glib+gtk1 or libagar (if you want to use xml, check out goingnuts' backport of gtkdialog to gtk1 - its extremely small and fast and should work in any scripting language, I use a multicall bash script - there is also a C example)

My personal reason for wanting as much as possible in C (besides it being a good learning tool), was that I wanted to build a large project of multicall binaries for the desktop. With gtk1, tinyx11 and uclibc, we can get all the default desktop apps into a single static binary in ~2-3mb (maybe less with some code refactoring and a single shell script for support) Compilers do not know what is in your XML, so any decent optimizations will lose code that is only used in the gui - so clicking a button may do nothing (unless you go through a lot of hoops). Compilers also can't automatically refactor common layout code used in every single XML file, nor have I seen any tool that does so.... I guess you could use the same UI file for all of them and only load a particular set of objects ... but then it would read unnecessary XML (unless there is some way to #include a file in XML?) The underpowered PCs that I have (I have several DECTops with the geode gx2 w/ 128mb ram) take a while to do anything, so even parsing large amounts of XML makes them sluggish. To me, its just simpler if it is all in C... its hard(er) for my 5 and 6 yr old to mess up a file system with a single statically compiled binary, and easier for me to restore if they do. (I also use it as my fall-back in case some part of my shared lib tool chain breaks while I am updating libraries)[/quote]_________________Check out my github repositories. I may eventually get around to updating my blogspot.

technosaurus, I also have a couple of DECTOP units -one of them is still virgin with the winCE system. The other one has Slackware installed. I adapted the original DOS system used for 'unlocking' the BIOS, so that you can restore the original locked system or unlock it.
In case you are interested, you can find my decTOP stuff here:
http://distro.ibiblio.org/amigolinux/download/AmigoProjects/decTOP/

I still have in mind to try installing my KISS linux on one of the decTOP boxes -I chose the i586 kernel and toolchain architecture just to be able to use the system with geode CPU, but have never checked to see if it was working...

Mark Tyler (the mt in mtpaint) forked gtk1 (as mtk) to use Xft and some other bugfixes/improvements here:
https://sites.google.com/site/mtpaint2/
however, the only version I can find is the latest version (mtk-0.5), which for whatever reason, he relicensed gpl3 (not lgpl3) but maybe someone has v0.3/4 around somewhere otherwise its not quite as useful._________________Check out my github repositories. I may eventually get around to updating my blogspot.

Nice find there -maybe. Perhaps wjaguar would know or could find out where older copies of the sources are. Barring that, scanning the ChangeLog or diffs against original gtk1 sources might point to some good stuff...

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum