New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support CEGUI 0.8.x #10

Closed
Quintus opened this Issue Aug 20, 2013 · 102 comments

Comments

Projects
None yet
8 participants
@Quintus
Member

Quintus commented Aug 20, 2013

Currently, SMC only officially supports CEGUI 0.7.x. It’s time to move on!

  • Depends on #9

@Luiji Luiji self-assigned this Apr 13, 2014

@Luiji

This comment has been minimized.

Member

Luiji commented Apr 13, 2014

I'm actively working on this. Status update: the hardest thing so far is getting CMake to handle it correctly. I'm new to CMake. ;) I got it able to detect CEGUI 0.8.0 but it adds /usr/include/cegui-0/CEGUI to the include path instead of /usr/include/cegui-0. :(

@Luiji Luiji added this to the Version 2.0.0 milestone Apr 13, 2014

@Quintus

This comment has been minimized.

Member

Quintus commented Apr 14, 2014

If you want, I’ll do this later today for you (in a separate branch), then you have a definite starting point. CEGUI is a bit tricky to detect, because CMake doesn’t have a built-in find-module for it, so I turned one up from the Internet and modified it.

Sorry for not having worked on SMC the last few days, but the Heartbleed bug got me quite busy. All the new TLS keys and certificates took my week up.

Vale,
Quintus

@Quintus

This comment has been minimized.

Member

Quintus commented Apr 14, 2014

@Luiji, I’ve created a cegui-0.8 branch for you. There are already two commits in there you probably want to have a look at:

  • In e0a049e, I have completely rewritten the CEGUI detection module so it now uses human-readable CMake code instead of the spaghetti it was before. This still detects CEGUI 0.7.x, so we can use it anyway.
  • In 66348e2, I’ve updated that module to detect CEGUI 0.8.x.

Thereby I noticed CEGUI 0.8.3’s pkg-config file is broken; it says the CEGUI headers are in /usr/include/cegui-0/cegui, but in reality they are in /usr/include/cegui-0/CEGUI. This is an upstream bug that short be reported to them; I can do this in the next days.

Oh, and why do they have appended zeroes to all their stuff?? This looks weird.

The Falagard WR stuff seems to have vanished in CEGUI 0.8.x, so I commented the respective line in the CMake module out. If there’s an equivalent that needs to be detected, you can replace it accordingly or remove the TODO comment.

Vale,
Quintus

@Luiji

This comment has been minimized.

Member

Luiji commented Apr 16, 2014

Thank you for the help! I'll look more into getting the code updated tonight or tomorrow. I'm not sure why they chose to add the cegui-0 suffix, though.

As for the incorrect case in the include path, that explains why I couldn't get my versions of the CEGUI CMake scripts working. Weird.

@Quintus

This comment has been minimized.

Member

Quintus commented Apr 18, 2014

As for the incorrect case in the include path, that explains why I couldn't get my versions of the CEGUI CMake scripts working. Weird.

I’ve reported the problem upstream to CEGUI devs: http://cegui.org.uk/forum/viewtopic.php?uid=12544&f=3&t=6751&start=0

The CEGUI people use a weird combination of bugtracker + forum for bugtracking. The bugs forum is not linked from the website, but the bugtracker -- but the bugtracker doesn’t let you register. Unless you manually look into the forums, you won’t be able to even find the bugs forum. And registering with that forum requires you to surf CEGUI’s wiki and fill out one of these awful captchas. I really expected that my first post on the forum additionally is subject to moderation or so. They don’t want bugreports I guess. Bah.

Vale,
Quintus

@Quintus

This comment has been minimized.

Member

Quintus commented May 3, 2014

Upstream CEGUI has fixed the pkg-config issue with this commit on their development branch, i.e. it’s not in a stable release yet. Complete discussion is in the CEGUI forums.

Vale,
Quintus

@Quintus

This comment has been minimized.

Member

Quintus commented May 13, 2014

@Luiji, it seems they have moved Falagard into an own library: http://static.cegui.org.uk/docs/current/fal_man.html

Vale,
Quintus

EDIT: Forget that. I’ve misunderstood their documentation layout.

@AMDmi3

This comment has been minimized.

AMDmi3 commented May 13, 2014

You might want to check out this commit regarding CEGUI detection.
AMDmi3@83c9897

PS. SMC CMakeLists says that pkg-config is better way of dependency detection - I'll disagree with that.

CMake's building modules and custom ones (which are very simple to write, only FIND_PATH + FIND_LIBRARY are needed basically) work quite well and produce [full path to library] and [include path] which are easy to manage and may just be passed to TARGET_LINK_LIBRARIES/INCLUDE_DIRECTORIES.

pkg-config, though, produce mix of different entities (like -l foo -L /path/to/foo) which, being meaningless without each other, should be separated and passed to different commands. Additionally, these are later combined back with possible ill side-effects, like picking up wrong version of a library from -L path provided by pkgconfig output of unrelated library.

Needless to say, this issue is also a result of using pkgconfig.

@Quintus

This comment has been minimized.

Member

Quintus commented May 14, 2014

PS. SMC CMakeLists says that pkg-config is better way of dependency detection - I'll disagree with that.

The comment is outdated, relying only on pkg-config indeed is (currently) not ideal. Which is why I have written a module for finding CEGUI; it uses pkg-config as a base, but also uses find_path and find_library. The problem here was an error in CEGUI’s pkg-config file, i.e. something you cannot point to as being pkg-config’s fault. pkg-config’s goal is the unification of library and header detection so that it is not necessary to know where a project chose to place its headers as long as it provides a proper pkg-config file. Currently, this is far from being ideal, but I do think pkg-config’s efforts should be supported.

Your commit looks fine to me. As it refers to the cegui-0.8 branch, I think @Luiji should merge it.

Vale,
Quintus

@Quintus

This comment has been minimized.

Member

Quintus commented Jun 6, 2014

@Luiji, you said you got segfaults when trying to use CEGUI 0.8. Did you get these segfaults in SDL’s IMG_Load() function in conjunction with libPNG and weren’t able to properly resolve that problem? Today I ran into this, and it turned out to be an incompatibility of the SDL_image and FreeImage libraries that require different versions of libPNG. As a consequence, I dropped the FreeImage dependency and instruct CEGUI to use the DevIL library instead. Could you check if merging commit 8a3a36b fixes the segfaulting problem for you?

Vale,
Quintus

@Luiji

This comment has been minimized.

Member

Luiji commented Jun 7, 2014

I merged everything up, but it's still got a segmentation fault. For reference, here's the current GDB traceback. It seems to be a related problem, but related to libJPEG.

[nnn@nnn-optiplex-745 build]$ ./manage test
GNU gdb (GDB) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from testinstall/bin/smc...done.
(gdb) run
Starting program: /home/nnn/Documents/smc/cegui-0.8/smc/build/testinstall/bin/smc 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Initializing resource manager and core classes
Game data directory: /home/nnn/Documents/smc/cegui-0.8/smc/build/testinstall/share/smc
User data directory: /home/nnn/.local/share/smc
User cache directory: /home/nnn/.cache/smc
User config directory: /home/nnn/.config/smc
Warning: Preferences file '/home/nnn/.config/smc/config.xml' does not exist. Using default values.
Configuration file is '/home/nnn/.config/smc/config.xml'.
Translation locale is en_US.UTF-8
Translation support with gettext set to:
    Directory /home/nnn/Documents/smc/cegui-0.8/smc/build/testinstall/share/smc/translations
    Codeset: UTF-8
    Text domain: Secret Maryo Chronicles
[New Thread 0x7fffe6cbe700 (LWP 19630)]
[Thread 0x7fffe6cbe700 (LWP 19630) exited]
CEGUI log file is at '/home/nnn/.cache/smc/cegui.log'.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff1d8f0bc in jpeg_CreateDecompress () from /usr/lib/libfreeimage.so.3
(gdb) backtrace
#0  0x00007ffff1d8f0bc in jpeg_CreateDecompress ()
   from /usr/lib/libfreeimage.so.3
#1  0x00007fffe813a12c in SILLY::JPGImageContext::JPGImageContext() ()
   from /usr/lib/libSILLY.so.1
#2  0x00007fffe8139bd8 in SILLY::JPGImageLoader::loadHeader(SILLY::PixelFormat&, SILLY::DataSource*) () from /usr/lib/libSILLY.so.1
#3  0x00007fffe8138d38 in SILLY::Image::loadImageHeader() ()
   from /usr/lib/libSILLY.so.1
#4  0x00007fffe83401f5 in CEGUI::SILLYImageCodec::load(CEGUI::RawDataContainer const&, CEGUI::Texture*) () from /usr/lib/cegui-0.8/libCEGUISILLYImageCodec.so
#5  0x00007ffff7bcd69f in CEGUI::OpenGLTexture::loadFromFile(CEGUI::String const&, CEGUI::String const&) () from /usr/lib/libCEGUIOpenGLRenderer-0.so.2
#6  0x00007ffff7bcf512 in CEGUI::OpenGLTexture::OpenGLTexture(CEGUI::OpenGLRendererBase&, CEGUI::String const&, CEGUI::String const&, CEGUI::String const&) ()
   from /usr/lib/libCEGUIOpenGLRenderer-0.so.2
#7  0x00007ffff7bc0eec in CEGUI::OpenGLRendererBase::createTexture(CEGUI::String const&, CEGUI::String const&, CEGUI::String const&) ()
   from /usr/lib/libCEGUIOpenGLRenderer-0.so.2
#8  0x00007ffff77300df in CEGUI::ImageManager::elementImagesetStart(CEGUI::XMLAttributes const&) () from /usr/lib/libCEGUIBase-0.so.2
#9  0x00007ffff7732a8b in CEGUI::ImageManager::elementStartLocal(CEGUI::String const&, CEGUI::XMLAttributes const&) () from /usr/lib/libCEGUIBase-0.so.2
#10 0x00007fffe8546891 in CEGUI::ExpatParser::startElement(void*, char const*, c---Type <return> to continue, or q <return> to quit---
har const**) () from /usr/lib/cegui-0.8/libCEGUIExpatParser.so
#11 0x00007fffe9cffd1f in ?? () from /usr/lib/libexpat.so.1
#12 0x00007fffe9d00a1e in ?? () from /usr/lib/libexpat.so.1
#13 0x00007fffe9cfedb1 in ?? () from /usr/lib/libexpat.so.1
#14 0x00007fffe9cff53d in ?? () from /usr/lib/libexpat.so.1
#15 0x00007fffe9d029af in XML_ParseBuffer () from /usr/lib/libexpat.so.1
#16 0x00007fffe854566e in CEGUI::ExpatParser::parseXML(CEGUI::XMLHandler&, CEGUI::RawDataContainer const&, CEGUI::String const&) ()
   from /usr/lib/cegui-0.8/libCEGUIExpatParser.so
#17 0x00007ffff76cc184 in CEGUI::XMLParser::parseXMLFile(CEGUI::XMLHandler&, CEGUI::String const&, CEGUI::String const&, CEGUI::String const&) ()
   from /usr/lib/libCEGUIBase-0.so.2
#18 0x00007ffff77216af in CEGUI::Scheme::loadXMLImagesets() ()
   from /usr/lib/libCEGUIBase-0.so.2
#19 0x00007ffff77281bb in CEGUI::Scheme::loadResources() ()
   from /usr/lib/libCEGUIBase-0.so.2
#20 0x000000000069f674 in CEGUI::NamedXMLResourceManager<CEGUI::Scheme, CEGUI::Scheme_xmlHandler>::doExistingObjectAction (this=0x1132760, object_name=..., 
    object=0xd15590, action=CEGUI::XREA_RETURN)
    at /usr/include/cegui-0/CEGUI/NamedXMLResourceManager.h:425
#21 0x000000000069ece7 in CEGUI::NamedXMLResourceManager<CEGUI::Scheme, CEGUI::Scheme_xmlHandler>::createFromFile (this=0x1132760, xml_filename=..., 
    resource_group=..., action=CEGUI::XREA_RETURN)
---Type <return> to continue, or q <return> to quit---
    at /usr/include/cegui-0/CEGUI/NamedXMLResourceManager.h:287
#22 0x0000000000697015 in SMC::cVideo::Init_CEGUI_Data (this=0xa46790)
    at /home/nnn/Documents/smc/cegui-0.8/smc/src/video/video.cpp:151
#23 0x00000000005347ca in SMC::Init_Game ()
    at /home/nnn/Documents/smc/cegui-0.8/smc/src/core/main.cpp:261
#24 0x0000000000533f54 in main (argc=1, argv=0x7fffffffe318)
    at /home/nnn/Documents/smc/cegui-0.8/smc/src/core/main.cpp:173
(gdb) quit
A debugging session is active.

    Inferior 1 [process 19626] will be killed.

Quit anyway? (y or n) y
[nnn@nnn-optiplex-745 build]$ 

(For reference, ./manage is a script I wrote that contains some shortcuts to longer commands I execute frequently.)

@Quintus

This comment has been minimized.

Member

Quintus commented Jun 7, 2014

There’s still FreeImage somehow involved. Try deleting the entire build directory and compiling SMC from scratch; FreeImage is not needed anymore, and it may be the problem.

Vale,
Quintus

@Luiji

This comment has been minimized.

Member

Luiji commented Jun 7, 2014

@Quintus Figured it out. Didn't merge FindCEGUI.cmake correctly. Got my way up to a `CEGUI::InvalidRequestException. Commiting the modifications...

@Quintus

This comment has been minimized.

Member

Quintus commented Jun 7, 2014

@Luiji Your CMake module for CEGUI is still not correct... You have no image codec. Add the DevIL detection, maybe the error vanishes.

Vale,
Quintus

@Quintus

This comment has been minimized.

Member

Quintus commented Jun 7, 2014

I did so for you in commit f39539d. This is UNTESTED! I have no CEGUI 0.8 right now here, so please test if the DevIL codec is detected at all.

Vale,
Quintus

@Luiji

This comment has been minimized.

Member

Luiji commented Jun 9, 2014

Compiled but had no effect. The log gets spammed with this error:

CEGUI::UnknownObjectException in function 'CEGUI::Image& CEGUI::ImageManager::get(const CEGUI::String&) const' (/build/cegui/src/cegui/cegui/src/ImageManager.cpp:262) : Image not defined:

I think I just made a mistake in my usage of the ImageManager. Interestingly, it doesn't fail after spamming all these, it fails on this:

CEGUI Scheme Exception occurred : Failed to load module 'libCEGUIFalagardWRBase.so': /usr/lib/cegui-0.8/libCEGUIFalagardWRBase.so: cannot open shared object file: No such file or directory

It is completely correct that /usr/lib/cegui-0.8/libCEGUIFalagardWRBase.so does not exist. It isn't provided by the Arch Linux package. I'm not sure what the deal with this is but I haven't yet had time to look into it. I'll get to it soon.

@Quintus

This comment has been minimized.

Member

Quintus commented Jun 9, 2014

Hm, very mysterious. Here’s how the Arch Linux package is built: https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/cegui

As far as I can see, everything normal. The package shouldn’t miss anything.

Vale,
Quintus

@Quintus

This comment has been minimized.

Member

Quintus commented Jun 9, 2014

@Luiji, I figured it out. FalagardWRBase has been renamed to CoreWindowRendererSet. This had to be changed both in the CMake module (to find the correct library) and in the XML schema (to load the correct module). Commit dce86f6 does this now.

Note that I fixed a dependency error. We were depending on TinyXML, but as we already depend on libxml2, I figured that to be nonsense. I removed the implicit dependency on TinyXML and instructed CEGUI to use libxml2 instead. Please recompile SMC from scratch to not have any old cmake stuff flying around.

Vale,
Quintus

@Luiji

This comment has been minimized.

Member

Luiji commented Jun 10, 2014

@Quintus that commit got past that error. Now to deal with the fact that I haven't updated any of the .layout files to the latest format! :P

@Luiji

This comment has been minimized.

Member

Luiji commented Jun 10, 2014

@Quintus Still getting all of the error messages relating to images. However, we now abort here:

Setting up level player
Loading levels
Applying preferences
CEGUI::UnknownObjectException in function 'CEGUI::WindowFactory* CEGUI::WindowFactoryManager::getFactory(const CEGUI::String&) const' (/build/cegui/src/cegui/cegui/src/WindowFactoryManager.cpp:185) : A WindowFactory object, an alias, or mapping for 'TaharezLook/StaticText' Window objects is not registered with the system.
CEGUI::InvalidRequestException in function 'void CEGUI::GUILayout_xmlHandler::elementWindowStart(const CEGUI::XMLAttributes&)' (/build/cegui/src/cegui/cegui/src/GUILayout_xmlHandler.cpp:251) : layout loading has been aborted since no WindowFactory is available for 'TaharezLook/StaticText' objects.
terminate called after throwing an instance of 'CEGUI::InvalidRequestException'
  what():  CEGUI::InvalidRequestException in function 'void CEGUI::GUILayout_xmlHandler::elementWindowStart(const CEGUI::XMLAttributes&)' (/build/cegui/src/cegui/cegui/src/GUILayout_xmlHandler.cpp:251) : layout loading has been aborted since no WindowFactory is available for 'TaharezLook/StaticText' objects.

I'll look more into it later but we're definitely making progress!

@Quintus

This comment has been minimized.

Member

Quintus commented Jun 10, 2014

Seems we are jumping from on exception to the next one :-P

Vale,
Quintus

@Quintus

This comment has been minimized.

Member

Quintus commented Jul 2, 2014

@Luiji, as @datahead8888 pointed out to me in #100 (comment), we are approaching the feature-freeze date end of this month. Do you think you are able to manage CEGUI 0.8 until that? It would be very nice to have this in 2.0.0 as this is our major blocker that prevents SMC from inclusion into modern Linux distributions.

Vale,
Quintus

@Luiji

This comment has been minimized.

Member

Luiji commented Jul 2, 2014

@Quintus I'll try what I can but I've been pretty busy so don't hold your breath. Any help would be appreciated. I'll see if I can fit a little more work on it today.

@datahead8888

This comment has been minimized.

Member

datahead8888 commented Jul 3, 2014

@Luiji, I just thought I'd say that I really respect your diligence with CEGUI, since it does not sound like a fun task but is obviously something that has to be done.

@Quintus Quintus removed this from the Version 2.0.0 milestone Jul 29, 2014

@Quintus

This comment has been minimized.

Member

Quintus commented Jul 29, 2014

Being realistic, we will not get CEGUI 0.8.x support in version 2.0.0. This is nothing bad, we will schedule it for later. This will be one of the first things I will go after once the 2.0.0 final is out.

In the meantime, I hope we can statically compile CEGUI 0.7.x in so we can provide packages for Ubuntu and other distros that don’t break other programs depending on the shipped CEGUI 0.8.x.

Vale,
Quintus

@Quintus

This comment has been minimized.

Member

Quintus commented Jan 10, 2016

You should be able to be more specific, the issues starts with glm >= 0.9.6

Ooh, nice! Thank you for the hint!

Quintus added a commit to Quintus/sfml-gui-test that referenced this issue Jan 10, 2016

@Quintus

This comment has been minimized.

Member

Quintus commented Jan 10, 2016

I expanded my example to include both a manual window creation and loading a window from XML.

Valete,
Quintus

@Luiji

This comment has been minimized.

Member

Luiji commented Jan 12, 2016

@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.

@Bertram25

This comment has been minimized.

Bertram25 commented Jan 13, 2016

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?

@akien-mga

This comment has been minimized.

akien-mga commented Jan 14, 2016

@Bertram25 I guess you'd need to revert to the official boost version in Debian unstable to get it in sync.

@Bertram25

This comment has been minimized.

Bertram25 commented Jan 14, 2016

@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.)

@muammar

This comment has been minimized.

muammar commented Jan 14, 2016

@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

This comment has been minimized.

Bertram25 commented Jan 14, 2016

@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.

@Quintus

This comment has been minimized.

Member

Quintus commented Jan 14, 2016

All fine, but please don’t do this again :-). This is not the Debian bugtracker :-)

Vale,
Quintus

@Quintus

This comment has been minimized.

Member

Quintus commented Jan 14, 2016

@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

@Quintus

This comment has been minimized.

Member

Quintus commented Jan 24, 2016

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

@tomboy-64

This comment has been minimized.

tomboy-64 commented Mar 7, 2016

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

@datahead8888

This comment has been minimized.

Member

datahead8888 commented Mar 7, 2016

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.

@Quintus

This comment has been minimized.

Member

Quintus commented Mar 9, 2016

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

@Quintus

This comment has been minimized.

Member

Quintus commented Mar 10, 2016

FYI, I have started the CEGUI porting work in the new feature-cegui-0.8 branch.

Valete,
Quintus

@Quintus

This comment has been minimized.

Member

Quintus commented Apr 6, 2016

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:

out

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

@Quintus

This comment has been minimized.

Member

Quintus commented Jun 29, 2016

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.

tsc1

tsc2

tsc3

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

@Quintus

This comment has been minimized.

Member

Quintus commented Jul 17, 2016

As of today with commit 60d7ecd, 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

@Quintus

This comment has been minimized.

Member

Quintus commented Jul 17, 2016

Also, as a note to those compiling the feature-cegui-0.8 branch: The build options have changed. ENABLE_NEW_EDITOR has been removed, and ENABLE_EDITOR now builds the new editor. Its not possible to build the old editor now. If unspecified at a clean build, ENABLE_EDITOR defaults to ON now rather than OFF.

When building the new head of feature-cegui-0.8, please clean your entire build directory. This will prevent possible problems with the CMake cache.

Valete,
Quintus

@Quintus

This comment has been minimized.

Member

Quintus commented Jul 19, 2016

The CEGUI 0.8.x port of TSC has been finished today. The branch feature-cegui-0.8 was merged into devel with commit 58a5440 and the feature-cegui-0.8 branch has been removed.

It is likely that I fiddle with the build system in a number of followup commits, but otherwise the change is complete. CEGUI 0.7.x is not needed anymore for compiling devel.

Valete,
Quintus

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment