My wxWidgets 3.0 changes wishlist

[SnakeChomp]

I am starting this thread to discuss the things I'd like to see in wxWidgets 3.0. I will not be personally mirroring my suggestions here to wx-dev.

[SnakeChomp]

Modernizing event identifier declarations

I just had this idea tonight, and just finished adding it into OMGUI, so I can say to you that I have implemented this and it works fine. These changes fall under the broader category of modernizing wxWidgets.

I would like to see a templated class used to declare all of the events which can be emitted by a widget of a certain type, T. Something like this:

Code: Select all

typedef int event_id;

template<typename T> class WXEXPORT event_traits;

/*!
    Lists all of the events emmited by Widgets
*/
template<> class event_traits<Widget>
{
public:
    //! The widget was created
    static const event_id CREATE;
    //! The widget is about to be destroyed
    static const event_id DESTROY;
    //! The size of a widget has changed
    static const event_id SIZECHANGE;
    //! The mouse entered the widget's client area
    static const event_id MOUSE_ENTER;
    //! The mouse left the widget's client area
    static const event_id MOUSE_LEAVE;
    //! The mouse moved within the widget's client area
    static const event_id MOUSE_MOVE;
    //! The mouse was stationary within the widget's client area for a period of time
    static const event_id MOUSE_HOVER;
    //! The left mouse button was pressed within the widget's client area
    static const event_id MOUSE_LEFT_DOWN;
    //! The left mouse button was released within the widget's client area
    static const event_id MOUSE_LEFT_UP;
    //! The left mose button was double clicked within the widget's client area
    static const event_id MOUSE_LEFT_DOUBLECLICK;
    //! The right mouse button was pressed within the widget's client area
    static const event_id MOUSE_RIGHT_DOWN;
    //! The right mouse button was released within the widget's client area
    static const event_id MOUSE_RIGHT_UP;
    //! The middle mose button was double clicked within the widget's client area
    static const event_id MOUSE_RIGHT_DOUBLECLICK;
    //! The middle mouse button was pressed within the widget's client area
    static const event_id MOUSE_MIDDLE_DOWN;
    //! The middle mouse button was released within the widget's client area
    static const event_id MOUSE_MIDDLE_UP;
    //! The middle mose button was double clicked within the widget's client area
    static const event_id MOUSE_MIDDLE_DOUBLECLICK;
};

/*!
    Lists all of the events emitted by Windows
*/
template<> class event_traits<Window> : public event_traits<Widget>
{
public:
    //! The window is being closed
    static const event_id CLOSE;
};

template<> class event_traits<Notebook> : public event_traits<Widget>
{
public:
    //! The currently selected NotebookPage has changed
    static const event_id PAGE_CHANGED;
    //! A different NotebookPage is about to be selected
    static const event_id PAGE_CHANGING;
};

/* etc for all other widgets that emit events */

The class members would be implemented in some source file somewhere, not in the header.

Why is this good? Firstly, its vastly more organized than using macros with various name prefixes. The event identifiers are grouped according to the widget that sends them, giving them a more well defined scope than wxWidgets currently has. Even without adding namespaces to wxWidgets, this change would eliminate potential naming conflicts and remove the need to for the c-style namespace prefix of "wxEVT_". Secondly, it makes documenting the event types, and finding out what event types can be emitted by Foo extremely easy. The comments contained in the code are doxygen comments. The documentation for the Widget class simply links to event_traits<Widget>, and the person reading the documentation can immediately find out a complete listing of all events that Widgets will ever emit. You can visit this page to see the results from a documentation standpoint: http://www.omgui.org/docs/classomgui_1_1_widget.html . Lastly, these classes are template friendly, and can be used to templatize the entire event connecting system to prevent you from connecting an event to an object that never actually emits such an event. By the same token, event type safety can also be gaurenteed via template magics instead of the macro casting funni business currently employed.

[ABX]

I am starting this thread to discuss the things I'd like to see in wxWidgets 3.0.

Well, after first "wish" I'm under impression you are starting this thread to advertise your own wxWidgets equivalent...

I will not be personally mirroring my suggestions here to wx-dev.

Thanks for courtesy with informing about it, but... any suggestion what's the purpose of this information?

ABX

[SnakeChomp]

Well, after first "wish" I'm under impression you are starting this thread to advertise your own wxWidgets equivalent...

To advertise my own incomplete toolkit which could not be actually used by anyone in its current state? Yeah, thats what I'm really doing here... This thread exists because adding suggestions for changes that can be made to wxWidgets 3 are not really appropriate in a thread titled "Why I don't like wxWidgets" so I will be posting them here. Is it my fault that I use OMGUI as a platform to test my ideas to make sure they work before suggesting them? Of course not. Would you rather I just blindly throw ideas around that might not work in practice just to avoid "advertising"?

Thanks for courtesy with informing about it, but... any suggestion what's the purpose of this information?

The purpose of this information is to hopefully bring about some useful ideas and or discussion for new things to do in future versions of wxWidgets, somewhat parallel to my other thread, but presented in a less aggresive manner. upCASE has said that he doesn't believe the mailing list is a suitable place for future discussions like these and I agree with him, which is why I won't be posting to wx-dev for now. If there is ever a point where discussions about the future crop up on wx-dev, and actually show promise of going somewhere, that would be my cue to chime in.

[ABX]

Would you rather I just blindly throw ideas around that might not work in practice just to avoid "advertising"?

No, not at all. It makes sense to use some working model but IIRC there is currently licence conflict with moving code from OMGUI to wxW so once it is done in OMGUI it will be harder movable to wxW. Please correct me if I'm wrong, I'm poor with all these licence problems.

upCASE has said that he doesn't believe the mailing list is a suitable place for future discussions like these and I agree with him

I will say obvious things here but... wxTNG/3.0 (and wxWidgets in general) is supposed to be cooperative work. The development goes by joining previous effort by new volunteers one by one. New volunteers come with new ideas in wide range: from new doc systems, through new classes, to new ways of communicating with community. I really do not mind such discussion here at all. But (hopefully wrongly) I find you going towards clash without lifting a finger to at least inform the most interested persons that this discussion started. For somebody who posted to wx-dev several times like you it is really not that difficoult to post once again with "I started wxW 3.0 wishlist at http://..." or "I expressed why I don't like wxW at http://... with some suggestions about wxTNG". We both know you could do that but you didn't so I have hard time with understanding your motivations better. For now I guess you want to choose yourself best time for forwarding this to wx-discuss, wx-dev or feature requests tracker. Therefore I will sit silent and wait when you will be interested in sharing your thread with other wx-developers yourself. Looking forward to see your posts there. Thanks in advance.

Regards,

ABX

[SnakeChomp]

No, not at all. It makes sense to use some working model but IIRC there is currently licence conflict with moving code from OMGUI to wxW so once it is done in OMGUI it will be harder movable to wxW. Please correct me if I'm wrong, I'm poor with all these licence problems.

I am the main developer of OMGUI, and I wrote all of the front end code, which includes the entire API. If I want to donate said code to wxWidgets, I am fully capable of simply releasing the code to you guys under the wxWidgets license, as I hold copyrights on everything.

post once again with "I started wxW 3.0 wishlist at http://..." or "I expressed why I don't like wxW at http://... with some suggestions about wxTNG". We both know you could do that but you didn't so I have hard time with understanding your motivations better.

I simply assumed that by posting to wx-dev that the devs would want to continue the discussion there. I'd rather not have discussion continuing both here and wx-dev. I don't have a whole lot more to say right now unless you count the things that have been said before, like using doxygen or namespaces, and until I do have a lot to say a discussion on wx-dev would likely go nowhere.

[Jamie]

I am the main developer of OMGUI, and I wrote all of the front end code, which includes the entire API. If I want to donate said code to wxWidgets, I am fully capable of simply releasing the code to you guys under the wxWidgets license, as I hold copyrights on everything.

With all due respect, why the if? I've previously downloaded and compiled omgui/cpaf and if it used the wxWindows LIbrary Licence, I (and probably others) would be more interested in contributing.

[mispunt]

It is nice to have such sugestions IMO, and the code that snake is showing is just an example. It doesn't have to be used.

What disapoints me is the slightly negative reaction of ABX. Well, perhaps I read it to negative, but I think you both (and of course the rest of the people) should better stop the flameware that is going on on this forum. I know, I am not posting very often on this forum, so probably I don't have the rights to say much about these annoying reactions.... (it's more something a moderator or an admin should do IMO, and no, it is not my intention to judge the admins and the mods here)

[priyank_bolia]

SnakeChomp are you also against the Event tables, they also uses macros, then people would definately argue removing that also and using connect or other slot mechnaism (I don't know what it is). I am surely 100% against it, as they provide one of the fatest and easiest way to maintain event handlers.

[priyank_bolia]

It is nice to have such sugestions IMO, and the code that snake is showing is just an example. It doesn't have to be used.

What disapoints me is the slightly negative reaction of ABX. Well, perhaps I read it to negative, but I think you both (and of course the rest of the people) should better stop the flameware that is going on on this forum. I know, I am not posting very often on this forum, so probably I don't have the rights to say much about these annoying reactions.... (it's more something a moderator or an admin should do IMO, and no, it is not my intention to judge the admins and the mods here)

I think its a heathly discussion and all are doing there job fine. I didn't see any flames, just some people disagreement on the design doesn't mean flames. We had such things always in my projects, nobody agress to my design unfortunately

[priyank_bolia]

My wish list:
1.) Better DC support, for writting owner drawn custom controls, that where people argue me, about MFC and Qt GUI.
2.) latest C++ support, string safe functions.
3.) Extensive use of STL based data structures and boost based smartpointers. see.
4.) Image and network classes to deliver more performance.

[ABX]

What disapoints me is the slightly negative reaction of ABX.

It is worth to note that my reaction was mainly related to selecting audience. I very like wxForum for great community support and sharing code. But it does not change that obligatory place where all people with write access are reading is different. In other words what I wrote is not different from suggesting to somebody who found a bug to jump to bug tracker and fill-in report. The only difference (which perhaps raised some irritation) is that I was talking to somebody who knows routines, used them in the past and had wx-discuss suggested previously. Just like Julian said a few days ago in wx-dev, there is enough place to build separated source trees for wxTNG experimentation in more that one subtree. But in selecting new team members and giving them write access it is very important to find how they cooperate with teams where some members disagree. Willingness to follow established routines is one criteria in my personal opinion.

Sorry if my redirecting-issues-job looked like flamewar. I will try to improve my not perfect english but choosing most suitable phrases and terms is not easy

ABX

[mispunt]

Sorry if my redirecting-issues-job looked like flamewar. I will try to improve my not perfect english but choosing most suitable phrases and terms is not easy

I know that problem, really I do, but thanks for exlaining it a bit for me

[leio]

I've previously downloaded and compiled omgui/cpaf and if it used the wxWindows LIbrary Licence, I (and probably others) would be more interested in contributing.

This can very well have an opposite reaction aswell - it depends where the contributors come from. If from wxWindows community, then what you are saying is likely true, but otherwise..

LGPL is a fine license, and a widely accepted and known at that.

The main concern why the need for a wxWindows license seems to be that this allows without doubt static linkage of the library.
We intend to name the libraries proper, and have good documented sense of versioning and API/ABI compatibility (that doesn't mean wxWidgets might not have that these days), so linking dynamically should not be a problem. We can provide NSI scripts and other tools to make it easier for release managers of applications to re-use a commonly installed OMGUI library if it exists, and properly install one into "Common Files" if it doesn't - like GTK+ does.
Given our design decisions, putting the main() part of the library under public domain should not be a problem either, as to allow statically linking just the tiny parts that ARE necessary to be done as such.

LGPL also for example gives us the ability to copy new GTK+ and other library code into the OMGUI library (of course giving proper credit as appropriate), instead of reinventing the wheel.
Know all the hacks in wxGTK for if GTK+ version is 2.4 to use some code path, and if it's earlier, use another? Well, with LGPL licensed library we can just provide the new code when necessary ourselves imported into our sources, and wrap only that, instead of having two different implementations (one for the new control, and one for the deprecated old one, which tends to be buggy as a bonus) to manage.

I believe this thread is by now in a need of a thread split...

[Jamie]

This can very well have an opposite reaction aswell - it depends where the contributors come from. If from wxWindows community, then what you are saying is likely true, but otherwise..

Yes, but isn't this a discussion about what people would like to see in wxWidgets? I think if someone is going to suggest improvements then the licence issue should be extremely clear.

LGPL is a fine license, and a widely accepted and known at that.

Sure, agreed.

The main concern why the need for a wxWindows license seems to be that this allows without doubt static linkage of the library.

Exactly.

We intend to name the libraries proper, and have good documented sense of versioning and API/ABI compatibility (that doesn't mean wxWidgets might not have that these days), so linking dynamically should not be a problem. We can provide NSI scripts and other tools to make it easier for release managers of applications to re-use a commonly installed OMGUI library if it exists, and properly install one into "Common Files" if it doesn't - like GTK+ does.

Sounds good, but it is still a hassle for Windows users. If I want to distribute even a little program then I must do it as a minimum of n + 1 pieces where n equals the number of LGPL libraries used.

LGPL also for example gives us the ability to copy new GTK+ and other library code into the OMGUI library (of course giving proper credit as appropriate), instead of reinventing the wheel.
Know all the hacks in wxGTK for if GTK+ version is 2.4 to use some code path, and if it's earlier, use another? Well, with LGPL licensed library we can just provide the new code when necessary ourselves imported into our sources, and wrap only that, instead of having two different implementations (one for the new control, and one for the deprecated old one, which tends to be buggy as a bonus) to manage.

Very nice. I've certainly had to deal with wxGTK oddities before.... But why make life harder for Windows users?

Let me just state for the record that I prefer Linux and use it at home and at work. But isn't the point of a cross-platform library to make it easy to develop for all platforms it supports?

If I wanted to only support Linux, I'd use (and have done so in the past) GTK+. The reason why I use wxWidgets is that I need to support Windows as well. Why not segregate the GTK+ port from the rest of the library? That way you can use all the LGPL stuff you want for Linux, and have a static linking exception on the other platforms (assuming they don't use any LGPL code).