-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Colin,
Am So den 3. Jul 2016 um 18:39 schrieb Colin Clark: > I am somewhat lost in understanding how this kind of development works > (I only worked on embedded micros - very different). Well, it works how it is best to archive. :-) If something is useful and have no downside, use it. In the other case, it depends. > What is the typical arrangement for development of an application that > compiles on both GTK2 and GTK3? Is it standard to maintain two separate > development trees? I do not have the knowledge to define the typical arrangement. I just see how other projects does and try to combine that with common sense and usability. So that might be good or bad. I might even fail that way one time or the other. Am So den 3. Jul 2016 um 18:50 schrieb Greg Troxel: > Colin Clark <ccl...@mcb.net> writes: > > What is the typical arrangement for development of an application that > > compiles on both GTK2 and GTK3? Is it standard to maintain two separate > > development trees? > > Generally, one or the other is enabld via something like autoconf and > there are ifdefs when necessary, with an attempt to minimize that. That is my idea too. > The reason I ask is because of all the deprecated warnings. For > instance, the GTK_STOCK_ warnings could probably be eliminated by simple > text substitutions. But that would not compile on GTK2. > > But to put GTK_CHECK_VERSION around every change would be a nightmare. True. But... > What is your opinion about how to progress? Am So den 3. Jul 2016 um 18:50 schrieb Greg Troxel: > A really good question :-) The problem currently is that GTK2 is stable and working fine and GTK3 has some bad usability problems but is needed for some new features. With that in mind I think, we should support both versions and in my opinion, there is no better way than the ifdef nightmare. Having two distinguish branches might be more clear but, as Greg already pointed out, it might be a nightmare to keep them in sync. It also makes it more difficult for users to compile one or the other version. A complete different solution would be to use a compatibility layer for every GTK call (that is different). Maybe that would be the way in the end if GTK3 stays that nightmare for long. That would mean to have a private name space for all GTK calls and "translate" them to the real library calls in different source files (gtk2.c and gtk3.c plus gtk23.h) and just use one or the other. But that would also be much work to do. Currently I tend to keep the ifdef way. But the private function name space has some potential and some elegances. I don't see a way at all in different branches. Long term that is not manageable. On the other hand, if GTK3 gets to a usable state, I would vote to drop GTK2. But I don't see that coming very near. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <kl...@ethgen.ch> Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Charset: ISO-8859-1 iQGcBAEBCgAGBQJXeV6pAAoJEKZ8CrGAGfas75oMAI5xZxwvETjsa7VKRVzxLF/Z 6U88hXbm+zXlTnbfc3RuD+0nt/VW7Vubv1Y+GOar6+1p2xqXTfLYdBwpBMvAn1JB OdG5FY/s0Po6F9LZmr7f7ehz8TVZ9PpSwmJBHuW1/eXCddncJUebw7PZxfsMuzxu 59t1+0NKfEkXbNRmhl7mJ8E6bK+ezjXZ/UdahCoMkF3oeqLkOIhxsdLso6VaKFNI TFQw8VuizRooDPUKojzpk/yAlrqYPOQzhlEGzXVsbGje3FZArdJxu/q1RsXHaqHx c6/nBXu4BgQvQAkRRUxQikgmehvuuvjMsq7EAWOfWYDFqhNgoMendPMMZQWKM3jT Q4adGNY+wkigE1W7EThKKF7w1XFY8v6ZIn3vS1CMNy9eTdLfTs8zYTlQ6t7c0XZi 4JkN++hUz4M5ffe/skMJnI1wue9Wy2tS8bHNqV8YcFrtHHZZnHGzmkiuCPPHA/O6 2PcYRcMi0MQE5o1Vx2OU4ZNefvQ4gYabNDHRRROpKw== =f9YC -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
