TODO/Feature request

Altren

25-06-2008 12:30:10

Here's (not full) list of features that we are planning to implement or working on (sorted by priority):

...ah, we made a lot of stuff that not listed here...
DelegateManager - assign events from layout file [work in progress]
PopupMenu and MenuBar in layout file
Panel and Panel bar [done]
Tree view widget

Word selection in Edit on double click [done]
MultiList custom sorting [done]
Popup menu with sub menus [done]
Edit scroll bars [done]
Console [done]
Edit word wrap [done]
Tooltips [done]
Shift of the text in different states [done]
animated static image [done]
Load layouts in a given parent [done]
multi delegates [done]
LocalizationManager - automatically replace #{text} tags with text from [done]
ScrollView widget [done]

Altren

20-10-2008 23:09:16

If you want to see some feature in MyGUI you are welcome, we'll discuss it and add to our plans.

Liberator

03-12-2008 22:42:56

Hi,

I have created a GUI driver that uses MyGUI for my engine GUI system and I have two things I need myself (and have hacked for CEGUI in the past).

1) Listbox that instead of adding a vertical scrollbar will add added items to a new row in a new colum (if needed). When resizing the listbox the number of rows is auto-adjusted so that max items can be displayed in a column without a vertical scrollbar. A horizontal scrollbar is not a problem. I like using his type of Listbox for fileopen/close type dialogs where I display all the resources.

2) A widget that does nothing except act as a spacer for other widgets. It would act as a grid in which you can place other widgets which are auto sized to fit in the gridbox. This will allow you to maike a grid that has text fields, button fields, progress bar fields etc.

How often is MyGUI updated? The reason I created the MyGUI driver is because CEGUI seems to have trouble staying alive so I hope MyGUI does not suffer the same fate. With my driver model however I can switch to new backends with relative ease.

Altren

04-12-2008 00:23:23

1) Listbox that instead of adding a vertical scrollbar will add added items to a new row in a new colum (if needed). When resizing the listbox the number of rows is auto-adjusted so that max items can be displayed in a column without a vertical scrollbar. A horizontal scrollbar is not a problem. I like using his type of Listbox for fileopen/close type dialogs where I display all the resources.You can make this in item box, you can use only StaticText as your items. You can see it in Demo_ItemBox, just remove pictures from items.2) A widget that does nothing except act as a spacer for other widgets. It would act as a grid in which you can place other widgets which are auto sized to fit in the gridbox. This will allow you to maike a grid that has text fields, button fields, progress bar fields etc.Sounds interesting, can you describe it a bit more detailed.How often is MyGUI updated? The reason I created the MyGUI driver is because CEGUI seems to have trouble staying alive so I hope MyGUI does not suffer the same fate. With my driver model however I can switch to new backends with relative ease.Well, there wasn't major releases for a long time, but we are working on MyGUI very active, if you want see that we have progress - check out MyGUI from svn. There are many commits changes and updates all time :)

Liberator

04-12-2008 18:58:20

1) Listbox that instead of adding a vertical scrollbar will add added items to a new row in a new colum (if needed). When resizing the listbox the number of rows is auto-adjusted so that max items can be displayed in a column without a vertical scrollbar. A horizontal scrollbar is not a problem. I like using his type of Listbox for fileopen/close type dialogs where I display all the resources.You can make this in item box, you can use only StaticText as your items. You can see it in Demo_ItemBox, just remove pictures from items.

Interesting,.. If I can also get a small image next to the static text then that would be perfect for imitating a Windows file-open dialog.


2) A widget that does nothing except act as a spacer for other widgets. It would act as a grid in which you can place other widgets which are auto sized to fit in the gridbox. This will allow you to maike a grid that has text fields, button fields, progress bar fields etc.Sounds interesting, can you describe it a bit more detailed.


Basically I'm talking about something that like your itembox houses a number of items but instead of a item being predefined to be an image or whatever it is simply a "widget" in an abstract sense. You can use the interfaces at the Widget class level to fit the widget objects in the allocated item space (cell). This would basically allow you to build things smilar to Exel sheets where cells can also contain pulldown boxes or other things not just editable text (edit box) as the cell content.
This type of widget would be the base class for your current itembox because it would already have most of the functionality with the itembox simply providing a specialized API that provides a more convenient way of manipulating its contents.


How often is MyGUI updated? The reason I created the MyGUI driver is because CEGUI seems to have trouble staying alive so I hope MyGUI does not suffer the same fate. With my driver model however I can switch to new backends with relative ease.Well, there wasn't major releases for a long time, but we are working on MyGUI very active, if you want see that we have progress - check out MyGUI from svn. There are many commits changes and updates all time :)


Good to know. Working on an expansive project like mine means I have little time to waste by constantly writing new plugins/backends/drivers because it distracts from building actual functionality. However if other people use my engine they will have the option of switching between CEGUI and MyGUI as their GUI driver which helps me serve a broad audience :)

mrmclovin

24-12-2008 01:33:31

Hello,
I'm just wondering if you have plans making a skin editor in which you'll be able to create your own skin using a (MyGUI obviously) gui?

If yes, approximately when ? ;).

If no, why is that? Consider this as a feature request that would make this awesome gui lib to a killer gui lib! :D

Altren

24-12-2008 02:27:52

Of course we was planning to create editor just after started creating LayoutEditor. Actually man that working on skin editor creating it very slow because he don't have enough time for it. And absolutely don't know when it will be ready.

tdev

31-01-2009 15:26:11

sizer concept for window layout:
i would be great if we could have some sort of simplified window layouting. As Base idea we could take a similar approach as wxWidgets did: http://docs.wxwidgets.org/stable/wx_sizeroverview.html

Maybe evolve this in stages:
1) create a simple Box sizer:
wxBoxSizer can lay out its children either vertically or horizontally


please note that boxsizers should be able to contains boxsizers itself.

2) create more complex layouting tools like a grid or some boxsizer with variable sizeable border?

i would really like to realize such a layout for some editor i am thinking of:
[attachment=0]sizers.png[/attachment]

AndiNo

08-02-2009 18:29:33

Is there any estimation about when the tree view widget will be finished? I looked through the SVN source but could not find any hint...

Five_stars

14-02-2009 19:14:05

Sorry for late and sorry for not good news.
We plan tree view next release or earlier (it's caused by new architecture changes). Can't say dates of release :), but not soon.
Good one. Work over containers(sizers) starts :) .

DarkHorizon

23-04-2009 15:25:30

1. Code Generation

One thing I'd like to see for the MyGUI Layout Editor is auto-generated classes, one per top-level window, with one variable per sub-widget, appropriately-named, with a constructor that sets the member variable using the appropriate FindWidget<>() function, for example...

<?xml version="1.0" encoding="UTF-8"?>
<MyGUI type="Layout">
<Widget type="Window" skin="Window" position="488 184 250 164" layer="Back" name="MyWindow">
<Widget type="Button" skin="Button" position="22 15 74 28" layer="Back" name="MyWindow_MyButton"/>
<Widget type="Edit" skin="Edit" position="20 47 78 24" layer="Back" name="MyWindow_MyEdit"/>
<Widget type="StaticText" skin="StaticText" position="22 79 72 24" layer="Back" name="MyWindow_MyStaticText"/>
</Widget>
</MyGUI>


...when saved, generates the following...

class MyWindow
{
public:
MyWindow()
{
m_MyWindow = MyGUI::Gui::getInstance().findWidget<MyGUI::StaticTextPtr>("MyWindow", false);
m_MyButton = MyGUI::Gui::getInstance().findWidget<MyGUI::StaticTextPtr>("MyButton", false);
m_MyEdit = MyGUI::Gui::getInstance().findWidget<MyGUI::StaticTextPtr>("MyEdit", false);
m_MyStaticText = MyGUI::Gui::getInstance().findWidget<MyGUI::StaticTextPtr>("MyStaticText", false);
}

MyGUI::WindowPtr m_MyWindow;
MyGUI::ButtonPtr m_MyButton;
MyGUI::EditPtr m_MyEdit;
MyGUI::StaticText m_MyStaticText;
};


... which can then directly be used in code...

MyWindow* lpMyWindow = new MyWindow();
lpMyWindow->m_MyButton->setCaption("Booya!");


Not sure if this is in the works, but it would certainly save on tedious/repetitive hand-generated code.

2. Auto-Variable Naming

Another useful feature for the MyGUI Layout Editor would be to automatically prefix a newly-created widget's name with (1) the name of its parent (if any), (2) some delimiter (e.g. an underscore) if it has a parent, and (3) a 2-3 character prefix indicating its type (e.g. bn for Button, lst for List, etc). For example, if I create a Window, its name is automatically prefixed with wnd. Let's say I call it "Status". If I were to create a child Button widget, it would be automatically prefixed as wndStatus_bn.

This obviously is my own personal preference for naming conventions, but if the prefixes could be customized (e.g. in the Settings for the editor), it would become fairly user-centric. Coupled with the code generation suggestion for #1, it would prove to be a huge time-saver and organizational boon.

Thanks!

Altren

23-04-2009 16:30:02

About 1st. Yes, we have this in plans, but with much more functionality, but it might take many time...
About 2nd, well, it's not hard to implement, but I'm not sure that anyone else need it. You can try to do it yourself if you need it.

MuLLeR

05-05-2009 09:39:16

Feature request.
Please commit only working versions. :)

Altren

05-05-2009 12:35:45

Right now we making major refactoring and, unfortunately, it's hard to keep it working and stable in all cases. Use 2.2.2 release or revision 1900 (not higher) for now.I'll tell when it will be done.

MuLLeR

05-05-2009 13:05:51

Ok. Thanks.

How about support for Ogre Cthugha?
Currently there is nothing rendered.

Altren

05-05-2009 13:14:17

It works fine for me. I'm always using Ogre from svn.

MuLLeR

06-05-2009 08:40:01

Strangely, but it does not work with me.

On exit Sigfaults on this line of code (rev. 1900)

102. delete mRenderOperation.vertexData;


And nothing is getting rendered.

Any suggestions?


False alarm, rev1900 works fine with latest trunk ogre.

MuLLeR

07-05-2009 08:24:47

1. CMake build system would be very nice. :)
2. Font scaling based on resolution. As everyone tends that the GUI should look the same on all resolutions.

Liberator

12-05-2009 23:52:10

1. Code Generation

One thing I'd like to see for the MyGUI Layout Editor is auto-generated classes, one per top-level window, with one variable per sub-widget, appropriately-named, with a constructor that sets the member variable using the appropriate FindWidget<>() function, for example...

<?xml version="1.0" encoding="UTF-8"?>
<MyGUI type="Layout">
<Widget type="Window" skin="Window" position="488 184 250 164" layer="Back" name="MyWindow">
<Widget type="Button" skin="Button" position="22 15 74 28" layer="Back" name="MyWindow_MyButton"/>
<Widget type="Edit" skin="Edit" position="20 47 78 24" layer="Back" name="MyWindow_MyEdit"/>
<Widget type="StaticText" skin="StaticText" position="22 79 72 24" layer="Back" name="MyWindow_MyStaticText"/>
</Widget>
</MyGUI>


...when saved, generates the following...

class MyWindow
{
public:
MyWindow()
{
m_MyWindow = MyGUI::Gui::getInstance().findWidget<MyGUI::StaticTextPtr>("MyWindow", false);
m_MyButton = MyGUI::Gui::getInstance().findWidget<MyGUI::StaticTextPtr>("MyButton", false);
m_MyEdit = MyGUI::Gui::getInstance().findWidget<MyGUI::StaticTextPtr>("MyEdit", false);
m_MyStaticText = MyGUI::Gui::getInstance().findWidget<MyGUI::StaticTextPtr>("MyStaticText", false);
}

MyGUI::WindowPtr m_MyWindow;
MyGUI::ButtonPtr m_MyButton;
MyGUI::EditPtr m_MyEdit;
MyGUI::StaticText m_MyStaticText;
};


... which can then directly be used in code...

MyWindow* lpMyWindow = new MyWindow();
lpMyWindow->m_MyButton->setCaption("Booya!");


Not sure if this is in the works, but it would certainly save on tedious/repetitive hand-generated code.

2. Auto-Variable Naming

Another useful feature for the MyGUI Layout Editor would be to automatically prefix a newly-created widget's name with (1) the name of its parent (if any), (2) some delimiter (e.g. an underscore) if it has a parent, and (3) a 2-3 character prefix indicating its type (e.g. bn for Button, lst for List, etc). For example, if I create a Window, its name is automatically prefixed with wnd. Let's say I call it "Status". If I were to create a child Button widget, it would be automatically prefixed as wndStatus_bn.

This obviously is my own personal preference for naming conventions, but if the prefixes could be customized (e.g. in the Settings for the editor), it would become fairly user-centric. Coupled with the code generation suggestion for #1, it would prove to be a huge time-saver and organizational boon.

Thanks!


Your first feature is in-part what I do with my GUI library. It maps a GUI widget or form class to the actual implementations for whatever backend library is used using the PAC design pattern. What use suggest is a much tighter integration with MyGUI into the code that might or might not be desirable to everyone.

The second is something I do myself in my FormBackend class which constructs a form from a resource (the xml) and wraps the widgets and all that. The feature you mention is something I need as well because I allow the same form to be loaded as often as desired. For most users with a simple GUI however this might not be needed. So scoping the uniqueness of the widget name to either its siblings or global would be useful for me to but whether it belongs in the MyGUI library itself,..

zeb

26-06-2009 10:30:21

1. Is there any plan to make MyGUI to be independent of OGRE. I can't make MyGUI work with other 3d engine easily.
2. I can't read the comment in source code. Maybe it's not English. Is that right? I wonder if you have plan to write the comment in English?

Thanks.

Liberator

26-06-2009 17:50:00

1. Is there any plan to make MyGUI to be independent of OGRE. I can't make MyGUI work with other 3d engine easily.
2. I can't read the comment in source code. Maybe it's not English. Is that right? I wonder if you have plan to write the comment in English?

Thanks.


The reason I like MyGui myself as one of th support Gui libraries for my engine is that it has good integration with Ogre which makes it high performant compared to other Gui toolkits. If you want something that is more standalone I would recommend CEGui.

I agree with the comments remark,.. comments in Russian? don't add much for me :D

psiha

29-06-2009 11:33:20

hi and thank you for "Yet Another GUI Library" :mrgreen:
...and i mean that both honestly and ironically :) ...because i've gone 'to hell and back' trying to find a "good" (g)ui library/framework but found none of them 'out there' to be really satisfactory (and there really is a huge number and variety of libraries)...
...but yours/mygui seems among the most promising (/with hope "not to eventually suck beyond repair" :mrgreen: ;) )

anyways :) on to the 'requests':

- 1. the single "real" feature that i currently miss most from mygui is a "rotational knob" kind of widget (that can handle/work with both 'image sets' and be able to use a single image/object and rotate/render it at runtime)...(so that it can 'out-of-the-box' display guis like these http://libnui.net ...)

- 2. from the above request it is perhaps obvious that i am looking for a gui for an audio-effect type of application/plugin and from that the next request follows: decoupling from ogre/providing a seamless way to choose between a fullblown full screen gui and a non intrusive windowed mode gui that can work well for plugins/as a child of a 'master' application (that does not use mygui)...from the latest svn revision it seems you are already on that path (with the directx renderer and the ogre renderer extracted from the 'core' myguiengine) so i'm already pleased :) i would only add the request for a 'pure opengl' renderer for 'true' cross-platform compatibility without the need for ogre...

- and now for the 'bitching' part :mrgreen: that is most/all of the below notes are design and/or (space) efficiency issues [linking with the myguiengine static library only (the one from svn, without any renderer) built with optimization for size and all of the optimization options provided by msvc++ 9.0 including link time code generation and only creating a single MyGUI::Gui object and calling its initialise() member function increased my binary size by over a megabyte, making it about three times the size than it was before and this is ofcourse unacceptable...unfortunatly, as is the current sad state of programming practice, other similar gui libraries were even (much) worse]:
- 3. why must everything be 'newed' (allocated on the heap)...(a short look at the MyGUI::Gui constructor will show what i mean)..."thank God" C++ is not java or c# and this is not only inefficient and introduces exception safety issues but is completely unnecessary...(most gui libraries out there suffer from the exact same flaw, as if they were programmed by someone how learned C then did some java and from that went straight to C++)...
- 4. if you need lazy instantiation (connected to above) use placement new or the meyers singleton pattern
- 5. if you >actually and really< need to allocate something on the heap new it directly into a smart pointer
- 6. deriving _everything_ from a CObject/IObject style base class (with virtual functions) is again so typical of c-then-java/c# programming school, this is not only not necessary in C++ it is plain wrong (from a generic point of view)...C++ also has both multiple inheritance and functional programming semantics...the 'single inheritance and everything is a CObject' in the end creates a coupled hierarchy so that using one class often brings in code that is completley unused (and often unrelated)...true, most of that effect is the blame of virtual functions which act like brick walls for practically any compiler/optimizer out there...a string and a window have nothing in common except that they are 'objects' but that is implicitly obvious for the language itself, there is no need to make it more obvious by deriving from a CObject/IObject class (with the added bloat of virtual functions)...
- 7. connected to above, if you, for example, need shared object semantics you most probably don't need it always and for every object of every class, so you do not provide shared object semantics by placing reference counting code in your base class...instead if somebody wants to use an object from your library as a shared object he/she will simply 'put' it in a shared pointer and pass it around like that...
- 8. also (connected to above) in the majority of cases 'you'/'the user' do not manipulate windows through their base class (also because the structure/design/hierarchy of most guis out there is known at compile time, so you know exactly the window type you are working with) so there is no need to use virtual functions in the window/widget base class (going into details in this first post why 'unnecessary virtual functions' are evil in practice/cause code bloat would be too much, you are free to google it :mrgreen: ;) )...instead you can, for example, use the WTL approach using templates (http://sourceforge.net/projects/wtl) so a user that actually needs to access his/hers widgets through a base class can then specify through a template parameter that he wants/needs a base class with a virtual interface...
- 9. a large number of users will also know at compile time which renderer, for example, they will use and the current approach of choosing a renderer by creating an object of that class that then 'registers' itself as the 'renderer singleton' (notice how this already is broken: how do you stop the user from creating another object that derives from the same class, 'overwriting' the last one...things like these are solved with a proper implementation of the singleton pattern and/or the object factory pattern, but, as i would like to show this is all unnecessary, and 'wrong', in this case) so that the rest of the code can than use this object through a pointer and virtual functions (of the base class) is really unsuitable for such use. because it will link in (all) code for all renderers and use its functionality through virtual calls and a pointer to the object when, in fact, it is compile time knowledge which object that is and where it is located (so neither the access through a pointer nor the virtual interface are needed)...this is better solved through the use of policy classes (see c++ policy based design) which are specified as template parameters...you can then easily create a 'renderer'/'redering policy' class that actually only wrapps all other exiting renderers and offers runtime switching between them if that is what the user wants (such a 'renderer wrapper' class could actually be almost automatically generated with boost::mpl 'magic')
- 10. reinventing the wheel is never good in theory and almost never good in practice...use boost (http://www.boost.org) and stl for everything that you need and they already provide (this includes everything from configuration and platform detection macros, over standard integer types, smart pointers, pointer containers and other advanced containers, 'any'/'variant'/'optional'-like c++ union wrappers, threading, filesystem etc etc etc)...even if they do not provide something that is/should actually already be implemented many times (as the unfortunate case of a logging library on which the boost guys have not yet cast the final vote) there probably already exists another good implementation 'somewhere outthere'...this way you (also) cut on your own maintenance time and code base.....i was glad to see that you atleast used std::strings and not YetAnotherStringClassThatOnlyThisLibraryUsesAndThatUsuallyCompletelySucks :mrgreen: like most other libraries do :)
- 11. managing/selecting/finding windows and widgets by name, that is, strings that are known at compile time is oxymoronically inefficient (from the C++ point of view that "you don't pay for what you don't use")
- 12. please do not use (std::)streams...never ever...they are horribly horribly inefficient (both by design and especially in the msvc++/dinkumware implementation)...http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf ...
- 13. std::vector and (more so) std::string are/can be also rather bloated so you should not use them where not needed...this especially counts for things like static strings/string lists and std::string function parameters that have default values of empty strings which are most often used (for example the MyGUI::Gui::initialise() member function)...calling this function causes construction and destruction of (empty) temporary string objects...that means actual code that has absolutely no effect gets generated and called...
- 14. (connected to above) always/from time to time check the dissasembly window to see what code gets actually generated by/for your c++ constructs...
- 15. design your classes and your hierarchy so as not to force RTTI onto your users (as previously mentioned, not everyone needs to access the widgets/objects from your library through pointers to base classes)
- 16. use the __declspec( selectany ) msvc directive when creating global variables and objects (of any kind)...the msvc linker needs it to be able to completely remove unused data and code for globaly declared (but unused) objects
- 17. provide a clean/default/out-of-the box way to build your library as as static library...imho this should be the default because...from its nature, it seems highly unlikely that a mygui .dll will ever be shared by two or more applications on the same machine and, the usual use case then of placing the dll next to your exe is oxymoronic...that's what static libraries and static linking is for...(binary wise you also get to 'tug along' only the, binary, code that your exe uses...provided of course that the library was properly designed, that is that everything is not coupled with everything else so you always end up the entire library in your exe)
- 18. please do not include logging code in the release builds
- 19. error codes and exceptions serve to report runtime errors/exceptional events, that is events that neither the author of the library nor the programmer using the library have control over (like out of memory conditions)...so they should not be used to report incorect use or programmer errors...that is what asserts are for
- 20. russian comments don't play nice with doxygen and non-russian speaking users :mrgreen: ;)
- 21. always remeber to make your design follow the C/C++ rule: "you don't pay for what you don't use"

...ok...enough for the first post :mrgreen: ;)


ps. if you'd like i'm willing to contribute on these design/low level implementation issues... ;)

{
edit1: added two more points
edit2: fix the link to the pdf containing the technical report on c++/stl performance
}

kungfoomasta

29-06-2009 19:25:43

It seems the majority of your post speaks against the size of MyGUI after compilation. Being 2009, I can't imagine the size being a major issue, unless you work with embedded systems of some sort, and thats still stretching things..

This might not be exactly related, but I will defend the use of 'new', I new as much as possible, because through using pointers I can forward declare as much as possible. This means that my headers include only a minimum number of other headers, and ideally, somebody using the library would not have to also include the libraries that library was dependent on. (for example if EngineX used MyGUI, which depended on Ogre, and AppX uses EngineX, AppX shouldn't have to include MyGUI and Ogre as dependencies, if the library was designed well)

psiha

30-06-2009 12:55:18

It seems the majority of your post speaks against the size of MyGUI after compilation. Being 2009, I can't imagine the size being a major issue, unless you work with embedded systems of some sort, and thats still stretching things..

i'm sorry i was obviously confused by the title of the mygui wiki page: "MyGUI is a _fast_ and _simple_ GUI."

with all due respect, this is exactly the type of reasoning that i despise. it's the exact type of 'reasoning' responsible for todays bloatware, anyware from windows vista to things like ati's graphic card control panel/systray application written in .net that hogs nearly a 100MB of memory or realteks control panel application for their audio card of which only its main exe is 16MB (hello people you can fit two proper whole os kernels in that!?). it is the reason why todays computers, even though literally thousands of times faster, feel as slugish as 10 or 15 years ago (while the 'ui experience' has, in essence/reality, become maybe only 'tens of times' 'better'/'richer'/'more complicated')...



This might not be exactly related, but I will defend the use of 'new', I new as much as possible, because through using pointers I can forward declare as much as possible. This means that my headers include only a minimum number of other headers, and ideally, somebody using the library would not have to also include the libraries that library was dependent on. (for example if EngineX used MyGUI, which depended on Ogre, and AppX uses EngineX, AppX shouldn't have to include MyGUI and Ogre as dependencies, if the library was designed well)


even if you want to sacrifice runtime performace for compile time performance, there is no need to "new as much as possible"...you only need to hold (private/implementation) class members by reference instead of by value (i.e. new only those)...even more 'properly' you do not 'new' them all separately, you use the pimpl idiom...
...but, yes, even then this does not hold for the example i mentioned because using the above technique make sense/gives results only for hiding private implementation details (be it your own or of a 3rd party library) that are never exposed to the user. from the point of view of a user of a library it provides almost no compilation performance gain to 'new' objects of classes that are otherwise part of the library's public interface (and this is exactly the case that i was commenting on for the MyGUI::Gui class) because the user is probably going to include them anyway and, from a library users perspective, a library is a stable piece of code so percompiled headers can be used to fix/aleviate any compile-time performance hit caused by a/the library...



AppX shouldn't have to include MyGUI and Ogre as dependencies, if the library was designed well)


i would also add that if AppX uses only MyGUI but not Ogre (if they were separable) from EngineX it should also not include Ogre _in its binary_, if the library/EngineX was designed well...


ps. from your preferences, are you sure C++ is the language for you? why not go for c#/.net where your preferences are the default behaviour/mindset already 'provided' by the language...

my.name

30-06-2009 13:23:58

i'm sorry i was obviously confused by the title of the mygui wiki page: "MyGUI is a _fast_ and _simple_ GUI."
http://my-gui.sourceforge.net/#tabs-about

kungfoomasta

30-06-2009 17:58:07

with all due respect, this is exactly the type of reasoning that i despise. it's the exact type of 'reasoning' responsible for todays bloatware, anyware from windows vista to things like ati's graphic card control panel/systray application written in .net that hogs nearly a 100MB of memory or realteks control panel application for their audio card of which only its main exe is 16MB (hello people you can fit two proper whole os kernels in that!?). it is the reason why todays computers, even though literally thousands of times faster, feel as slugish as 10 or 15 years ago (while the 'ui experience' has, in essence/reality, become maybe only 'tens of times' 'better'/'richer'/'more complicated')...

Surely you understand that not everybody can be completely satisfied with a particular design. In order to decrease size the way you want the library would have to become very plugin oriented. (If you're not using buttons, toss out support for buttons, if you're not using text, toss out support..etc) I'm not supporting bloated code, but I do support a design where the developer is not affraid of going above the minimum necessary, to focus on factors other than size. Having the number one priority set as "my library has the smallest footprint possible" is IMO not aligned with what the majority of what people want, they want a fully functioning, well rounded GUI library that is flexible and can be adapted to custom scenarios.

From your preferences, it seems assembly is the language for you. All these higher level languages are unnecessary and add bloat. :wink:

psiha

01-07-2009 12:38:18


Surely you understand that not everybody can be completely satisfied with a particular design.


exactly...that's why a good library does not (or strives not to) force particular design decisions and compromises on its users _if it does not have to_...configurability is the 'holy cow' in this area...



In order to decrease size the way you want the library would have to become very plugin oriented. (If you're not using buttons, toss out support for buttons, if you're not using text, toss out support..etc)


not true, fortunately...that would be the old C-style/runtime modularity approach...i was not talking about that (i'd actually vote against such a policy...closely related to the static linking issue brought up earlier)...
i was simply talking about proper/modern/correct coding practice which foremost includes modularity and decoupling...if you do not write 'spaghetti code' (http://en.wikipedia.org/wiki/Spaghetti_code), where everything is coupled with everything else, and giant 'do-it-all-classes', then the compiler and linker will be able to simply exclude the unused code from the final binary (unless ofcourse you litter everything with virtual functions, because these are still 'brick walls' for the c++ compiler).
if you asked the 'modern c++ gurus' andrei alexandrescu or herb sutter (who explicitly speak against 'premature optimization' in their book "C++ Coding Standards") they would probably agree on most of the points i outlined...because most of those points are not 'just crazy bitching about dubious optimization details' but also, or even primarily, about wrong coding practice (e.g. two or more consecutive new statements into raw pointers are simply wrong, a bug actually, because they are not exception safe and would cause, atleast, leaks in case of an exception)...
...just as alexandrescu and sutter speak against 'premature optimization' they also, in the next chapter, argue against 'premature pessimization'...



I'm not supporting bloated code


i'm sorry, you are not allowed both this statement and the previous, so typical one, that 'this or that does not matter in "2009"' :P ;)



but I do support a design where the developer is not affraid of going above the minimum necessary, to focus on factors other than size.


as i argued above (with premature optimization and pesimization, as well as certain simply wrong practices) not focusing does not mean completely "bluring out"...
...if we got the library from e.g. 2MB to like 200kB (where i think you can get with simply not 'pessimizing prematurely') then one could object that further optimization effort would be 'premature optimization'/'loosing the main focus of the library'...



Having the number one priority set as "my library has the smallest footprint possible" is IMO not aligned with what the majority of what people want, they want a fully functioning, well rounded GUI library that is flexible and can be adapted to custom scenarios.


i'm all for flexibility...as much as possible...just give it to me "properly" :mrgreen:
e.g. - use policy based design (see andrei alexandrescu writtings on that) for compile time polymorhpism and abstract classes and virtual functions only where they model _actual_ (from a logical and design point of view) runtime polimorphism
- don't reinvent the wheel (e.g. boost provides two great implementations, 'more static' and 'more dynamic', for the 'any'/'variant'/'discriminated union' idiom/pattern...use it, focus your efforts on something else/new)
- etc...not to repeat my self...

( http://en.wikipedia.org/wiki/Anti-patte ... i-patterns )



From your preferences, it seems assembly is the language for you. All these higher level languages are unnecessary and add bloat. :wink:


not true, again, fortunately...
C++ does not add any bloat ("by default")...because it followed the C paradigm: >you do not pay for what you do not use<...
(sadly, the same cannot be said for some parts of the stl...but again, you are not forced to use it)
coding complex systems in asm, if at all feasible, can in fact produce less efficient results because (amongst other things) you don't see the big picture as you get cluttered with all the ugly details...(that this actually happens can already be seen in many big 'pure C' projects like openssl where they 'emulate' c++/the object oriented approach and of course do it wrongly, ugly and inefficiently...)...
i can use asm from C++ always, but i cannot do, for example, compile time metaprograming (e.g. things like multiplying matrices at compile time) in asm...and that is where, often, both beauty and efficency hide...

but, on the other hand, yes, if you do not care how much you pay for what and simply do not want to care about the 'boring details' then C++ by definition is not the language for you...the "managed code" paradigm is just for that...the language and the runtime handle the "dangerous real world" for you...


ps. if i understood correctly, you lead the development of quickgui...why don't you join forces with the mygui team? ;)

my.name

01-07-2009 16:20:51

=)

kungfoomasta

01-07-2009 19:57:29

I normally don't post much in these forums, but I often check out what other GUI libraries are doing, for ideas, seeing what people want, common issues, etc. Colaboration is good and reduces work load, but our libraries seem pretty mature at this stage, and the both have different areas of focus. (Still I do sometimes recommend MyGUI to people, because it is so active.)

mrmclovin

07-08-2009 16:25:50

I think you should make the initialization of MyGUI more explicit. I'm getting little annoyed over the required "hidden" singleton presence, especially in the public API. For example:
MyGUI::OgrePlatform* mPlatform = new MyGUI::OgrePlatform();
mPlatform->initialise(mWindow); // mWindow is Ogre::RenderWindow* where you want to render MyGUI
MyGUI::Gui * mGUI = new MyGUI::Gui();
mGUI->initialise(mWindow);


Should be:
MyGUI::OgrePlatform* mPlatform = new MyGUI::OgrePlatform();
mPlatform->initialise(mWindow); // mWindow is Ogre::RenderWindow* where you want to render MyGUI
MyGUI::Gui * mGUI = new MyGUI::Gui(mPlatform);
mGUI->initialise();


It's so more obvious with the latter chuck of code! I really think you should start to code towards a more explicit public API when it comes to dependecies of other classes.

AndiNo

07-08-2009 17:08:36

Tell me if I'm wrong, but for me (using SVN 2131) the initialise function looks like this:
void initialise(const std::string& _core = "core.xml", const std::string& _logFileName = MYGUI_LOG_FILENAME);
The wiki uses it the same way you do... but I don't know why?
In the code the description looks like this:
/** Initialise GUI and all GUI Managers
@param
_window where GUI will be drawn
@param
_core name of core config file for MyGUI (contain main config files with skins, layers, fonts, etc.)
@param
_group MyGUIResourceGroup where _core and all other config and GUI resource files are
@param
_logFileName Log file name
*/

Maybe it's just outdated?

Altren

07-08-2009 17:59:48

Yeah - it was outdated, I wasn't checking it since 2.2.2 was released.

mrmclovin

27-09-2009 15:09:06

Hello! Lately, I've been using MyGUI more and more and as I encount problems and try to solve them I realize the MyGUI suffers a clean API. I really like MyGUI for what it have become and its functionality but the API needs major improvement. I will give you some examples to prove my point and attempt to give you constructive feedback.

Explicit initialization
I've spent time debugging due to some mistakes where I've initilized gui before created viewport and added a camera. It may be obvious to have a camera and such created before creating MyGUI. However I don't like that mygui assumes you have created a platform and other stuff. Especially when it can be more explicit without any big changes. Suggestion of future initialization:
MyGUI::OgrePlatform* mPlatform = new MyGUI::OgrePlatform();
mPlatform->initialise(mWindow, mViewport, mCamera);
MyGUI::Gui * mGUI = new MyGUI::Gui(mPlatform);
mGUI->initialise();


Awkward function names
The names of methods has unnecessary words in it. The names are not like they make no sense but they could be named better. Examples of common naming patterns:
List::insertItemAt (size_t _index, const UString &_name, Any _data=Any::Null)
Why the "At" suffix? It's implicitly that you insert an item at _index because 1)it's named 'insert' 2)first param is called _index

Non-uniform names
List::getItemNameAt (size_t _index)
List::findItemIndexWith (const Ogre::UTFString &_name)
These two functions have the same purpose. They retrieve data from the List. But one of them has the 'find' prefix. Why not put 'get' as prefix on both? Even though findItemIndexWith() may iterate through a vector (while getItemNameAt doesn't) it must not be called 'find'. If the user should remark something about the function, it should be written i the documents.
Also, why not skip the 'At' and 'With'?

Use overloading!
The API handles absolute and relative positioning/sizes by different names on methods and structs. Examples of setting relative values is Widget::createWidgetReal() which creates a child widget with its position and size calculated in percent accordding to parent.
We also have the RealCoord, RealSize structs etc. which is used to set percentage values on widgets. The opposite is absolute positioning written with ordinary int's (IntCoord, IntSize and so on). If you want to create a child widget with absolute values you call Widget::createWidget().
This can be written much more elegant IMO. Take the RealCoord for instance. What does it tell us? A coordinate struct with Real (=float) values? Wouldn't RelCoord, as in RelativeCoord, be a better name? Wouldn't AbsCoord be a better name instead of IntCoord? As far as i know IntCoord and RealCoord
are only used with position and size on widgets and nothing else. So IntSize is a useless name IMO. As for the methods, there shouln't be seperate names. Just use overloading.
Widget::createWidget(AbsCoord absoluteCoord)
Widget::createWidget(RelCoord relativeCoord)


And here I have a few requests:

* MenuitemCtrl and Menuitem should be couple together and remove MenuItemCtrl. It's less confusing with one of them only.

* There should be a way (function/operator) to copy existing widgets

* It would've been nice to have some kind of widget sheet. It's similair to layouts with the difference that it does not
represent a layout but a collection of many panels/widgets. For example if I want to put all my panels and windows in the same place
even though the panels may not relate to eachother like in a layout. It's just a sheet where I fetch the widgets when I want to. I.e. I load the sheet once but
none of them are visible until i "load/activate" the individual widget.

* The layout editor should have a renderbox that represents the viewport the layout should be placed in. As it is for now, the layout editor's window itself represents the viewport
which means the layout editor's own panels and windows are taking up the corners which is very annoying.

my.name

28-09-2009 02:00:12

>>Explicit initialization
soon


>> Awkward function names


//example

int getItemData(size_t _index) { ... }
int getItemData(Widget* _item) { return getItemData(getIndexByItem(_item)); }

Widget* item = 0;
getItemData(item); // error

size_t index = 0;
getItemData(index); // error

//-------------------------

int getItemDataAt(size_t _index) { ... }
int getItemData(Widget* _item) { return getItemDataAt(getIndexByItem(_item)); }

Widget* item = 0;
getItemData(item); // fine

size_t index = 0;
getItemDataAt(index); // fine


// from List<T> NET
//Remove
[url=http://msdn.microsoft.com/en-us/library/cd666k3e]http://msdn.microsoft.com/en-us/library/cd666k3e(VS.85).aspx
//RemoveAt
[url=http://msdn.microsoft.com/en-us/library/5cw9x18z]http://msdn.microsoft.com/en-us/library/5cw9x18z(VS.85).aspx

my.name

28-09-2009 02:20:19

>>Non-uniform names

getXXX() // exception if not found
findXXX() // return 0 or ITEM_NONE if not found

Ripgiblet

28-09-2009 16:43:58

Firstly fantastic library:] Been a pleasure to use, and fast:] (Please don't compromise speed for anything;}).

Ok I use MyGUI for almost all GUI stuff including HUD for RTS style troops. Could you add the ability to change/set the colour of the bars somehow... currently I have to make a bitmap for each of the colours to use for a bar... but I kind of wanted to change the bars colour based on its value... example Half dead orange...
Now it has the SetColour widget control in MyGUI::Progress...
->setColour(MyGUI::Colour(0,0,1,1));
Would it be possible to apply a colour shade or something:] to the bar... that way we could make the bar white then apply the colour and the bar would change:]
Anyway... since uses images.. maybe not easy... but well...

PS-Any other ideas on how to do this? (I could make up my own progress widget I guess....)
PS2-Thanks again for this great GUI library. If this game ever gets finished I will send you a copy, and if commercialised successfully will send you some cash :D.

Altren

28-09-2009 17:01:25

Well, I think you should use pair of widgets - some backgroung (just StaticImage with fixed picture) and rawRect - rectangle with customizable vertex colours: you can find example of rawRect in Demo_Colour.

Altren

30-09-2009 01:40:36

Explict initialisation ready:
// initialise Ogre before platform
// ... mRoot->initialise(true);

mPlatform = new MyGUI::OgrePlatform();
mPlatform->initialise(nullptr, nullptr); // or mPlatform->initialise(mWindow, mSceneManager); if you already have it
mGUI = new MyGUI::Gui();
mGUI->initialise(mResourceFileName);

// ... create mWindow
// ... create mSceneManager

// ... create Camera and Viewport

mPlatform->getRenderManagerPtr()->setRenderWindow(mWindow);
mPlatform->getRenderManagerPtr()->setSceneManager(mSceneManager);

// also if you have several Viewports you may choose any
mPlatform->getRenderManagerPtr()->setActiveViewport(viewport_num);

mrmclovin

13-10-2009 13:24:26

Use overloading!
The API handles absolute and relative positioning/sizes by different names on methods and structs. Examples of setting relative values is Widget::createWidgetReal() which creates a child widget with its position and size calculated in percent accordding to parent.
We also have the RealCoord, RealSize structs etc. which is used to set percentage values on widgets. The opposite is absolute positioning written with ordinary int's (IntCoord, IntSize and so on). If you want to create a child widget with absolute values you call Widget::createWidget().
This can be written much more elegant IMO. Take the RealCoord for instance. What does it tell us? A coordinate struct with Real (=float) values? Wouldn't RelCoord, as in RelativeCoord, be a better name? Wouldn't AbsCoord be a better name instead of IntCoord? As far as i know IntCoord and RealCoord
are only used with position and size on widgets and nothing else. So IntSize is a useless name IMO. As for the methods, there shouln't be seperate names. Just use overloading.

Widget::createWidget(AbsCoord absoluteCoord)
Widget::createWidget(RelCoord relativeCoord)

What's your (mygui-developers) comments on this?

my.name

13-10-2009 20:38:40

Bad style

from CEGUI
// position a quarter of the way in from the top-left of parent.
fWnd->setPosition( UVector2( UDim( 0.25f, 0 ), UDim( 0.25f, 0 ) ) );

// set size to be half the size of the parent
fWnd->setSize( UVector2( UDim( 0.5f, 0 ), UDim( 0.5f, 0 ) ) );



AbsCoord coord(10, 10, 100, 100);
RelCoord coord2(0, 0, 0.5, 0.5)

///...

///...

Widget::createWidget(coord1)
Widget::createWidget(coord2)

mrmclovin

14-10-2009 10:55:17

from CEGUI
Bad style
// position a quarter of the way in from the top-left of parent.
fWnd->setPosition( UVector2( UDim( 0.25f, 0 ), UDim( 0.25f, 0 ) ) );

// set size to be half the size of the parent
fWnd->setSize( UVector2( UDim( 0.5f, 0 ), UDim( 0.5f, 0 ) ) );


What's the bad style, i don't understand?

RelCoord coord(.25f, .25, .5f, .5f);
Widget::createWidget(coord)


Isn't that much easier?

More examples of how elegant it can be:
AbsPos pos(5, 10);
RelSize size(0.5f, 0.5f);
createWidget(pos, size); // creates the half the size of parent positioned 5px left and 10px from top of parent...


You'll also be able to do robust and powerful stuff like
AbsCoord coord(pos, size, widget); calculates an absolute coord based on a relative size and an absolute pos, as if widget was the parent

RelCoord relCoord(pos, size, widget); same as above, but relative instead

The API will be cleaner and better abstracted, especially for beginners. When I first started to use MyGUI it took some time for me to understand what createWidgetReal() and RealCoord was .. I mean does createWidgetReal() actually create the widget and createWidget() just create some invisible base-layer for widgets..? My point is that it will make programming mygui easier!

my.name

14-10-2009 12:28:39

In my project of 130 forms and 3 methods createWidget. Here it is good style.
To enter new type only for one method it is bad style.
If to enter new type for all methods it is the big changes for the sake of laziness to write createWidgetReal.
Project MyGUI pure and simple, and I do not wish to enter new type without the reason, differently it to turn to the monster with uncontrollable complexity.

mrmclovin

14-10-2009 22:52:08

In my project of 130 forms and 3 methods createWidget. Here it is good style.
130 forms and 3 methods createWidget, what do you mean?

To enter new type only for one method it is bad style.
Enter new type of what?

If to enter new type for all methods it is the big changes for the sake of laziness to write createWidgetReal.
It's not because of laziness (ok maybe a little cuz we all are lazy =) but about abstraction, flexibility and make the API easier and more self-explained.

Yes it might some big changes but I thought if you're up to release a v.3 of mygui I thought at least that I would suggest major improvement of the API.... and I still think it'd be worth it!

Solver

23-10-2009 20:28:37

Developers, is there any chance of having a Managed MyGUI update soon, so it would be compatible with the recent versions of Mogre? I have an application that I want to migrate over to Mogre with MyGUI, and I've been waiting for the managed version update for some time now.

Here's hoping you have the time to update managed before releasing 3.0 :)

tp

25-11-2009 07:56:33

Sliders could use a bit more polish to be on par with the rest of the library:
  1. The slider can't be made to move in increments. If I have a slider that adjusts values between 1 and 10, it is hard to tell which value it's being dragged to. I don't think it would generally cause trouble to snap the value while it's being dragged, because when using the control as a page scroller, the range is always larger than the size of the slider itself.[/*:m]
  2. The mouse wheel always causes the slider to move in increments of 50. The aforementioned adjustment between 1 and 10 is kind of hard with this behaviour ;)[/*:m][/list:u]

teofil20

13-06-2010 11:50:13

I was thinking of making a spin box with an edit and two arrows.The edit would only let you type numbers like a masked textbox in vc++.

AshMcConnell

14-07-2010 14:50:35

Could you make the WIDGET_TOOLTIP_TIMEOUT a configurable property? I am trying to make a tooltip that slides in from the bottom of the screen. It would be nice if the Show tooltip even happened straight away and I could animate for a small amount of time.

Thanks for your help
Ash

my.name

15-07-2010 09:16:10

Carrying out of all variables in options is planned

Altren

15-07-2010 10:14:16

By the way - you can use eventMouseMove and show tooltip manually.

AshMcConnell

15-07-2010 16:07:25

By the way - you can use eventMouseMove and show tooltip manually.

Is it possible to detect when we move away from the widget that the tooltips refers to? How do we know when to hide it?

Thanks for your help!
All the best,
Ash

Altren

15-07-2010 18:38:29

Right, use eventMouseSetFocus and eventMouseLostFocus then.

ShiftZ

16-11-2010 19:48:13

I've noticed a difference between the ways how image are determined in layoutEditor and skin editor. LayoutEditor accepts ResourceImageSet, but in skinEditor there is no way to setup Resource, Group and ImageName, like in properties of staticImage, instead, i have to point texture coords manually on image. Can you add same fields to SkinEditor like those in LayoutEditor to use ResouceImageSet?

samaursa

14-02-2011 20:39:31

A few features that would make layout editor absolutely wonderful (although even right now it is still amazingly well done, especially the one with the newer release).

Copy/paste widgets. Select multiple widgets and to allow dragging. Copy/paste the multiple selected items.

DragonM

19-02-2011 04:46:17

When the Tree control is implemented, can you please include the functionality of MultiList? That is, a control with more than one column, where the tree is drawn in the left-most column and the visibility of rows in (optional) additional columns is controlled by that tree.

Rambus

13-05-2011 00:09:29

A feature request: downLayerItem

It would be helpful in certain situations to have access to a command similar to upLayerItem, that pushes an item to the bottom of visibility in a layer.
downLayerItem would make a widget the widget furthest back.

siondream

05-07-2011 10:47:03

I'd like very much automatic integration with gettext. You would'nt have to manually translate every Widgets' Caption property.

uelkfr

14-09-2011 06:09:13

Please finish Project - Multiple Layout feature, code generation for each layout. What does name="_Main" mean?

uelkfr

14-09-2011 06:09:18

Please finish Project - Multiple Layout feature, code generation for each layout. I mean in Layout editor there is menu called Project, but functionality is not finished yet (3.2.0rc). And question about .layout files you have coded in Media, is name="_Main" means name generated automatically and _Main added to the end of it? Can't answer to this question through the search :)

Also need more themes. You have three themes, but they are same just different colours. For example, need theme with smaller captions, smaller sans-serif font, more sophisticated theme. BTW, current font looks like somewhat distorted, since you use textures is it possible to draw to x2 sized texture and then compress to x1 sized texture, or maybe freetype2 has some quality options that you can expose to mygui users.

simed

19-10-2011 08:39:33

Not sure if this is right thread - I can't see a sticky thread or anything about contributing to MyGUI. Is it allowed and if so how does one get access - and how is it moderated?

We're looking to use MyGUI for commercial projects and are likely to need additional Widget types, etc - so we'd be keen either to add these to MyGUI or maybe pay someone to do it. Either way being involved with the project sounds sensible for us.

uelkfr

23-10-2011 06:15:12

There is PointersW32.xml which makes use of hardware cursor so it not brings lags, is it possible to make PointersX11.xml and PointersOSX.xml? There is very big lag with graphical cursor in X11 KDE, maybe in X11 GNOME too.

Altren

24-10-2011 12:32:05

Not sure if this is right thread - I can't see a sticky thread or anything about contributing to MyGUI. Is it allowed and if so how does one get access - and how is it moderated?If you want to change something or add a feature you should discuss it with MyGUI developers first (me (Altren) and my.name). Easiest way is to create new forum topic. Then send patch with changes, and if everything is fine I'll give you access if it is necessary.
We're looking to use MyGUI for commercial projects and are likely to need additional Widget types, etc - so we'd be keen either to add these to MyGUI or maybe pay someone to do it. Either way being involved with the project sounds sensible for us.Depends on what you need. We can help to find better way to implement something, or can add something if it fits into the MyGUI core.

Altren

24-10-2011 12:33:51

There is PointersW32.xml which makes use of hardware cursor so it not brings lags, is it possible to make PointersX11.xml and PointersOSX.xml? There is very big lag with graphical cursor in X11 KDE, maybe in X11 GNOME too.Unfortunately we don't have developers, who have experiance with X11 or OSX, so we can't implement that. We will be glad to include patch with related changes if someone will implement this.

shenjoku

31-10-2011 21:22:51

I'd like to suggest a feature. I've noticed recently that input, at least for keyboard input, is being handle incorrectly. the InputManager is returning true when you have a widget that has focus whether or not the widget actually handled the key input, which can completely block an application from getting input when it really shouldn't. If possible I would really like to see it changed so those functions only ever return true if the widget actually handled the input. This would make the engine a lot easier to use and avoid major issues like being unable to toggle a modal dialog because the dialog is swallowing all input events and doing nothing with them.

Along the same lines, there's also an issue of invisible widgets still maintaining focus and swallowing input events in the same way when they aren't even being rendered and can't be interacted with.

simed

31-10-2011 21:49:40

Seconded :)

This has probably been asked before... but it would be really nice if code comments were in English. As well as meaning the comments are meaningless to the majority of us, it raises a barrier to contributing.

simed

01-11-2011 13:46:22

Ability to have an event when a widget is resized would be nice, I see Window has eventWindowChangeCoord but if you are using Stretch alignment, any widget can change size and knowing about this can be useful.

simed

07-11-2011 08:32:05

ScrollBar control should let you specify start/end values, not just the range. To maintain compatibility I propose keeping setScrollRange() and add new API setScrollStart() ... now getScrollPosition() simply adds value of scroll-start value. You could also add overridden setScrollRange(int start,int end) method.

Motivation of this is if you have a scrollbar representing a value which can be in range -100 -> +200, it saves having to write extra code in our app every time.

Apostate

02-08-2012 00:32:33

I would like some more control over the placement of widgets. Essentially what I want is the ability to set % or pixel for the dimensions of a widget on a per-side basis, with a few additions. I made up a little mockup demonstrating what I would like to be able to do:



In Red:
1) Width
2) Height
3) Offset from bottom
4) Offset from right

In Blue:
1) Offset from right
2) Height
3) Offset from bottom
4) Offset from left

These are in terms of the parent widget. This way, even if you resize the window, the button and editbox will stay the same height, while the button will stay the same width and the editbox will fill the extra/reduced space.

I think this is similar to the Align properties, but it should be a fairly simple change that would give more control over how widgets react to their parent changing size. The align properties are really confusing for me :|

my.name

03-08-2012 12:44:13

EditBox align - HStretch Bottom
Button align - Right Bottom

Apostate

03-09-2012 21:24:53

That works. I guess I was just assuming, based off the names, that the editbox would stretch disproportionately and end up covering up the button (if you scaled up) or leaving a big gap (if you scaled down). I'm dumb. It would still be nice to be able to use pixel positions and percent positions on individual dimensions without having to switch back and forth, but that's not super important.

getdev

07-11-2012 21:26:08

It would be nice, if will be the ability to create graphs (UML), as in the blender:

my.name

08-11-2012 08:34:42

Look at GraphView unit test

Altren

09-11-2012 14:45:18

Transporter

14-11-2012 15:32:52

This has probably been asked before... but it would be really nice if code comments were in English. As well as meaning the comments are meaningless to the majority of us, it raises a barrier to contributing.
Agree :!: :!: :!:

Apostate

28-03-2013 16:11:33

I see there's a TreeControl in the UnitTest folder. Is there any hope of being able to use it soon? It looks like it was mentioned at the start of this thread in 2009, but I'm assuming it's not ready yet?

hahaer

07-05-2013 00:13:25

When Ogre render window is in a extarnal window, MyGUI make render window can not resize and move correctly.
So maybe mannual resize or move method is needed for MyGUI

only_a_ptr

13-06-2013 11:42:13

Hi.

I just wrote my own code template and looked for a way to use it with LayoutEditor.

My search ended in MyGUI_3.2.0\Tools\LayoutEditor\CodeGenerator.cpp:// FIXME hardcoded template
const std::string TemplateName = "BaseLayoutCPP.xml";

Make customizable, please :mrgreen:

Crystal Hammer

15-08-2014 10:23:45

Hi. Firstly I want to say I really like MyGUI, awesome library !

So, from the things I really missed over the last 4 years, and
IMO it'd be great to have them implemented someday.

Let me start with those BIG tasks to code first.

- Layout Editor: Multi-select.
Big thing and complicated but, I mean the simplest one possible:
Add/remove to selection with shift click (or ctrl).
When you have multiple widgets selected you can move them all at once (with mouse or keyboard).
Also just hide/disable properties. Too complicated to detect if are shared etc.
Maybe later just allow (editing for all selected) color, alpha, font etc. (those properties that are common for all widget types).
Moving lots of widgets each one separately is tedious and prone to offset error, and setting positions in .layout by editing digits is even more tedious.

- Built-in widget and font resizing with screen resolution.
Yeah I know. Big and complicated. But definitely possible, even now and IMO very needed.
We do it in our code, is just unconvenient and bit buggy too, since we got ScrollView area staying same size.

- Generally many things are much quicker to do by editing .layout file, or simply impossible to do in Layout Editor. Like the 2nd one from below, or changing parent of widget (or even worse for many). In .layout it's just copy paste.

And just a few small bugs:

- Layout Editor: Auto load last project doesn't work. Starts empty.
- Layout Editor: If you have e.g. a widget at position 500 500 in a widget that has size 300 300, then you can't pick it, and don't see it. Well other than in the menu. I would just show some rectangle or something so it's easy to pick it by mouse.
- Layout Editor: zoom to point is very cool, but can't zoom back to left, top (offset 0,0), unless you have mouse at 0,0, so always have to move those sliders back to 0.

Spire

20-08-2014 04:07:08

- Built-in widget and font resizing with screen resolution.
Yeah I know. Big and complicated. But definitely possible, even now and IMO very needed.
We do it in our code, is just unconvenient and bit buggy too, since we got ScrollView area staying same size.

How do you do this? If you post some code somewhere (such as in a new thread), I might be able to look into it and see if it can be integrated directly into MyGUI.