Hi I don’t know if this has been discussed, but it seems that the interface has been a problem on different systems. Recently Trolltech released QT 4.5 C++/Java GUI as open source. Is it a totally stupid to suggest that changing the GUI to QT might be a direction synfig could go to? QT seems pretty polished and mature, thoughts?
Maybe not change but maintain an alternative parallel QT version. Do you want to start to code it? You’re welcome to do that.
-G
Hi!
I’m new here, and I’ve been using Synfig only for a few days (well, the last version. Used one a few years ago, but didn’t fulfill my needs). However, I find “GIMP-style” GUIs a bit irritating (in my KDE4, at least, I only have the document and the toolbar window in the tray, and when I click on them, the layers & cía doesn’t appear…).
Now I’ve found this post about a GUI change. What are those “platform problems”? Are them big enough to need a GUI library change?
I want to help, and maybe I can start with the QT port of synfigstudio, but if it’s not really needed, well, it may be a waste of time, and maybe I can help in other parts of the development.
Anyway, I think GTK it’s a bit limited in some aspects, and QT is a much better candidate for a big project like this, but I don’t want to start a senseless flame-war here!
What do you think?
Hi Uiomae,
We have so few developers working on Synfig right now. I may say that we have just one developer and the rest of us are just sending small patches here and there.
Develop a new GUI is not a trivial task. It is not just change the library calls from GTK to QT. There are lots of etl/synfig-core/synfigstudio code mixed/linked.
I think that the best thing you can do if you really want to create a fork of synfig in WT is:
- Understand how does the current GTK work. That implies to understand the whole code of etl, core and studio.
- Understand what are the weaks and the strenghts of synfig code to avoid to duplicate bugs and to keep the current good behavior.
- Then decide if a full rework of the GUI at QT style is doable.
ANY suggestion or help is always welcome. The collaboration to Synfig is really open to anyone.
-G
Hi Genete.
Thanks for your response!
I know that developing a GUI is not an easy task. I’ve developed a few GUIs in the past (mostly with wxWidgets, but that knowledge here is just stupid because Linux backend is also GTK, so…) and I only want to help 
.
A full rweork “QT style”, as you call it 
, is certainly doable. Toon Boom Digital PRO uses QT as GUI (and OpenGL), and they don’t seem to have any problem with it .
The major problem I see is the one you pointed out: GUI code is mixed with ETL/Synfig code, and that’s just bad. I’ve seen that GTK GUI code is in src/gtkmm, but anyway is very mixed .
As you have already worked a lot with the code, do you think that is there anything that can’t be done with the actual GTK GUI and can justify a rewrite? (I’m talking about the future planned improvements, here) If someone as experimented as you doesn’t see any reason for a rewrite, I don’t think I’m going to found one 
.
Wrong. I’ve not already worked a lot with the code. I’ve just read some parts of it and tried to understand how does it work. I don’t know QT and only have some references of gtkmm (what’s the library really used). I think it is more useful and efficient to implement OpenGL rather than rework the GUI. They seems to be similar effort (even less effort to implement OpenGL) and the result will be much more appreciated with the the OpenGL one.
I say that because it can be implemented straight forward to simpler objects and still leaving the current renderer for the final output. The real need is to speed up the GUI not to rework it. That’s my honest opinion.
Some people dislikes the multi-window style (Gimp style) and prefer a single window style (Inkscape). I prefer the GImp style because at the end it is more flexible.
Cheers.
-G
Sorry that I wrongly assumed that. I though I read something in the forums, but obviously I’ve been mistaken.
I don’t know what do you mean with “implement OpenGL” rather than reworking the GUI. Do you mean creating an OpenGL renderer?
My idea is to do the GUI on QT and the “playfield” in OpenGL, so we have a good GUI and a powerful renderer, best of both worlds, just like Toon Boom (sorry about the references, but I come from that world 
, and I comment it because it’s an idea that works, nothing else)
No problem. I came from Anime Studio world. 
By implement an OpenGL I mean to substitute the current GUI renderer for a OpenGL renderer. Obviously, due to the special kind of effects form Synfig the final render should be done like the current one.
-G
OK, so you mean doing the OpenGL playfield thing I mentioned. As I said, that was one of the ideas.
So if you think it’s more priority than redoing the GUI, I’ll go for it . I’ll take a look at the current playfield to see what have to be done.
Wow! It would be awesome if you do that!. Please open a new thread on that and post there any progresses/questions there (preferably in the “coding synfig” forum)
I’ll do my best on support you on that! 
-G
OpenGL realtime rendering at playfield have much-much-much more priority than any modifications of GUI! It will be so much appreciated by community if you will do that! Even if it will not be completed in nearest time, any efforts in that direction will be appreciated. 
P.S. I’m not a dev.
Ok, ok, I GET the idea 
Working on that, I’ll open the post suggested by Genete when I have something visible. I’ll be doing first some tests with the “manipulators” (the lines around selected objects) and later I’ll do the merging with the actual code. I’m thinking on doing the most GUI agnostic as possible, so the QT GUI would be a reality in a hope-not-so-distant future
Stay tuned!
Thanks a lot, Genete!
I’ve already have a local copy generated from my SVN sources (that reminds me, GIT source is not in sync with SVN :S).
I’m currently looking through NURBS documentation. It’s been ages since the last time I played with that stuff xDD.