My wxWidgets 3.0 changes wishlist
Posted: Mon Dec 26, 2005 9:57 am
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.
Official forum for the wxWidgets Cross-Platform GUI Toolkit
https://forums.wxwidgets.org/
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 */
Well, after first "wish" I'm under impression you are starting this thread to advertise your own wxWidgets equivalent...SnakeChomp wrote:I am starting this thread to discuss the things I'd like to see in wxWidgets 3.0.
Thanks for courtesy with informing about it, but... any suggestion what's the purpose of this information?SnakeChomp wrote:I will not be personally mirroring my suggestions here to wx-dev.
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"?ABX wrote:Well, after first "wish" I'm under impression you are starting this thread to advertise your own wxWidgets equivalent...
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 wrote:Thanks for courtesy with informing about it, but... any suggestion what's the purpose of this information?
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.SnakeChomp wrote:Would you rather I just blindly throw ideas around that might not work in practice just to avoid "advertising"?
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.SnakeChomp wrote: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 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.ABX wrote: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 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.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.
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.SnakeChomp wrote: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.
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 unfortunatelymispunt wrote: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)
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.mispunt wrote:What disapoints me is the slightly negative reaction of ABX.
I know that problem, really I do, but thanks for exlaining it a bit for meABX wrote: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
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..Jamie wrote: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.
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.leio wrote: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..
Sure, agreed.leio wrote:LGPL is a fine license, and a widely accepted and known at that.
Exactly.leio wrote:The main concern why the need for a wxWindows license seems to be that this allows without doubt static linkage of the library.
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.leio wrote: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.
Very nice. I've certainly had to deal with wxGTK oddities before.... But why make life harder for Windows users?leio wrote: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.