|
|
bad.png (49,086 bytes) |
|
|
Please do not use GTK for plugin GUIs. The toolkit is not suitable for that (and does not provide any pro-audio widgets to begin with). Plugins should be self-contained and since gtk is not relocatable, that's near impossible to achieve. Furthermore the GTK ABI is not stable and also depends on libraries which have no stable ABI (eventually also gcc4/5 if the code uses C++). Last but not least GTK2/3 cannot co-exist in the same memory space (nor can QT4/5) and with gtk4 on the verge things will only get worse. Also x-platform binaries (portable sessions) are a PITA with any of the "big" toolkits. This has been mentioned on the LV2-dev list every year now like x-mas and it's down to 12 remaining plugin-suites only. Please don't start new projects with a GTK or QT GUI. see also https://community.ardour.org/node/13030 and soon only 11 to go https://community.ardour.org/node/13994 Eventually Ardour will move away from gtk (though probably not gdk) at which point plugins relying on gtk-libs being available may stop working altogether. |
|
|
Just fix this bug. My symlink worked, unless I broke something else. If LV2 had a GUI API, I would have used that. But there is none. Sorry that I cannot roll my own UI. I need the text features. And the pugl has lacks support for any widgets. Also I think GTK should be considered as the native UI on GNU/Linux. The ABI compatibility issues comes from wrong mindset. Sure if you live in the closed-source world, you need to worry about these issues. But we are free open source software. Every distribution recompile all packages for each distupgrade. This also includes plugins. Pulling GTK support leaves a vacuum, until LV2 presents its own UI, rendered by the host. In ten years this may happen. But is it really needed. Can you explain what you mean by "Pro audio widgets". Knobs and switches are trivial to make in any "toolkit". Also different kinds of meters should be easy, just looking at the right standard for what you are trying to achieve (EBU, Peak, LUFS ...). I can even make them work with plane OpenGL. However, if you ask me to render a text label, or even worse, a text input field, I cannot. It just requires a too high degree of expertise in different writing systems, or maybe we do not need to support Psy's language. Luckily, the experts has done all that with Pango, which is used by GTK. So I would at least have a dependency to Cairo, Pango, Freetype, and Harfbuzz for doing the rendering correctly. Pango also pulls in Glib (1). And that is only rendering. I also need to position cursor in text using the mouse. So, I think I skip that part of the UI. Then, the user needs to choose samples from his filesystem, I need a file chooser. How can I populate that? What should it look like. If I use GTK, the user knows how it works. Maybe I have many control ports, that needs to be grouped, so layout is nice to have. With a fully implemented toolkit, I get that too. I want to develop audio plugins, not UI toolkits. Sorry. The one way forward: Use established toolkits. If we are not happy things should be discussed on the GTK list. Like making --enable-static work well can be a good starting point. If there are any performance problems with GTK, then there is a real issue. I think the UI is responsive, but there is a lot of event mangling in GTK, so maybe it is not very good in a real-time environment. (1) As expected, GTK already requires these. The full list required to compile my UI is '-lgtk-x11-2.0' '-lgdk-x11-2.0' '-lpangocairo-1.0' '-latk-1.0' '-lcairo' '-lgdk_pixbuf-2.0' '-lgio-2.0' '-lpangoft2-1.0' '-lpango-1.0' '-lgobject-2.0' '-lglib-2.0' '-lfontconfig' '-lfreetype'. |
- Anonymous
