My wxWidgets 3.0 changes wishlist

This forum is reserved for everything you want to talk about. It could be about programming, opinions, open source programs, development in general, or just cool stuff to share!
SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am
Contact:

Re: My wxWidgets 3.0 changes wishlist

Post by SnakeChomp » Tue Dec 27, 2005 10:11 pm

Jamie wrote:With all due respect, why the if?
It means exactly what it says. If I want to give my code to wxWidgets, I will, and if I don't, I won't.
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.
Jamie wrote: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.
n+1 pieces? What? You can distribute one zip file, or one installer executable, which contains all of your pieces and does the right things with them. That sounds like 1 piece to me, just like every other program in all of creation.

SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am
Contact:

Post by SnakeChomp » Tue Dec 27, 2005 10:17 pm

priyank_bolia wrote: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.
You can put a bunch of connect() statements into a constructor and achieve the exact same effect as an event table, except it doesn't rely on preprocessor magic and looks more like real C++ code IMO. All the event handlers are in one spot, and can easily be changed. If you were insane, you could do something like defining EVT_FOO's for anything that can be connected and use them within a constructor, but thats just completely silly. There is no reason for having static event tables anyway and I believe even Vadim is against them in favor of Connect().

Jamie
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 205
Joined: Wed Mar 30, 2005 10:56 pm

Re: My wxWidgets 3.0 changes wishlist

Post by Jamie » Wed Dec 28, 2005 12:24 am

SnakeChomp wrote:It means exactly what it says. If I want to give my code to wxWidgets, I will, and if I don't, I won't.
So why make suggestions on how to fix wxWidgets then? At least when making suggestions and posting sample code clearly state what the licence for it is.
SnakeChomp wrote:n+1 pieces? What? You can distribute one zip file, or one installer executable, which contains all of your pieces and does the right things with them. That sounds like 1 piece to me, just like every other program in all of creation.
But then I have to explain to users why my little program needs a full installer instead of just running it. If I zip it up then I need to explain why they can't delete any of the dll files needed because of LGPL linking requirements. Not exactly user friendly, is it?

User avatar
ABX
Can't get richer than this
Can't get richer than this
Posts: 810
Joined: Mon Sep 06, 2004 1:43 pm
Location: Poznan, Poland
Contact:

Re: My wxWidgets 3.0 changes wishlist

Post by ABX » Wed Dec 28, 2005 12:39 am

Jamie wrote:At least when making suggestions and posting sample code clearly state what the licence for it is.
FYI 10th entry at http://forums.wxwidgets.org/viewtopic.php?t=2

ABX
CVS Head, 2.8.X
wxMSW, wxWinCE, wxPalmOS, wxOS2, wxMGL, bakefile
gcc 3.2.3, bcc 5.51, dmc 8.48, ow 1.6, vc 7.1, evc 3/4, pods 1.2

SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am
Contact:

Re: My wxWidgets 3.0 changes wishlist

Post by SnakeChomp » Wed Dec 28, 2005 2:59 am

Jamie wrote:So why make suggestions on how to fix wxWidgets then? At least when making suggestions and posting sample code clearly state what the licence for it is.
Point 10 states that pasted code without a license is public domain. Seeing as my pasted code has no license, its in the public domain. I cannot try to copyright the idea of using templates to declare event identifiers, as the code that two people would come up with when implementing templates to store event identifiers would be more or less identical anyway, so why are you making such a huge fuss over this?
But then I have to explain to users why my little program needs a full installer instead of just running it. If I zip it up then I need to explain why they can't delete any of the dll files needed because of LGPL linking requirements. Not exactly user friendly, is it?
Who on earth are you writing programs for? They are going to delete dlls that came with the program and expect things to still work? What kind of nonsense is this? Thats like deleting a dll out of c:\windows\system32 and expecting windows to still work. Lets be reasonable. Most user friendly (windows) applications have installers, and most applications worth using are of the non-trivial sort as to actually require installers.

Jamie
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 205
Joined: Wed Mar 30, 2005 10:56 pm

Re: My wxWidgets 3.0 changes wishlist

Post by Jamie » Wed Dec 28, 2005 7:41 am

SnakeChomp wrote:Point 10 states that pasted code without a license is public domain. Seeing as my pasted code has no license, its in the public domain. I cannot try to copyright the idea of using templates to declare event identifiers, as the code that two people would come up with when implementing templates to store event identifiers would be more or less identical anyway, so why are you making such a huge fuss over this?
Point taken, I just wanted clarity on the issue. I must confess to not having fully read the rules...
SnakeChomp wrote:Who on earth are you writing programs for? They are going to delete dlls that came with the program and expect things to still work? What kind of nonsense is this? Thats like deleting a dll out of c:\windows\system32 and expecting windows to still work. Lets be reasonable. Most user friendly (windows) applications have installers, and most applications worth using are of the non-trivial sort as to actually require installers.
I agree, however it wouldn't be the first time it has happened (deleting dlls). Unfortunately it seems the majority of Windows users are that clueless. Sometimes a client insists on a self-contained executable, just presenting a different POV.

Thanks for hearing me out, I will continue this discussion in the appropriate channels.

BTW great work wrt wxIFM.

Ksmith22
I live to help wx-kind
I live to help wx-kind
Posts: 199
Joined: Mon Nov 21, 2005 4:34 pm

Post by Ksmith22 » Wed Dec 28, 2005 2:31 pm

Don't forget accidental deletions. I personally prefer to keep as much contained in my EXE as possible.

priyank_bolia
wxWorld Domination!
wxWorld Domination!
Posts: 1339
Joined: Wed Aug 03, 2005 8:10 am
Location: BANGALORE, INDIA
Contact:

Post by priyank_bolia » Wed Dec 28, 2005 3:27 pm

Ksmith22 wrote:Don't forget accidental deletions. I personally prefer to keep as much contained in my EXE as possible.
A repair wizard in setup...

lowjoel
Moderator
Moderator
Posts: 1511
Joined: Sun Jun 19, 2005 11:37 am
Location: Singapore
Contact:

Post by lowjoel » Wed Dec 28, 2005 11:34 pm

i dont think NSIS nor INNO has that, MSI tools are too expensive...

leio
Can't get richer than this
Can't get richer than this
Posts: 802
Joined: Mon Dec 27, 2004 10:46 am
Location: Estonia, Tallinn
Contact:

Post by leio » Wed Dec 28, 2005 11:50 pm

That particular user might just as well "accidentally" delete the exe file. I fail to see why is all of this relevant or an issue at all.
Besides, quite some programs installed from an installer, inject something that make explorer warn on deletion that one or several (blahblah) applications might stop working if you go on with the delation blahblah.
Compilers: gcc-3.3.6, gcc-3.4.5, gcc-4.0.2, gcc-4.1.0 and MSVC6
OS's: Gentoo Linux, WinXP; WX: CVS HEAD

Project Manager of wxMUD - http://wxmud.sf.net/
Developer of wxGTK;
gtk+ port maintainer of OMGUI - http://www.omgui.org/

priyank_bolia
wxWorld Domination!
wxWorld Domination!
Posts: 1339
Joined: Wed Aug 03, 2005 8:10 am
Location: BANGALORE, INDIA
Contact:

Post by priyank_bolia » Thu Dec 29, 2005 5:49 am

Anyway leave all that, the forum is for: My wxWidgets 3.0 changes wishlist

SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am
Contact:

Getting back on track...

Post by SnakeChomp » Wed Jan 04, 2006 10:51 am

I probably sound pretentious in this post. Sorry.

In an attempt to continue discussion on the topic at hand, I have decided to take a look at the single most ugly class in wxWidgets: wxWindow. This class adds plenty of fat to the library with a ton of functions which are occasionally out of place or have little benefit.

Useless flags:
  • wxHSCROLL, wxVSCROLL . The problems with these are obvious, and I have already outlined them in a preivous post. In brief, wxScrolledWindow exists, so why do these? These flags only serve to make the library bigger due to the necessary code to support them on platforms which aren't Windows.
  • wxCLIP_CHILDREN. A Windows only flag that should never be turned off. It's probably on by default anyway. Why does this exist? Just get rid of it.
  • wxALWAYS_SHOW_SB. Another Windows only flag that isn't really useful at all in the context of wxWindow. It probably only exists to coincide with wxHSCROLL and wxVSCROLL flags. This flag only makes sense in a small subset of widgets, so why isn't this documented in the widgets where it matters? Alas, documentation problems are for another post.
Methods that make me ask why?
  • Every function which takes a wxSize, wxRect, wxPoint argument and has overloads for integers. Why are there so many ways of doing the same thing? If there weren't so many overloads, the "virtual function hiding" problem would never have happened, and the need for DoFoo functions would be nonexistant. Wouldn't that be nice? I would prefer that one single version of the interface was provided, either for ints, or wxSize,wxRect,wxPoint. Since these objects exist, its natural to be using them exclusively.
  • wxWindow::SetOwnBackgroundColour and co. This collection of methods seems like a very poor way of allowing someone to change the background of all of the nested panels in their application easily, which is more often than not a silly idea in the first place. The entire API relating to wxWindow::InheritAttributes is flawed IMO. A much simpler way to set the background color of your wxFrame and to have all child wxPanels inherit it is so simply add a boolean argument to wxWindow::SetBackgroundColor which indicates whether or not the background color should be inherited by children. I know you have an aversion to boolean arguments, but don't worry, because an even better idea is to not have any of this cruft in the library at all, and simply let everyone who wishes to make ugly skinned applications manually set the background colors of all their panels themselves. Its really not hard for them to do that, is it? So why go to all this trouble to cater for the definitive minority?
  • wxWindow::IsExposed. Or, you could do this more correctly by calling wxWindow::GetUpdateRegion and querying that to see if your point is exposed. Why are there two ways to do the same thing? All its doing is increasing the size of my binaries.
  • wxWindow::InitDialog. InitDialog? wxWindow's aren't wxDialogs, so this function is in the wrong spot. Does wxStaticBitmap::InitDialog make any sense?
  • wxWindow::SetTitle. "Sets the window's title. Applicable only to frames and dialogs." Ok, so if its only useable by wxTopLevel, why isn't it a member of wxTopLevel instead of wxWindow?
  • wxWindow::SetLabel. This obviously only makes sense for things like buttons, labels, radio buttons, and etc, so why is this function a member of wxWindow? What does wxFrame::SetLabel do?
  • wxWindow::GetBestSize, wxWindow::GetBestFittingSize, wxWindow::GetAdjustedBestSize. Can pick just one function that is supposed to work all the time and use it please?
  • wxWindow::GetConstraints. I don't think that removing wxLayoutConstraints and anything relating to it requires any explanation. Can we finally do this now?
  • wxWindow::OnInternalIdle. "This virtual function is normally only used internally, but sometimes an application may need it to implement functionality that should not be disabled by an application defining an OnIdle handler in a derived class." *blink* What? So even the documentation admits that this function only exists to work around the potential that somebody poorly designed their application? Why must we all be made to suffer?
  • wxWindow::SetScrollbar, wxWindow::GetScroll*, wxWindow::ScrollLines, wxWindow::HasScrollbar, wxWindow::ScrollPages, wxWindow::SetScrollPos, etc. These functions only exist because wxHSCROLL and wxVSCROLL do. The fact that these functions exist in wxWindow means that I can ask a wxStaticBitmap where its scrollbar thumb is currently located. Does this sound silly to anybody else?
  • wxWindow::GetGrandParent. This is most definately one fat function. Its certainly easy enough for the (few) users who need specifically the parent of the parent to simply call GetParent twice, this function is definately not needed in the API.
  • wxWindow::ClearBackground. The purpose of this function sounds obvious enoguh, but its benefit is dubious at best. If someone is doing drawing where they must erase the entire background before drawing again, they had better be using some form of buffering or their application will flicker like nothing has flickered before. Considering that flicker is a huge issue in wxWidgets as it is, why even give people the option of doing soemthing that will flicker? This method is uneccesary.
  • wxWindow::Center*, wxWindow::Centre*. Is it really necessary support two spellings of these methods?
  • wxWindow::GetWindowStyleFlag, wxWindow::GetWindowStyle. Same argument as above. The latter isn't even officially documented, its merely mentioned in the documentation for the former.
  • wxWindow::SetPalette. Function documentation states its obsolete, so lets remove it.
All of the above functions and flags should simply be removed from wxWidgets, or moved from wxWindow into the class in which they belong.

My biggest problem with wxWindow...
is the fact that it can be constructed directly. Why? Why can you construct both wxWindows and wxPanels? What is the difference between a wxWindow with no children and a wxPanel with no children? In fact, the difference is minor, wxWindow simply lacks a few functions for setting default items and other stuff. However, it should be stressed that wxWindow is supposed to serve as the base interface for all widgets in the library, so why is the base interface also constructable? It is my belief that wxPanel should be constructable to serve as the "blank slate" on which to craft your own custom controls, not wxWindow.

One thing I would really love...
...is for wxWindow::Show() to be able to show a window without activating it. This could even be added to wx 2. I mentioned this a while ago and was told to submit a patch.

priyank_bolia
wxWorld Domination!
wxWorld Domination!
Posts: 1339
Joined: Wed Aug 03, 2005 8:10 am
Location: BANGALORE, INDIA
Contact:

Post by priyank_bolia » Wed Jan 04, 2006 5:33 pm

Sorry to say, but some of your initial remarks makes me to assume that you want all the current applications to break and removed support for window and make wxWidgets instead of cross platform just another linux graphical library. Or all windows users (whom you call minority) to learn again another programming language. wxWidgets similarity to MFC is just a great reason windows people adopt wxWidgets, only the intial starup time was large at my time, because there was no proper article about that, but once I had everything in place, the road ahead was very smooth as only the classes name were different, rest a lot was the same. I guess my article and wizard will help to decrease that initial learning curve too.

wxSize, wxRect, wxPoint argument - thats the ease

wxWindow::SetOwnBackgroundColour- even is the API is faulty we have to go by the way the environment does it, and not device our own standard.

GetUpdateRegion and point are differnt things and used differently in real situations.

The fact that these functions exist in wxWindow means that I can ask a wxStaticBitmap where its scrollbar thumb is currently located. Does this sound silly to anybody else? No, why can't you have a derived class which does it own painting, and it scrollable for very large pictures.

wxWindow::ClearBackground, because windows people are used to override the erase background handler for flickr removal and when they need to erase the background, I think thats the choice given.

One the spelling issue I support wxWidgets team, In fact it creates a lot of problem to me always to use colour instead of color as all major API uses colour. But this is not the english followed in a large world. MFC uses color and also all my tools give spelling error for that. now, who will decide that the wxWidgets team english is right and the MFC developers and the rest of the world english is wrong.

If the documentation says its obsolete, post a bug, recently I asked them to remove wxCloseEvent::GetForce and its has been removed.

SnakeChomp
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 235
Joined: Sun Oct 10, 2004 2:53 am
Contact:

Post by SnakeChomp » Wed Jan 04, 2006 10:07 pm

priyank_bolia wrote:Sorry to say, but some of your initial remarks makes me to assume that you want all the current applications to break and removed support for window and make wxWidgets instead of cross platform just another linux graphical library. Or all windows users (whom you call minority) to learn again another programming language. wxWidgets similarity to MFC is just a great reason windows people adopt wxWidgets, only the intial starup time was large at my time, because there was no proper article about that, but once I had everything in place, the road ahead was very smooth as only the classes name were different, rest a lot was the same. I guess my article and wizard will help to decrease that initial learning curve too.
I don't remember asking to remove support for Windows? And did I ever try to call windows users a minority? Where are you coming up with that stuff?
wxSize, wxRect, wxPoint argument - thats the ease
I don't know what this means.
wxWindow::SetOwnBackgroundColour- even is the API is faulty we have to go by the way the environment does it, and not device our own standard.
The envorinment? What envorinment?
GetUpdateRegion and point are differnt things and used differently in real situations.
Again, I don't know what you are trying to say.
No, why can't you have a derived class which does it own painting, and it scrollable for very large pictures.
Put a picture into a wxScrolledWindow, like you are supposed to do anyway.
wxWindow::ClearBackground, because windows people are used to override the erase background handler for flickr removal and when they need to erase the background, I think thats the choice given.
Whats the point in overriding erase background to remove flicker if you are just going to call a function which induces flicker in your application?

phlox81
wxWorld Domination!
wxWorld Domination!
Posts: 1387
Joined: Thu Aug 18, 2005 7:49 pm
Location: Germany
Contact:

Post by phlox81 » Thu Jan 05, 2006 3:19 pm

The more cooks you have, the more salt is in the soup...

Post Reply