Closed Quintus closed 8 years ago
@Quintus Based on http://sfgui.sfml-dev.de/p/docs/guide/hello_world the API looks much simpler than CEGUI. I'll need more investigation before I can make more definite opinions.
Are there many projects that use SFGUI? How do you feel about the support for it?
How do you feel about the support for it?
Well, support... SFGUI is moderately active developed according to its repository, and the API is relatively simple and easy. As for help, you can either ask on the more active SFML forum or on the specific SFGUI forum, which is not really active.
Btw. the SFGUI API reference is available online, I just didn’t see that one earlier. Though the real explanation is probably in the large number of example files.
Are there many projects that use SFGUI?
I don’t think so.
Vale, Quintus
If the forum is not very active and if not many projects use it, I'd be a little concerned about the level of support. It is, however, probably a much better choice than developing our own GUI system. If the CEGUI API is as complicated as you guys have said, the simplicity advantages also might outweigh the support concern.
As a side note, CEGUI has a GUI editor that simplifies a lot its usage: CEED. But of course, if the OpenGL renderer is broken, it's not particularly helpful for you :)
I spoke with exploit3r in the #sfgui chatroom. He said that GLSL (OpenGL shading language) can be used with SFML without a problem. He specifically said a lighting system (requiring a fragment shader) does not pose a problem. He also gave links to some resources we might consult for this (one of which is in SFML). See: #94.
Also, he said that SFML currently uses legacy OpenGL. However, he said they are planning on upgrading it.
I spoke with exploit3r in the #sfml chatroom.
I dare you don’t. You spoke in the #sfgui
chatroom, which is also there but much less active. However, you got your answers, so I don’t criticise :-). Just as a further note, post SFML-but-not-SFGUI-specific questions better in #sfml
:-)
He said that GLSL (OpenGL shading language) can be used with SFML without a problem.
Good. I have briefly glanced over your discussion with him and did not understand a word, so it must have been good :-). You know what you’re doing, so I leave that to you.
Also, he said that SFML currently uses legacy OpenGL. However, he said they are planning on upgrading it.
Good. As said SFML is actively developed, so this will happen some time. That should be enough. Also, CEGUI people have earlier pointed out to me my graphics card (or its driver), doesn’t support OpenGL 3 anyway :-). I was wanting to look for a new one anyway, so probably the time for that is approaching now.
As far as CEGUI is concerned, I still do not have an answer on the problem with the OpenGLRenderer. I can now file it as a bug on the CEGUI tracker probably so that it may be fixed in a future version.
Vale, Quintus
I have filed the OpenGLRenderer problem now as a bug against CEGUI: https://bitbucket.org/cegui/cegui/issue/1063/openglrenderer-on-linux-renders-cegui
Let’s see what happens.
Valete, Quintus
You spoke in the #sfgui chatroom, which is also there but much less active.
Yes, I lost the record of what I had logged into when I left without autojoining. I will update my two github issue tracker statements to note the correct channel.
Just as a further note, post SFML-but-not-SFGUI-specific questions better in #sfml
I originally said I was going to ask the question later, but exploit3r kept explaining things until I finally just asked my question.
@Quintus:
Also, CEGUI people have earlier pointed out to me my graphics card (or its driver), doesn’t support OpenGL 3 anyway :-).
You should probably keep that around so we can insure that TSC can still work on older drivers, since that's one of the biggest things SMC had going for it. ;)
Allegro's already on the new OpenGL API, but I don't really think it matters much. The new vertex array mechanism is faster, but right now the only time the function pipeline doesn't work is with ES.
I might grab the SFGUI source later and check it's complexity. The problems of inactivity could possibly be resolved if it's simple enough for us to just modify it to our needs as time goes along.
@Luiji there is some activity on the repository in a separate branch, see my link above. Also, the devs are around in the #sfgui
and #sfml
IRC channels and on the forums and answer questions related to SFGUI. So I wouldn’t label it dead in any way. Just not overwhelmingly active.
Vale, Quintus
@Quintus Sounds satisfactory to me. I should still take a look at the source code, anyway, since I can. ;)
Yes, doing so will be nice. Please report back :-)
Vale, Quintus
As discussed in #149, if we switch to SFGUI, we won't have to deal with questions about how Cegui updates the mouse cursor or how it rotates sprites to fix the sprite rotation issue we currently have in the level editor. Of course this should not be the deciding factor on whether or not to use Cegui.
If we do switch to something like SFGUI, whoever works the conversion might try to fix the issue in #149 if possible -- it would be a great way to "bring in" the new API.
Hi guys, what's the status on your GUI discussions? I know he's quite busy with other projects (OpenDungeons, ValyriaTear), but if you need some advice from an advanced CEGUI user, maybe @Bertram25 could answer you :)
Rémi Verschelde notifications@github.com writes:
Hi guys, what's the status on your GUI discussions? I know he's quite busy with other projects (OpenDungeons, ValyriaTear), but if you need some advice from an advanced CEGUI user, maybe @Bertram25 could answer you :)
We are currently about to complete our efforts to port TSC from SDL1 to SFML. Since that is a fairly large task for our rather small team, the complex task of upgrading CEGUI from 0.7.9 to the current version has been postponed until the SFML port is finished. I am however confident that we can complete the latter in this month.
It was my intention to tackle the GUI problem afterwards. We have not yet finally decided if we stay with CEGUI and will return to this question before actually working on the code (obviously). Since CEGUI has resolved a fatal bug that was pretty crucial to us1 we only have to investigate ticket #5002 to have CEGUI on par with other alternatives. Regarding that ticket I suspect that the problem simply is caused by our aged version of CEGUI.
In the TSC team, there is currently no member with CEGUI knowledge. What we thus would need is someone who contributes to the project on a losely regular base; otherwise it is easier for one of the existing team members to just learn one of the GUI libraries around. That might or might not be CEGUI. Please feel free to bring forward any arguments pro/contra CEGUI in this ticket. The current state of TSC shouldn’t be used as an argument, because it relies on the old CEGUI 0.7.9 and will need a rewrite anyway. We are thus in the comfortable position to chose the GUI library that looks best to us.
CEGUI’s documentation has improved since 0.7.9, and good documentation is a criterion critical to me as a new user. This includes especially tutorial documentation on how to get started with a library; a reference documentation does not fulfill that. I haven’t tried out CEGUI more than was required for reporting the bug I linked to above, so I haven’t checked if CEGUI contains such information, and whether this information is current and not outdated. Also, due to my work on the SFML port of TSC, I can confirm that CEGUI (0.7.9, but I guess this holds true for newer versions as well) works fine with SFML as the graphics library beneath it.
The other currently closest competitor is SFGUI3. I haven’t investigated it either, because the SFML porting efforts are more important right now.
If I was asked to give a preference right now, I would currently advocate upgrading CEGUI instead of switching to SFGUI or another competitor because that keeps separate what should be kept separate. SFGUI especially hard-depends on SFML and cannot be used if we ever decide to switch to another graphics library (again).
Further input is welcome.
Vale, Quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
Hi guys, :) If you choose to keep Cegui and need some hints about it, feel free to ask me or people on cegui forums. On the pro side, mostly, cegui 0.8 comes with an unified editor which is really nice to do the grunt work before making stuff cleaner on the xml level. On the con side, I would say that cegui config logic is smart but somewhat uncommon which makes it somehow harder to grasp at the beginning, and gui modding documentation can be somewhat tricky even if rather correct for such a project.
Regards,
Since datahead has volunteered to tackle the rather complex task #516 yesterday in IRC I have some resources free now. I’m going to write some minimal programs with SFML and CEGUI and see how it feels. It might be that I investigate some other tickets on the tracker first, though.
@Bertram25 thank you for your input. If any questions arise, I will come back to you. In the meantime you might be able to provide insight into these issues (in descending importance): #149 #462 #334 #54
If you find it worthwhile, you might join our IRC channel #secretchronicles
on freenode.net. That’s where we discuss most of the things before they make it to the tracker for peristance.
Vale, Quintus
Also, /cc @brianvanderburg2 as he might also have some input on whether to continue with CEGUI or switch.
Vale, Quintus
I had gotten the impression that when we chose SFML as an API, its ability to let us use SFGUI was seen as a positive in this decision.
I remember that @Luiji was one of the major advocates for leaving CEGUI in favor of some other solution. I think we really should try to get his input before making a firm decision to stick with CEGUI. If the documentation has improved, this may alleviate some of his concerns, though I'd be curious if he had additional ones.
Sticking with CEGUI does mean we will have to invest some tough effort in fixing #149, the icon mirroring issue. This of course is not a reason to abandon CEGUI; whoever does the CEGUI upgrade will be the best person to investigate this issue, since it requires deeper CEGUI knowledge.
cegui 0.8 comes with an unified editor which is really nice to do the grunt work before making stuff cleaner on the xml level
I assume you mean an editor GUI for creating game GUI layouts, correct? If so, I think this is a big positive, and some new people in the community might find it useful, too. Truth be told, though, I don't think most of the other programmers who were on the project in the last couple years would probably use this tool as opposed to editing xml files, but feel free to correct me.
If upgrading to CEGUI is not too tough this time, we would also have the option to switch to something like SFGUI later, though it still is rework.
@lambda-11235, what do you think?
Hi guys, :)
Just to say that I'm neither an advocate of CEGUI, nor against it, but if I can help... ;)
@Bertram25 thank you for your input. If any questions arise, I will come back to you. In the meantime you might be able to provide insight into these issues (in descending importance): #149 #462 #334 #54
Sure. I'll have a look now.
I assume you mean an editor GUI for creating game GUI layouts, correct? If so, I think this is a big positive, and some new people in the community might find it useful, too. Truth be told, though, I don't think most of the other programmers who were on the project in the last couple years would probably use this tool as opposed to editing xml files, but feel free to correct me.
Rather true, the editor is named CEED (CEgui unified Editor) as they call it. Seems @akien-mga already mentionned it. The good point is that the latest editor version is rather stable and was very useful for me, for instance, to do quick mock-ups, and finalize the GUI basic behaviour quickly. But in the end, once you're used to it, you always end up quick-checking the XML data to ensure everything looks fine.
This said, CEED and Cegui are still not included into Debian for instance (even if I offered several times to do it. I may end up providing self-made packages, I guess.), and I can completely understand if the documentation or the CEGUI logic is not straight forward.
This said, CEED and Cegui are still not included into Debian for instance (even if I offered several times to do it.
Please talk to @muammar then. He was wanting to package TSC for Debian and he is a Debian dev so he can actually upload packages to the Debian repos. At least that is how I understand it. Take a look at #448.
If so, I think this is a big positive, and some new people in the community might find it useful, too. Truth be told, though, I don't think most of the other programmers who were on the project in the last couple years would probably use this tool as opposed to editing xml files, but feel free to correct me.
I’m a pretty barebones UNIX commandline hacker, so that’s likely. I will take a look at it though, and I of course respect it if other people prefer GUI tools.
I had gotten the impression that when we chose SFML as an API, its ability to let us use SFGUI was seen as a positive in this decision.
Yes, in the sense that it opens up a wider range of possibilities. We now do have a choice. We didn’t have that before.
@datahead8888 Luiji currently doesn’t follow the TSC project’s tracker. If you want his opinion, please email him directly and give him some days to reply.
Valete, Quintus
Please talk to @muammar then. He was wanting to package TSC for Debian and he is a Debian dev so he can actually upload packages to the Debian repos.
We already talked a lot. :) He has already uploaded a package for Debian, but the package hasn't left the incoming/NEW queue, yet. (But I don't really know why.)
@Bertram25 the problem has been with the licenses of some fonts and stuff like that :(. Right now, I am working on the package¹ again because two days ago I got a reply from FTP masters. Hope this time CEGUI will be accepted.
@muammar Thanks for the news :D Mind if I have a go at a CEED package myself?
Just how much CEGUI code is there in TSC? I have the impression that converting TSC from CEGUI to SFGUI would be a lot more work than converting from SDL to SFML was. If this is true, I could definitely see an argument for upgrading CEGUI for now if it's not "too" difficult and putting the SFGUI question on the backburner until we feel we have more time again. We don't want to burn up all of our time on upgrades, or we will never accomplish our other goals.
Just how much CEGUI code is there in TSC?
The problem is that TSC uses some internal features of CEGUI that were never meant to be used as @Bertram25 has discovered in #149. Internal APIs are subject to change, so it is not unlikely that upgrading will also cause us a lot of work.
A year ago or so I wiped the use of CEGUI’s XML parser from the TSC code, which was probably a major problem in switching away from CEGUI. That drastically reduced the amount of CEGUI usage in TSC. CEGUI is now used for drawing GUI stuff as it should be, and (argh) for keeping game state (see ticket #30).
Vale, Quintus
I’m currently experimenting with CEGUI. Due to the CEGUI bug we found and that got fixed it will in any case be required to use CEGUI >= 0.8.5. Current stable version of CEGUI is 0.8.4, so this will (again) make problems for users of LTS Linux distros.
Valete, Quintus
Re-reading the CEGUI ticket I have to relativize this is a bit. The bug is caused by a new version of the glm (dependency) library. So if your system not only has an old CEGUI, but also an old glm library, it should work as expected.
I have written a small example using SFML and CEGUI to draw a window onto the screen: https://github.com/Quintus/sfml-gui-test
Please feel free to build this example with whatever versions of CEGUI and SFML you have at hand (it however has to be CEGUI >= 0.8.0). If you find that it works (i.e. doesn’t look upside down and minified) please report that to me. It works for sure with CEGUI 0.8.5 (current development version of CEGUI). The repository’s README contains instructions about how to build CEGUI from its Mercurial repository.
Valete, Quintus
I have written a small example using SFML and CEGUI to draw a window onto the screen: https://github.com/Quintus/sfml-gui-test
Builds and runs just fine on Mageia 5 x86_64 with CEGUI 0.8.4 (+ a couple patches but that should not have much impact) and SFML 2.3.1. I have glm 0.9.5.4.
@akien-mga That’s good to know. Thank you!
So the problem was introduced somewhere between glm 0.9.5.4 and glm 0.9.7.1. I’m going to update my repos README accordingly.
Vale, Quintus
You should be able to be more specific, the issues starts with glm >= 0.9.6: https://bitbucket.org/cegui/cegui/commits/dd3b82d Also CEGUI 0.8.5 should work with any glm version now.
You should be able to be more specific, the issues starts with glm >= 0.9.6
Ooh, nice! Thank you for the hint!
I expanded my example to include both a manual window creation and loading a window from XML.
Valete, Quintus
@datahead8888: I do follow the tracker, it just takes me a millennium to run through the tickets. ;)
If someone became fluent in CEGUI that would be all the reason you need to stay with it. The only other GUI frameworks I think any of us know are application frameworks like GTK+, Qt, FLTK that aren't really suited for the task at hand (theme-ing alone would be rather hellish).
This is a situation where knowledge is preferable to any sort of "library superiority." Go with what we know, the problem at the time is none of us knew any of them so I was trying to see if there was an easier-to-learn alternative. However, since @Quintus is already learning CEGUI, the results of his efforts will be the best judge of whether there's sufficient expertise to continue utilizing CEGUI.
Hey guys :)
Pinging @muammar in particular.
First of all, congrats for the cegui 0.8 package in unstable :D
I took the opportunity to create the files necessary for the CEED packaging: https://github.com/Bertram25/ceed
The package builds fine and ceed-gui is correctly found, but the following bug is encountered:
PyCEGUI package is missing! PyCEGUI provides Python bindings for CEGUI, the library this editor edits assets for, see cegui.org.uk. (exception: /usr/lib/python2.7/dist-packages/cegui-0.8/PyCEGUI.so: undefined symbol: _ZTIN5boost6python15instance_holderE)
Your environment doesn't meet critical prerequisites! Can't start!
It seems you are building the python modules according to the rules file so I'm not sure I get it. (I checked the package content and indeed, you are.) The thing is, it seem not to use the right boost version compared to the one you used for packaging Cegui. What version did you use? Do you know how we could sync the version used? I'll stop hijacking the issue now. ;) Any idea on your side? Can I open a bug against it on Debian?
@Bertram25 I guess you'd need to revert to the official boost version in Debian unstable to get it in sync.
@Bertram25 I guess you'd need to revert to the official boost version in Debian unstable to get it in sync.
Actually, it is what I used. I think I'll open a bug on the debian tracker. (And some other bugs can be closed as well.)
@Bertram25 thanks! finally all problems with licenses are solved now. I think you can open the bug in the bts. We could also discuss the steps that has to be followed to have it in Debian. Regards.
@Bertram25 thanks! finally all problems with licenses are solved now. I think you can open the bug in the bts. We could also discuss the steps that has to be followed to have it in Debian. Regards.
Sure, I'll do it right now. Sorry again to the whole TSC team for the issue hijack.
All fine, but please don’t do this again :-). This is not the Debian bugtracker :-)
Vale, Quintus
@Luiji I am just learning CEGUI so far as I need for being able to judge it. I will target SFGUI in a similar mannor afterwards.
Vale, Quintus
I took a look at SFGUI. It appears CEGUI’s documentation is actually better than SFGUI’s, and CEGUI has quite a lot of more possibilities. SFGUI also isn’t in ArchLinux’s repositories, but CEGUI is.
SFGUI does not allow to load GUI layout from XML as CEGUI does. On the other hand, SFGUI is much simpler to manage; CEGUI with all its provider classes requires a complex setup that SFGUI simply doesn’t have. SFGUI is C++11-only, and they force use of std::shared_ptr
whereas CEGUI seems to take a more classic approach.
What makes me feel uncomfortable with SFGUI is that their user guide does not guide you through the entire process of writing a GUI with it. Granted, they link to the HelloWorld example in their repository, but somehow this feels wrong. And then what they call a "user guide" appears to be a rather small document.
Styling with a CSS-like language appears to be a nice feature of SFGUI, but on a glance I didn’t see something related to it in their user guide. They might have an example in their repository, though.
Valete, Quintus
Hello,
for what it's worth, I am also interested in TSC supporting cegui 0.8.4. Once this is completed I would like to provide a package for the Gentoo distribution, as I'm hesitant to put another outdated version of cegui into Gentoo's tree.
With kind regards, Matthew
Once this is completed I would like to provide a package for the Gentoo distribution, as I'm hesitant to put another outdated version of cegui into Gentoo's tree.
We are always interested in getting builds for more Linux distributions. Let the team know if you have any questions on the builds or on our Cegui/SFGUI discussions.
for what it's worth, I am also interested in TSC supporting cegui 0.8.4.
It will most likely be CEGUI 0.8.5 due to the fatal glm bug in CEGUI (see discussion further above).
Okay. I take over this issue for now. Be prepared that it will take several weeks, I don’t have much time.
Valete, Quintus
FYI, I have started the CEGUI porting work in the new feature-cegui-0.8
branch.
Valete, Quintus
I am making progress. TSC now compiles and runs when linked against CEGUI 0.8.5. The TaharezLook scheme we used to use appears to have seen a general overhaul. Not everywhere to the better, the sliders (not in the screenshot) look awful for example. Screenshot:
The editor is not yet available in feature-cegui-0.8
, and it occasionally segfaults (namely on quit). Also there appears to be a mouse passthrough problem.
Valete, Quintus
Status report for those not following the commit log in feature-cegui-0.8
. A good part of the conversion is done, but as expected the editor is the by far most complicated part in the CEGUI 0.8 conversion. I am rewriting larger parts of it at the moment, but the editor basics work. What does not currently work is placing new elements into the level, but editing (some) existing elements works, as well as viewing info on them, saving, loading, reloading levels and such. The settings window has not yet been ported either.
As said, the editor is rewritten at core parts in this effort. As you can see in the screenshots below, the annoying bug #149 is fixed as a side effect of this.
That is, although there isn’t much activity in devel
currently, work on TSC is going on. Mostly in feature-cegui-0.8
. As long as I’m basically the only person working on things, it’s natural that I focus on one thing at a time.
Valete, Quintus
As of today with commit 60d7ecd1c40b397963c379614a5f6aaa91eb53fe, the editor has been completely ported to CEGUI 0.8.x. There are some bugs left though that I want to finish before looking further, though.
Valete, Quintus
Currently, SMC only officially supports CEGUI 0.7.x. It’s time to move on!