I'm poking here at my gtk3 work and wondering about the least disruptive way to merge it in.
gtk2 and gtk3 are still quite similar so to me it makes sense to have a single set of gtk source files with a few ifdefs which can be built against gtk2 and gtk3 rather than say copy everything that is currently gtk into a new gtk3 dir and have them diverge quickly wrt. bug fixes. >From a "universal build" perspective (and similar to the current kde stuff) it would be ideal to be able to build and deploy both gtk2 and gtk3 vclplugs at the same time. Its possible, but really horrible, to trick dmake into building a dir twice with different compiler flags. That's likely to be hard to port to a pure gmake build system if that happens. So, what I was planning as the solution is to leave all the gtk files in vcl/unx/gtk and add a vcl/unx/gtk3 hierarchy of one liner .cxx files which just include the matching common "gtk" files but with different makefile.mks to build with gtk3 What I'd *really* like to do is to rename gtk to gtkcommon and add both a gtk2 and gtk3 hierarchy, moving the current makefile.mks into the gtk2 dirs, but that might be too disruptive for the sake of existing patches and merging in other work. It could always be done later anyway. The other option is just to go the ugly double dmake route, that works, doesn't need extra dirs added, and its only real failing is that its potentially not future proof. I'm undecided. The other broad changes would be that configure flags would change from --enable-gtk to --enable-gtk2 and --enable-gtk3. Enable_gtk2 would continue to generally default on like it does now, enable_gtk3 would default off. C. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice