MyGUI 3.2.0 Release Candidate 1

After almost year of constant work we are ready to announce MyGUI 3.2.0.

Download

Main improvements are new SkinEditor, improved LayoutEditor, simplified skin structure.
Detailed changelog:
----------------------------------------------------------------
------------------------- Version 3.2.0 RC1 --------------------
----------------------------------------------------------------

-- Core --
- Skin properties were simplified for more convenient creation in the editor.
- All widgets events is now multidelegates.
- Support of right mouse button drag.
- If MyGUI is built from svn revision log file also contain svn revision (in addition to version).
- Fixed bug with texture creation for fonts.
- Other minor additions and bug-fixes.

-- Managers --
- LanguageManager now replace tags recursively.
- Fixed bug in LanguageManager when missing language was selected.

-- Resources --
- Add Layout resource, layouts loaded and parsed only once at first use.
- All resource files now have "MyGUI_" prefix to avoid naming conflicts.

-- Widgets --
- VScroll and HScroll replaced with single ScrollBar class.
- Edit renamed into EditBox.
- List renamed into ListBox.
- MenuCtrl renamed into MenuControl.
- MultiList renamed into MultiListBox.
- Progress renamed into ProgressBar.
- StaticImage renamed into ImageBox.
- StaticText renamed into TextBox.
- Tab renamed into TabControl.
- New Window property Moveable.
- Message moved from Core to Common.
- MultiListBox now support different modes of columns resizing.
- Button properties StateCheck and ButtonPressed replaced with single property StateSelected.
- ListBox and ComboBox now support ToolTip.
- Menu items can be checked now, tick icon appears.
- Property AlignVert renamed into VerticalAlignment.
- Hidden widget lose input and focus.
- Active elements visualisation in list now properly respond to changes in the list.
- All text related properties was moved from Widget to TextBox.

--SubWidgets--
- All widgets now have Colour property that colours whole widget.
- RawRect subwidget was removed.
- Implemented PolygonalSkin sub widget for lines and splines drawing.

-- Tools --
- SkinEditor added.
- All skins created in SkinEditor.
- LayoutEditor now support projects creation.
- Possibility to create MultiListBox columns in LayoutEditor.
- Possibility to create PopupMenu\MenuBar in LayoutEditor.
- Colour selection window added in LayoutEditor.
- Show skin preview in LayoutEditor.
- Scaling support in LayoutEditor.
- Possibility to change widget's type in LayoutEditor.
- Possibility to add custom properties in LayoutEditor.
- Removed check for unique name in LayoutEditor (not required any more).
- FontViewer now same generated font in two formats: as ttf + xml that use freetype in runtime for texture generation and as manual font (texture and glyphs description)

-- Renders --
- BasisManager for OpenGL and DirectX now properly display Win32 window content without bugs with offset.
- Fixed memory leak in OpenGL's and DirectX's DataManager.
- Possibility to save texture in OpenGL.
- Fix typo in names vertext -> vertex.

-- Plugins --
- Awesomium plugin removed (not LGPL anymore).

-- UnitTests --
- New UnitTest for PolygonalSkin.
- New UnitTest for RotatingSkin.

There are still several things that need to be done for release:
* new screenshots;
* tutorial videos for editors;
* updated Berkelium plugin;
* may be some minor CMake tweaks;
* update website.
But code itself is ready for use.

Congratulations on the almost-release. I've been looking forward to this, especially for the new LogManager. I'm starting to play around with it with my project now, will hopefully have some feedback soon...

I've included below some quick notes I made when upgrading my project from MyGUI 3.0.1 to 3.2.0rc1. I hope they are of use to someone.


Things to rename:

ui->inject... => MyGUI::InputManager::getInstance().inject...

StaticText => TextBox
StaticImage => ImageBox
(a few others)

Widget::setCaption => TextBox::setCaption, Button::setCaption, etc.
Widget::getCaption => TextBox::getCaption, Button::getCaption, etc.

Gui::getViewWidth => RenderManager::getViewSize().width
Gui::getViewHeight => RenderManager::getViewSize().height
Gui::load => ResourceManager::load
LayoutManager::load => LayoutManager::loadLayout


Run your project and look for "deprecated" warnings. Replace the text as the warning suggests. Repeat until no warnings.

As a suggestion: Perhaps these deprecated calls could instead log a warning, call the corresponding new call, and continue? For example, "Gui::getViewWidth()" could log a warning and return "RenderManager::getViewSize().width". As it stands, a deprecation warning comes up during the build, and then the app fails to link. This makes upgrading harder, as you *must* change your code around before the app will even run. If the upgrade process is easier, more people will upgrade.

Some good news: I can confirm the combo of CentOS 5 Linux, nVidia drivers, OpenGL, Ogre 1.7.2, and MyGUI 3.2.0rc1 works fine. Demos run fine, so does my own project (once upgraded!).

Now some bad news: Severe regression with VirtualBox 3.2.10 (on CentOS 5) running Windows XP, (software) OpenGL. MyGUI 3.0.1 worked, but 3.2.0rc1 no longer does!

In this environment, the MyGUI 3.0.1 samples (and my project) work fine, albeit a little slow (this is expected). MyGUI 3.2.0rc1, on the other hand; all of the samples and my project come up with a white window, with black boxes where you would expect widgets to be.

Neither MyGUI nor Ogre seem to know what is going on; the logs report no errors (that I can see!).

Interestingly enough, the MyGUI demos work when using the (Ogre) software D3D renderer (but are hideously slow), but it doesn't help anyway as Ogre is unstable when using software D3D anyway (the Ogre samples crash, for example, and so does my project).

This is a bit of a blow for me, as one of the features that tipped me to starting with MyGUI is that it behaved well under software OpenGL. CEGUI, in contrast, just crashes immediately during initialisation if you try. The big plus of this particular environment to me is that it allows me to run and develop on multiple operating systems simultaneously (including Linux and Windows configs) with no need to reboot, and with snapshot support. This is really neat for testing and development.

In case it helps, I've attached the Ogre and MyGUI logs from an unsuccessful a run of Demo_Controllers.exe to this post.

If anyone is happy to take a look at this, I'm happy to help out where I can, or try some experiments. Remember though that I am still very much a MyGUI novice.

As a suggestion: Perhaps these deprecated calls could instead log a warning, call the corresponding new call, and continue? For example, "Gui::getViewWidth()" could log a warning and return "RenderManager::getViewSize().width". As it stands, a deprecation warning comes up during the build, and then the app fails to link. This makes upgrading harder, as you *must* change your code around before the app will even run. If the upgrade process is easier, more people will upgrade. Are you sure that deprecated functions doesn't work for you? Every deprecated function should give warning during compilation and that's all - because internally they call new function and everything links fine. Could you give linker errors, because we never had them for any deprecated function.

Now some bad news: Severe regression with VirtualBox 3.2.10 (on CentOS 5) running Windows XP, (software) OpenGL. MyGUI 3.0.1 worked, but 3.2.0rc1 no longer does!

In this environment, the MyGUI 3.0.1 samples (and my project) work fine, albeit a little slow (this is expected). MyGUI 3.2.0rc1, on the other hand; all of the samples and my project come up with a white window, with black boxes where you would expect widgets to be.

Interestingly enough, the MyGUI demos work when using the (Ogre) software D3D renderer (but are hideously slow), but it doesn't help anyway as Ogre is unstable when using software D3D anyway (the Ogre samples crash, for example, and so does my project).
As far as I remember there was no changes in MyGUI.OgrePlatform related to render process. Am I right that you use MyGUI.OgrePlatform with Ogre (what version, by the way)? I'll try to investigate what happened. Also did you changed anything else other than MyGUI version, for example Ogre/VirtualBox/something else. Just to be sure that changes in MyGUI caused problems.

Just a quick reply for now because it's late here and I'm about to go to bed.

Are you sure that deprecated functions doesn't work for you? Every deprecated function should give warning during compilation and that's all - because internally they call new function and everything links fine. Could you give linker errors, because we never had them for any deprecated function.

Yes. The functions were found, a warning was printed during build, but each failed when performing the final linking- the symbols weren't defined. When I moved them across to the new functions, the warnings vanished, and it linked correctly. One thing I noticed is that as I ported each method from old to new, the associated linker errors would vanish, until I had done the lot. The porting from MyGUI 3.0.1 to 3.2.0rc1 was done on Linux; I don't know if a similar thing would have happened under Windows. Perhaps it is a Linux-only thing?

I'll have another play with it tomorrow and report back on the specific linker errors (I'll port my code back the other way!) and some other details that may help. Now that I know that it was supposed to work, I can have a dig and see if I can find out why.

As far as I remember there was no changes in MyGUI.OgrePlatform related to render process. Am I right that you use MyGUI.OgrePlatform with Ogre (what version, by the way)?

Yes, with Ogre 1.7.2, built from source with a minor patch that removes a bug in DataStream handling (which shouldn't affect MyGUI, except in a positive way).

I'll try to investigate what happened.

Thanks.

Also did you changed anything else other than MyGUI version, for example Ogre/VirtualBox/something else. Just to be sure that changes in MyGUI caused problems.

No, no other changes. Host OS, guest OS, compiler, and VirtualBox have all been the same. The machine is disconnected from the internet so no strange upgrades that I don't know about. The only change to Ogre has been application of the patch above, but after that I fully rebuilt MyGUI 3.0.1 and everything dependent on both. The build steps are scripted so I can be sure I did the exact same steps each time. When setting up MyGUI 3.2.0rc1, I literally did a full rebuild of my project with MyGUI 3.2.0rc1, ported and tested under Linux, did a full rebuild, then went to Windows with the updated project code, built MyGUI 3.2.0rc1, fully rebuilt and linked it to my project, found the problem, checked out the samples, and realised that the changes had affected both my project and all the samples. I then went back and experimented with the samples in 3.0.1 and 3.2.0rc1.

However, one thing I'll try tomorrow is a full rebuild of MyGUI 3.0.1 on Windows, so if anything *did* change that could have broken it, it'll affect the samples as well.

VirtualBox is a free download if you want to have a play with it.

I don't suppose MyGUI had changed the way it does blending by any chance? Just a suspicion.

Incidentally, one thing I have done since my previous post is to build Mesa3D, and use the generated GL DLLs instead of the default Microsoft ones. When using Mesa3D (through Ogre), MyGUI 3.2.0rc1 seems to work fine (albeit very slowly, and it crashes on exit). So, at a guess, the problem is likely going to be one where MyGUI 3.2.0rc1 asks Ogre via OgrePlatform to do something that normally is perfectly reasonable, but for some reason fails with the Microsoft GL renderer. From experience, the Microsoft GL renderer is very finnicky, so I wouldn't be surprised if the fault was there somehow.

Also check your texture used for MyGUI skin if it is in General resource group (or same Group that used in MyGUI::OgrePlatform::initialise).

I found one chage in RenderManager that looks strange and might cause your bug. Open MyGUI_OgreRenderManager.cpp in MyGUI.OgrePlatform and in OgreRenderManager::doRender replace this two lines
mRenderSystem->_setTexture(0, true, texture_ptr);
mRenderSystem->_setTextureUnitFiltering(0, Ogre::FO_LINEAR, Ogre::FO_LINEAR, Ogre::FO_POINT);with A)
mRenderSystem->_setTexture(0, true, texture_ptr);
mRenderSystem->_setTextureUnitFiltering(0, Ogre::FO_LINEAR, Ogre::FO_LINEAR, Ogre::FO_NONE);or with B)
mRenderSystem->_setTextureUnitFiltering(0, Ogre::FO_LINEAR, Ogre::FO_LINEAR, Ogre::FO_NONE);
mRenderSystem->_setTexture(0, true, texture_ptr);

Okay, I have some further feedback:

Re the deprecated method linker errors on Linux, I got my code and changed just the call to "MyGUI::LayoutManager::getInstance().loadLayout() back to MyGUI::LayoutManager::getInstance().load()". Both cases compiled fine.

With: MyGUI::LayoutManager::getInstance().load(fname), this was the linker error:


ifmygui.o: In function `MyGUILoadLayout(MyGUI::Gui*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
/path/to/build/ifmygui.cpp:123: undefined reference to `MyGUI::MemberObsolete<MyGUI::LayoutManager>::load(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
collect2: ld returned 1 exit status


With MyGUI::LayoutManager::getInstance().loadLayout(fname), it linked fine.

Now I checked in the build dir, thinking it might just be a bad default?


> grep DONT_USE *
CMakeCache.txt:MYGUI_DONT_USE_OBSOLETE:BOOL=OFF


So the default looks okay.

The compiler version, if it helps:


> gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


...

Re the Windows problem and whether something might have changed, I completely rebuilt MyGUI 3.0.1 and tried the samples again- they all work fine.

I've also performed a fresh rebuild of MyGUI 3.2.0rc1 just in case, and the problem is still there.

Also check your texture used for MyGUI skin if it is in General resource group (or same Group that used in MyGUI::OgrePlatform::initialise).

I haven't made any changes from the defaults; either way I also tried the search-all-resources patch (see viewtopic.php?f=17&t=13937) and the behaviour was the same.

I found one chage in RenderManager that looks strange and might cause your bug. Open MyGUI_OgreRenderManager.cpp in MyGUI.OgrePlatform and in OgreRenderManager::doRender replace this two lines...

I'll check this out and let you know how it turns out. Thanks again for looking into things.

It worked!

I applied the first fix:

I found one chage in RenderManager that looks strange and might cause your bug. Open MyGUI_OgreRenderManager.cpp in MyGUI.OgrePlatform and in OgreRenderManager::doRender replace this two lines

mRenderSystem->_setTexture(0, true, texture_ptr);
mRenderSystem->_setTextureUnitFiltering(0, Ogre::FO_LINEAR, Ogre::FO_LINEAR, Ogre::FO_POINT);
with A)

mRenderSystem->_setTexture(0, true, texture_ptr);
mRenderSystem->_setTextureUnitFiltering(0, Ogre::FO_LINEAR, Ogre::FO_LINEAR, Ogre::FO_NONE);


And all the MyGUI demos all started working perfectly again!

I haven't tried it with my own project in Windows yet (rebuilding now!) but if it doesn't work the fault is probably in my code. UPDATE: It worked fine.

I haven't tried it on Linux either, but I'll give that a shot shortly. (UPDATE: It worked fine) I did have a quick look, and FO_POINT does appear in a few other places too (eg. in the LayoutEditor, the unit tests).

Thankyou for taking the time to check it out.

Incidentally, are you interested in my patch to allow you to optionally enable a search of all resource groups rather than just the default specified one? More details in this thread:

viewtopic.php?f=17&t=13937

And a 3.2.0rc1-compatible patch in this post:

viewtopic.php?f=17&t=13937#p78388

It could be useful to new users as something to try if they are having trouble loading in textures (because they're not in "General"), and if you need to load from multiple resource groups (like I do in my own project) it is quite essential.

Ok, I commited change in _setTextureUnitFiltering call, so in release everything will be fine. About your patch with resource group - see post in related topic.
Also I'll look deeper into linker errors today.

And thank you for feedback.

Ok, I commited change in _setTextureUnitFiltering call, so in release everything will be fine. About your patch with resource group - see post in related topic.
Also I'll look deeper into linker errors today.

Excellent news. Thanks for all of that.

And thank you for feedback.

No problem at all.

Issue with linking fixed now. So obsolete functions under linux now work as they should to: compile with warning and work through new function. Unfortunately there's no way to make warning more informative with gcc. With MSVC warning messages are more informative:
1> DemoKeeper.cpp(28) : warning C4996: 'MyGUI::MemberObsolete<MyGUI::Gui>::getViewSize': is deprecated, use : const IntSize& RenderManager::getViewSize() const

I can confirm that a subversion checkout of MyGUI from earlier today now works fine under software GL with no changes required, as well as under my Linux environment too.

With a slightly-more-recent subversion checkout I changed my code back to use "MyGUI::LayoutManager::getInstance().load()", and it compiled and linked fine under Linux. No more link errors.

One thing that I noticed though is that the deprecation attribute is disabled for Linux and gcc 4.1.2 in MyGUI_Diagnostic.h, which means no warnings on this setup. I commented out this test (ie. starting with the line containing "MYGUI_COMP_VER == 412", and leaving the "#else" case), and it gives deprecated warnings as expected, and then links successfully. I'd guess that "__attribute__((deprecated))" is fairly safe for gcc 4.1.2 on Linux, there were just problems with the templates earlier. I hope this helps.

Thanks again.

Congratulations! Excellent work, very appreciated. I will have to update my dependencies soon.

Sounds AWESOME
I'am looking forward to the final release - normally I would try it immediately, but in a team project like Xrodon II frequent library updates are a bit time consuming.

- Scaling support in LayoutEditor.

Does this mean scaling widgets and text to stretch fit in different resolutions?

Sounds really great BTW !!

EDIT: Oh it said EDITOR, not MANAGER... I was a bit quick there, nevermind

Thankyou for all of the excellent work on MyGUI.

As you've probably guessed from my posts and patches, I've been using occasional recent svn checkouts of MyGUI in my project, so I'm very interested in the official 3.2.0 release.

I was wondering what the plans were from this point heading toward release, especially as a few more things have gone into the subversion trunk since 3.2.0RC1. Is there likely to be another release candidate, ie. 3.2.0RC2? Would it be based on the subversion trunk or tweaks to RC1? Are there any features/functionality that you're looking to tidy up pre-release? What would the current guess for release date be for the official 3.2.0 release? Just a few random questions.

I'm definitely looking forward to the official 3.2.0 release. I hope it's all going well.

Hi. I'm testing mygui and so far it looks great. Have you guys considered relicensing it as MIT? It's not much of a change from LGPL with static clause and it would go much better with Ogre. I respect your decision of course but since it's the only big inconvenient I see with it I thought I'd mention.

Why LGPL is inconvenient for you? Also note that only MyGUIEngine itself is LGPL and rest (i.e. platform and tools/demost/etc) is MIT.

Hi,

I just say the Mygui 3.2 RC1. It looks great but what about the wrapper / precompiled dlls? I know, it's only a RC but it would be a lot easier if there are some binaries...

Thanks

We are not releasing precompiled libraries since there is plenty IDE's/versions and it's hard to maintain packages with our small team.

But what about the wrapper? Is it updated? Are all functions wrapped( in version 3 some are missing)?

Ah, sorry, you asked about wrapper. Well, we are going to try building single package for latest Mogre, but there are some problems though.
Also our wrapper doesn't wrap completely all functions from some managers, but we will add few most wanted. As far as I remember right not is is only findWIdget.

Also our wrapper doesn't wrap completely all functions from some managers, but we will add few most wanted. As far as I remember right not is is only findWIdget.
Mm, but why do you not wrapp all functions? I just managed to compile the wrapper but as you said some managers and some functions aren't wrapped.
For example I need MyGUI::LayerManager::getWidgetFromPoint but it isn't wrapped. Should I try to wrap it myself (no experience in CLI/C++) or will it be added in the future?

Edit: Where are .Caption or .Text gone ?! How can I set the text of a button if there are no methods? I have only .SetCaptionWithReplacing ...

We do not wrap all functions because it takes time, and it's problematic to configure generation of wrapped functions.

Text and Caption was moved to TextBox and also accessible in derived classes.

Excuse me, but I've been having some trouble using the myGui mOgre wrapper, and searching the internet hasn't helped much. Of all of the versions of myGui that I have tried to use, I have been the most successful with this one, finally i have been able to create the proper .dll's, that is to say, myGui.Managed/myGui.Sharp, and their dependencies, and i have been able to add them as references in my project. Unfortunately, I cannot seem to locate the method for initializing myGui. myGui.Managed(/sharp).Gui does not contain a method for Initialize, and I cannot find anyplace that does, so whenever i try to use a widget, my code end prematurely, albeit without error. can anyone here tell me how to initialize myGui for the C# wrapper?

shadoslayer,
take a look at:

Download binaries and demo (Mogre 1.6.5 or 1.4.8; Mygui 3.0.2) from SourgeForge:
http://sourceforge.net/projects/my-gui/ ... r%20Mogre/
The 'export.cs' or 'export.vb' contrains some P/Invoke stuff for initilizing and createGUI, ...

Read something about the wrapper in general:
http://www.ogre3d.org/tikiwiki/Mogre+MyGUI+wrapper

About Mygui 3.2: Wait until official wrapper is released, had some trouble with it

Hi. I'm wondering what the latest plans were with respect to the pending MyGUI 3.2.0 release?

Thankyou again for all the excellent work on MyGUI.

Hi,

I don't know if someone tell you but, I checked out the trunk version of MyGUI, after cmake, in visual c++, I had to change the target name of OgrePlatform lib, it was "MyGUI" instead "MyGUI.OgrePlatform".

Else, thank you very much for your MyGUI, the best GUI engine for Ogre !

That's the known and fixed bug in old CMake version. You should use newer CMake to fix that. CMake files in MyGUI are fine.

Is 3.2 still being worked on or going to be released anytime soon? Just curious since there hasn't been any updates in a long time and this release candidate has been out for nearly a year.

For the lazy ones, like I, you can download compiled binaries for windows (x86) at the following URLs :

Release : http://tinyurl.com/blhsv7d
Debug : http://tinyurl.com/cvhzanh

I've noticed that in 3.2.0 HRelative and VRelative don't exist anymore. This is completely breaking my UI layouts. Is there something equivalent that handles the same way in the new version?

I am curious about this as well. How do we do stretching relative guis?