You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(37) |
Aug
(66) |
Sep
(2) |
Oct
(3) |
Nov
(48) |
Dec
(65) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(12) |
Feb
(22) |
Mar
(30) |
Apr
(20) |
May
(73) |
Jun
(23) |
Jul
(44) |
Aug
(20) |
Sep
(27) |
Oct
(33) |
Nov
(30) |
Dec
(49) |
2004 |
Jan
(36) |
Feb
(31) |
Mar
(76) |
Apr
(64) |
May
(104) |
Jun
(22) |
Jul
(24) |
Aug
(49) |
Sep
(48) |
Oct
(50) |
Nov
(50) |
Dec
(47) |
2005 |
Jan
(43) |
Feb
(40) |
Mar
(19) |
Apr
(68) |
May
(21) |
Jun
(69) |
Jul
(29) |
Aug
(61) |
Sep
(57) |
Oct
(27) |
Nov
(54) |
Dec
(31) |
2006 |
Jan
(15) |
Feb
(13) |
Mar
(25) |
Apr
(18) |
May
(21) |
Jun
(7) |
Jul
(7) |
Aug
(15) |
Sep
(8) |
Oct
(44) |
Nov
(54) |
Dec
(39) |
2007 |
Jan
(34) |
Feb
(41) |
Mar
(119) |
Apr
(59) |
May
(6) |
Jun
(9) |
Jul
(18) |
Aug
(61) |
Sep
(74) |
Oct
(44) |
Nov
(23) |
Dec
(17) |
2008 |
Jan
(18) |
Feb
(21) |
Mar
(25) |
Apr
(10) |
May
(16) |
Jun
(13) |
Jul
(17) |
Aug
(7) |
Sep
(16) |
Oct
(16) |
Nov
(18) |
Dec
(4) |
2009 |
Jan
(11) |
Feb
(4) |
Mar
(4) |
Apr
(10) |
May
(18) |
Jun
(8) |
Jul
(5) |
Aug
(8) |
Sep
(9) |
Oct
(34) |
Nov
(4) |
Dec
(13) |
2010 |
Jan
(7) |
Feb
(4) |
Mar
(9) |
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(14) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(11) |
Jun
(9) |
Jul
(12) |
Aug
(18) |
Sep
(3) |
Oct
(1) |
Nov
(6) |
Dec
(23) |
2012 |
Jan
(11) |
Feb
(13) |
Mar
(17) |
Apr
(10) |
May
(13) |
Jun
(10) |
Jul
(6) |
Aug
|
Sep
(3) |
Oct
(3) |
Nov
(5) |
Dec
(4) |
2013 |
Jan
(6) |
Feb
(3) |
Mar
(26) |
Apr
(14) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(7) |
2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(3) |
Sep
(1) |
Oct
(22) |
Nov
(8) |
Dec
(2) |
2015 |
Jan
(9) |
Feb
(7) |
Mar
(5) |
Apr
(5) |
May
(4) |
Jun
(5) |
Jul
|
Aug
(11) |
Sep
(2) |
Oct
(19) |
Nov
(14) |
Dec
(6) |
2016 |
Jan
(5) |
Feb
(30) |
Mar
(7) |
Apr
(5) |
May
(13) |
Jun
(2) |
Jul
|
Aug
|
Sep
(10) |
Oct
(3) |
Nov
(8) |
Dec
(3) |
2017 |
Jan
(8) |
Feb
(2) |
Mar
(2) |
Apr
(1) |
May
|
Jun
(7) |
Jul
(6) |
Aug
|
Sep
(6) |
Oct
(18) |
Nov
(31) |
Dec
(1) |
2018 |
Jan
(10) |
Feb
(4) |
Mar
(3) |
Apr
(5) |
May
(10) |
Jun
(3) |
Jul
(8) |
Aug
|
Sep
|
Oct
(6) |
Nov
(18) |
Dec
(15) |
2019 |
Jan
(61) |
Feb
(11) |
Mar
(27) |
Apr
(43) |
May
(12) |
Jun
(13) |
Jul
(18) |
Aug
(19) |
Sep
(16) |
Oct
(7) |
Nov
|
Dec
|
2020 |
Jan
(6) |
Feb
(4) |
Mar
|
Apr
(24) |
May
(1) |
Jun
(6) |
Jul
(22) |
Aug
(8) |
Sep
(40) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
2021 |
Jan
(10) |
Feb
(3) |
Mar
(2) |
Apr
(7) |
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
(13) |
Feb
(11) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(18) |
Sep
(3) |
Oct
|
Nov
(30) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
(19) |
May
(7) |
Jun
|
Jul
|
Aug
(2) |
Sep
(2) |
Oct
(1) |
Nov
(5) |
Dec
(6) |
From: Jorge G. <go...@ie...> - 2004-05-12 20:10:42
|
> On Ter 11 Mai 2004 07:06, Alberto Griggio wrote: (...) >> You just have to use a special tag prefix for the desired property, >> which can be either var: or code:. Quoting the docs: (...) Still working with that -- I'm sorry, but I could only test it today -- I had the following problem: Traceback (most recent call last): File "./rh.py", line 291, in ? app = Aplicacao(0) File "/usr/lib/python2.3/site-packages/wxPython/wx.py", line 1951, in __init__ _wxStart(self.OnInit) File "./rh.py", line 272, in OnInit frame_1 = BHSysRH(None, -1, "") File "./rh.py", line 57, in __init__ self.btnFunc = wxBitmapButton(self.panel_1, btnFunc, (os.path.sep.join([imagens, 'seta.png']))) File "/usr/lib/python2.3/site-packages/wxPython/controls.py", line 180, in __init__ self.this = controlsc.new_wxBitmapButton(*_args,**_kwargs) TypeError: Type error in argument 3 of new_wxBitmapButton. Expected _wxBitmap_p. Where line 57 was generated by wxGlade and is: self.btnFunc = wxBitmapButton(self.panel_1, btnFunc, (os.path.sep.join([imagens, 'seta.png']))) (I filled in the widget -> bitmap value as: "code:os.path.sep.join([imagens, 'seta.png'])" (without quotes) "imagens" is a variable created with: configFile = ConfigParser.ConfigParser() configFile.read('config.ini') imagens = configFile.get('sistema', 'imagens') del configFile and has the string 'imagens' as its value (verified with a 'print' on the code). Any hints on what I might be doing wrong? This is the first time I use such a feature. Be seeing you, -- Godoy. <go...@ie...> |
From: <Ric...@ed...> - 2004-05-12 14:49:10
|
In module edit_widget.py function increment_label() I believe the line: while common.app_tree.has_name(label): should be: while common.app_tree.has_name(_label): Using wxGlade-0.3.3-pre1, wxPython-2.5.1.5, Python-2.3.3 on Win98. regards, Richard |
From: Remco O. <dev...@sm...> - 2004-05-12 12:09:10
|
On Tuesday 11 May 2004 22:27, David Robertson wrote: > Is this a bug, or am I doing something wrong. In > the Properties window, I set the class of a widget > to moduleName.subclassName. When an XRC file > is generated, subclass for the widget only contains > subclassName. When loading the XRC file, the class > can't be found. If I manually add moduleName to the > XRC widget subclass, the widget loads correctly. I had the same problem. I have submitted a patch to the sf project page wich resolves it for me. The module was stripped of when generating xrc. This step is now simply commented out. I don't see any problems with this for xrc-files (Alberto might though). Remco |
From: Marco A. <PPN...@sp...> - 2004-05-12 06:49:54
|
Rehi Had to run yesterday and couldn't give my 2-cents for your final question/remark: > - Finally (for now ;-), always for C++ output, should we generate event > tables (more familiar to wxWidgets' users) or use the dynamic > wxEvtHandler::Connect() calls (probably easier) ? I have to admit that I personally would favour the "dynamic" Connect-Method. I never used it though and wasn't aware of it. What are the disadvantages of the Connect-paradigm? I can't see any... so why not stick with the more powerful (dynamic) approach? Which one is favoured/better supported by wxWidgets? > As you can see, it's not trivial... this doesn't mean it's impossible of > course, and actually I'm positive on it, but we need some more > discussion. So, thanks again for opening it! You are welcome... let's hope others will comment on it as well. Have a marvellous day, Marco |
From: David R. <dwr...@lb...> - 2004-05-11 20:29:21
|
Is this a bug, or am I doing something wrong. In the Properties window, I set the class of a widget to moduleName.subclassName. When an XRC file is generated, subclass for the widget only contains subclassName. When loading the XRC file, the class can't be found. If I manually add moduleName to the XRC widget subclass, the widget loads correctly. This happens with 0.3.2 with Redhat 9 and Windows XP, with both wxPython 2.4.2 and 2.5.1 David Robertson Berkeley Lab |
From: Richard T. <ri...@re...> - 2004-05-11 19:53:56
|
> > It should work now (tested only on GTK2). > > Alberto > It's not crashing on Win98 either now, thanks Alberto. regards, Richard |
From: Alberto G. <al...@qu...> - 2004-05-11 15:52:41
|
> > Yes, I am using wxPython 2.5.1.5 - sorry, I should have mentioned > it. It should work now (tested only on GTK2). Alberto |
From: <Ric...@ed...> - 2004-05-11 15:04:09
|
> > I guess you are using wxPython 2.5.x... If this is the case, this is > probably just another incompatibility we need to fix before releasing > 0.3.3 final :-( I'll try later and let you know... > Yes, I am using wxPython 2.5.1.5 - sorry, I should have mentioned it. |
From: Alberto G. <al...@qu...> - 2004-05-11 14:53:33
|
> The error appears to happen in wxGladeFrame.__init__() at the line: > > main_sizer.Show(custom_sizer, False) > > The error also happens with wxGlade-0.3.2 > > I am using Python 2.3.3 on Win98SE. > > Can anyone shed any light on this problem? I guess you are using wxPython 2.5.x... If this is the case, this is probably just another incompatibility we need to fix before releasing 0.3.3 final :-( I'll try later and let you know... Alberto |
From: <Ric...@ed...> - 2004-05-11 14:23:12
|
I've been trying to add a custom widget to wxGlade-0.3.3-pre1. I set the local widget path to a directory containing a widgets.txt file which references a subdirectory containing my custom widget's files. However, I keep getting the following error: PYTHON caused an invalid page fault in module PYTHON23.DLL at 017f:1e037250. At first I thought that my custom widget might be the cause, but I have now replaced it by a copy of the 'widgets\button' subdirectory from the wxGlade distribution and wxGlade still crashes. The error appears to happen in wxGladeFrame.__init__() at the line: main_sizer.Show(custom_sizer, False) The error also happens with wxGlade-0.3.2 I am using Python 2.3.3 on Win98SE. Can anyone shed any light on this problem? regards Richard Townsend |
From: Jorge G. <go...@ie...> - 2004-05-11 12:20:32
|
On Ter 11 Mai 2004 07:06, Alberto Griggio wrote: >> Hi! >> >> >> Is it possible to use variables instead of string with wxGlade to, >> e.g., insert images on my application? For instance, I want to >> insert some images and those are stored at image_dir, so I'd like to >> use something like image_dir+'image.png' to reference image.png. > > Yes, it is :-) > > You just have to use a special tag prefix for the desired property, > which can be either var: or code:. Quoting the docs: (...) Thanks. But then you can mix those only with some command such as join for Python, correct? There's no way to make "var:image_dir + 'image.png'" and have wxGlade to write the correct syntax for each language? Using join (with 'code:') is no problem to me, but being able to specify only part of the name would be even better. Specially if people doing the layout are different from people writing the code. The answer you gave solve my problems. The rest was just to think about... :-) Thanks again, Alberto. Be seeing you, -- Godoy. <go...@ie...> |
From: Marco A. <PPN...@sp...> - 2004-05-11 10:12:27
|
Hi Unfortunately my C++-knowledge is very rudimentary and my Perl-knowledge has eroded over time (since I use Python). Hence I am no big help for these 2 languages. > - For example, which events do we allow? For those not familiar with > wxWidgets' event system, there are basically two categories of events: > "plain" wx.EventS and wx.CommandEventS. In short, the former are what > other GUI toolkits (qt and GTK for example) call "events", while the > latter are "signals". The difference for us is that "events" are not > propagated to parent windows, and so must be handled by the widget that > generates them. To summarize, this causes problems for C++ code > generation (if you want some details, ask and I'll try to > explain...),so > I'd like to avoid supporting plain "events", but only "signals". This > means that EVT_SIZE should be omitted, for instance. I admit that my wxWidgets-knowledge is very basic. I only used the "EVT_*"-macros (I know for perl and python these are no macros, but let's talk about macros here), so far - so I didn't care about the inner workings of events/signals. I read a bit about wx.Command and wx.Event and I am not sure, whether I got your point. Let me put it that way: There are the macros to go with (EVT_*) - be it for C++, be it for Python (and also for Perl, I suppose). A little "database" that that holds the specifics for each macro (usable with what widgets, description, parameters, parameters sent to event-handler) would help generating the code. That is how deep I would go! If I do have an EVT_SIZE-Macro... well, then it can be supported. Maybe my view in this matter is too simplistic: If you could give me an example that breaks my concept - that would be helpful. > - C++ code generation (funny to see how problems never come from python! > - and perl aswell, at least AFAIK ;-) has another problem, namely that as > far as I can tell event handlers can't be virtual, so they can't be > overriden by subclasses. This means that use case #2 (aka "man, don't > touch the generated code, but subclass instead!" :-) can't be used "out > of the box". Hmm... let me cite from the wxWidget/wxPython 2.5.1 manual - so that we are talking about the same thing: <quote> Event handling overview [...] An event table is placed in an implementation file to tell wxWindows how to map events to member functions. These member functions are not virtual functions, but they are all similar in form: they take a single wxEvent-derived argument, and have a void return type. Here's an example of an event table. BEGIN_EVENT_TABLE(MyFrame, wxFrame) EVT_MENU (wxID_EXIT, MyFrame::OnExit) EVT_MENU (DO_TEST, MyFrame::DoTest) EVT_SIZE ( MyFrame::OnSize) EVT_BUTTON (BUTTON1, MyFrame::OnButton1) END_EVENT_TABLE() The first two entries map menu commands to two different member functions. The EVT_SIZE macro doesn't need a window identifier, since normally you are only interested in the current window's size events. The EVT_BUTTON macro demonstrates that the originating event does not have to come from the window class implementing the event table -- if the event source is a button within a panel within a frame, this will still work, because event tables are searched up through the hierarchy of windows for the command events. In this case, the button's event table will be searched, then the parent panel's, then the frame's. As mentioned before, the member functions that handle events do not have to be virtual. Indeed, the member functions should not be virtual as the event handler ignores that the functions are virtual, i.e. overriding a virtual member function in a derived class will not have any effect. These member functions take an event argument, and the class of event differs according to the type of event and the class of the originating window. For size events, wxSizeEvent is used. For menu commands and most control commands (such as button presses), wxCommandEvent is used. When controls get more complicated, then specific event classes are used, such as wxTreeEvent for events from wxTreeCtrl windows. </quote> > One solution would be to generate code like this: > > class WithEvents: public wxWindow { > private: > void wxglade_private_OnSomeEvent(wxEvent &evt); > public: > virtual void OnSomeEvent(wxEvent &evt); > //... > }; > > void WithEvents::wxglade_private_OnSomeEvent(wxEvent &evt) > { > OnSomeEvent(evt); > } > > void WithEvents::OnSomeEvent(wxEvent &evt) {} > > EVT_SOME(&WithEvents::wxglade_private_OnSomeEvent) > > Then a user could write: > > class MyDerivedWithEvents: public WithEvents { > public: > void OnSomeEvent(wxEvent &evt) { std::cout << "Hello, world!\n"; > } > }; > > But I'm not sure I like it that much... Well this looks nice to me... What does disturb you about this code? There must be some circumventing the 'no virtual functions in EVT-marcros'. There is no other way how to do it... or is there? And don't forget that all widget should be declared public or (maybe better) at least protected, so that they can be used by the derived class. > - About tagging the generated source code, I was thinking of something > like: > > def on_click(self, event): # wxGlade: MyFrame.<event_handler> > pass > > (this has actually been generated by my "event-aware" wxGlade) > > But the real issue is: what to do if someone changes the event handler > name? To be safe, we shouldn't try to remove on_click from the code, as > it could contain all sort of stuff. But this only if the user mixes > his/her > code with the generated one. But if (s)he is "nice" and uses > subclassing, > whenever some handler is renamed, the code becomes dirtier because of > the > remaining (and unused) all handlers... > > My vote goes to not try to touch the handlers once they are written, > and > this is actually what the actual experimental code does... Creating a gui is (normally) a re-iterating process - which means, that code is re-generated a lot of times. My proposal: When first generating the code we have no problem - for once 8o). The generated code tags the event function as shown by your proposal: def on_click(self, event): # wxGlade: MyFrame.<event_handler> pass My proposal would be to enlarge the wxGlade-remark to: def on_click(self, event): # wxGlade: <event_handler> [FrameName|DialogName] [WidgetName] [EVT-Macro] pass or more concrete: def onBtnDoSomething(self, event): # wxGlade: <event_handler> EventHandling btnDoSomething EVT_BUTTON pass When regenerating the code the existing source must be parsed anyhow - so we can create a list of all event-handlers. In Python I would create a dict: key = 'btnDoSomething' + '::EVT_BUTTON' # widgetName + macroName value = 'OnBtnDoSomething' # event handler name evtDict[key] = value Now I can figure out the 'new', 'existing', 'renamed', 'deleted' event-handlers: # From wxGlade information you know nameOfWidget = 'btnHallo' nameOfEventMacro = 'EVT_BUTTON' nameOfEventHandler = 'OnBtnHallo_BUTTON' # Now we figure out, whether it is new, existing, renamed, deleted if evtDict.has_key(nameOfWidget + '::' + nameOfEventMacro): # So, we have already defined an event handler for this widget # Is it unchanged? funcName = evtDict[nameOfWidget + '::' + nameOfEventMacro] if funcName == nameOfEventHandler: # The method exists and is unchanged - copy paste the existing method pass else: # The method was renamed - so copy paste and rename the method # The user has to rename his derived method by himself! pass # Now and this is very important: Remove the handled event handler # Cause all entries that are left after generation of the event handlers # are deleted entries - deleted entries will be copy pasted into the # new code, but (!) the #wxGlade-Remark will be removed del evtDict[nameOfWidget + '::' + nameOfEventMacro] else: # If we reached this point there was no event-handler for this widget. # Create one! pass # Later in the code, when all handlers mentioned in wxGlade are handled, # in evtDict might still some entries be left - these are event handlers # not used anymore. # Copy them into the new code but remove the #wxGlade-tag for (key, value) in evtDict: pass I hope you get the idea... And now I have to run onto the train! What do you think? Greetings, Marco (<-- Birthday kid) |
From: Alberto G. <al...@qu...> - 2004-05-11 08:06:45
|
> Are there plans to support wxGridBagSizer? > > Thanks. Plans maybe. Zero time though :-( Alberto |
From: Alberto G. <al...@qu...> - 2004-05-11 08:06:45
|
> I'm not able to set fonts in the Properties Common tab. Whatever I > do, the font setting is stuck on "['8', 'default', 'normal', > 'normal', 'False', 'MS Shell Dlg']". > > Am I missing something? A bug that should be fixed on CVS now. ;-) Cheers, Alberto |
From: Alberto G. <al...@qu...> - 2004-05-11 08:06:44
|
> Hi! >=20 >=20 > Is it possible to use variables instead of string with wxGlade to, > e.g., insert images on my application? For instance, I want to > insert some images and those are stored at image_dir, so I'd like to > use something like=A0=A0image_dir+'image.png'=A0to=A0reference image.png. Yes, it is :-) You just have to use a special tag prefix for the desired property, which can be either var: or code:. Quoting the docs: """ Specifying the path of bitmaps In wxGlade some widgets need to specify a bitmap path. You can use any graphic format supported by wxWidgets. The bitmap can be specified in several ways: Usually you can type an absolute path in a textbox or browse for a bitmap with a file dialog. This will produce a wxBitmap object with the typed string as bitmap path (e.g. wxBitmap("/usr/share/icons/application.png", wxBITMAP_TYPE_ANY)) You can enter a variable name using the var: tag in the textbox. This will produce a wxBitmap object with the variable name as bitmap path (e.g. var:my_bitmap_path produces wxBitmap(my_bitmap_path, wxBITMAP_TYPE_ANY)). In perl code generation a \x{201C}$\x{201D} sign is added if you omit it. You can enter a code chunk returning a wxBitmap, by using the code: tag. This inserts verbatum the code you enter in brackets and nothing more (e.g.: if wxSomeWidget needs a wxBitmap as an argument, the string code:if (x =3D=3D 0) get_bitmap1() else get_bitmap2(); produces wxSomeWidget((if (x =3D=3D 0) get_bitmap1() else get_bitmap2();), option1, option2)). wxGlade never declares or assigns variable or function names, so after code generation, you have to provide extra code to declare your variables or functions. If you use var: or code: tags the preview window shows an empty bitmap of fixed size. """ Cheers, Alberto |
From: Jorge G. <go...@ie...> - 2004-05-10 15:25:18
|
[ I'm reposting... I haven't received my own message. Sorry if it appears twice.] Hi! Is it possible to use variables instead of string with wxGlade to, e.g., insert images on my application? For instance, I want to insert some images and those are stored at image_dir, so I'd like to use something like image_dir+'image.png' to reference image.png. image_dir is gotten from a configuration file that is parsed with ConfigParser and is different on Linux and Windows and might even be changed by the user if he wants. I could change the path for every image file, but there are lots of them (icons, bitmaps, etc.) on the code and doing that would practically duplicate all the code inserted by wxGlade to specify the images. This is something that I've been looking for for a while... TIA, -- Godoy. <go...@ie...> |
From: Jorge G. <go...@ie...> - 2004-05-09 19:35:14
|
Hi! Is it possible to use variables instead of string with wxGlade? For instance, I want to insert some images and those are stored at image_dir, so I'd like to use something like image_dir+'image.png' to reference image.png. image_dir is gotten from a configuration file that is parsed with ConfigParser and is different on Linux and Windows. I could chance the path for every image file, but there are lots of them (icons, bitmaps, etc.) on the code and doing that would practically duplicate all the code inserted by wxGlade to specify the images. TIA, -- Godoy. <go...@ie...> |
From: Steven P. <n9...@n9...> - 2004-05-08 22:41:52
|
On May 8, 2004, at 6:49 AM, Alberto Griggio wrote: >> Unfortunately it isn't the cure I was hoping it was... It does stop >> the immediate crash I was seeing, but if you use other pop-up menu >> items it will still crash after a while, so there is more digging I >> will have to do to find the cause. The above doesn't hurt anything, >> though, and does postpone the crash in the first few uses of the >> pop-up menus. > > Ok, sorry that I can't help here :-( > However, should we hold v0.3.3 until this is figured out, or go on > with the release? I'd say go ahead with the release, as I this is not a new problem -- it's been there for a while -- and it may take a bit of time to track down. As things are right now, it's more usable than the last released version so that's a step forward anyway. |
From: Milan B. <al...@eu...> - 2004-05-08 12:21:46
|
Alberto Griggio wrote: > Well, it depends on the platform and wxPython version. If you are on > windows, you can use the .exe that should have no problems (or at > least definitely less bugs than v0.2.2) I use it on both Windows and Linux. I like to have non-exe version for Windows too, so that I can checkout the cvs version if some new important feature comes out. >>Also, I still have Python 2.2 on one, and Python 2.3 on other >>computer. Which version of Python is recommended? > > It's been a while since I switched to 2.3, but AFAICT everything > should work with 2.2 as well. Ok. I'll check. >>Third, I have WxWindows (wxWidgets) version 2.4.0. So, once more, >>which version of wxWindows and wxPython are recommended for use with >>wxGlade currently? > > The generated code works for both 2.4 and 2.5. As for the wxPython > version, probably the safest choice is 2.4.2.4 (again, only if you > don't use the .exe version of wxGlade) Ok. Thanx a lot. -- Milan Babuskov http://fbexport.sourceforge.net |
From: Milan B. <al...@eu...> - 2004-05-08 12:20:06
|
Alberto Griggio wrote: > - C++ code generation (funny to see how problems never come from python! - > and perl aswell, at least AFAIK ;-) has another problem, namely that as > far as I can tell event handlers can't be virtual That's correct. > , so they can't be > overriden by subclasses. This means that use case #2 (aka "man, don't > touch the generated code, but subclass instead!" :-) can't be used "out > of the box". One solution would be to generate code like this: > > class WithEvents: public wxWindow { > private: > void wxglade_private_OnSomeEvent(wxEvent &evt); > public: > virtual void OnSomeEvent(wxEvent &evt); > //... > }; Why two methods? I mean, why not just create a subclass for every object that needs events. I know that it may give a clutter of classes, but it's auto-generated so who really cares. And it should be a lot easier to program. Something like this: class WithEvents: public wxWindow { private: void OnSomeEvent(wxEvent &evt); }; BEGIN_EVENT_TABLE(WithEvents, wxWindow) EVT_SOME(WithEvents::OnSomeEvent) END_EVENT_TABLE() void WithEvents::OnSome(wxEvent& event) { } > Then a user could write: > > class MyDerivedWithEvents: public WithEvents { > public: > void OnSomeEvent(wxEvent &evt) { std::cout << "Hello, world!\n"; } > }; And they way I propose, user shouldn't write anything, he gets and empty event handler for his object. > But the real issue is: what to do if someone changes the event handler > name? How about not allowing user to change it. Why would he? > - Finally (for now ;-), always for C++ output, should we generate event > tables (more familiar to wxWidgets' users) or use the dynamic > wxEvtHandler::Connect() calls (probably easier) ? FWIW, I vote for event handlers. Bye, -- Milan Babuskov http://fbexport.sourceforge.net |
From: Alberto G. <al...@qu...> - 2004-05-08 09:56:34
|
Hello, thanks for this first of all. It will definitely help adding events support when this will be done. Now, some comments. I had already started implementing basic event handling, and I actually have some code that works for python, but then I had to stop because of the wx2.5 issue that took me all my "wxGlade-time". So I already tried some solutions, and smashed my head against more than a wall :-) - First, the UI to add/remove handlers. This is the easiest part of course, since it contains very little (if any) logic, but it still seems to be not obvious, if only because I thought (and implemented) it completely differently from this proposal :-) But I don't want to into the details of this yet, there are bigger issues... - For example, which events do we allow? For those not familiar with wxWidgets' event system, there are basically two categories of events: "plain" wx.EventS and wx.CommandEventS. In short, the former are what other GUI toolkits (qt and GTK for example) call "events", while the latter are "signals". The difference for us is that "events" are not propagated to parent windows, and so must be handled by the widget that generates them. To summarize, this causes problems for C++ code generation (if you want some details, ask and I'll try to explain...), so I'd like to avoid supporting plain "events", but only "signals". This means that EVT_SIZE should be omitted, for instance. - C++ code generation (funny to see how problems never come from python! - and perl aswell, at least AFAIK ;-) has another problem, namely that as far as I can tell event handlers can't be virtual, so they can't be overriden by subclasses. This means that use case #2 (aka "man, don't touch the generated code, but subclass instead!" :-) can't be used "out of the box". One solution would be to generate code like this: class WithEvents: public wxWindow { private: void wxglade_private_OnSomeEvent(wxEvent &evt); public: virtual void OnSomeEvent(wxEvent &evt); //... }; void WithEvents::wxglade_private_OnSomeEvent(wxEvent &evt) { OnSomeEvent(evt); } void WithEvents::OnSomeEvent(wxEvent &evt) {} EVT_SOME(&WithEvents::wxglade_private_OnSomeEvent) Then a user could write: class MyDerivedWithEvents: public WithEvents { public: void OnSomeEvent(wxEvent &evt) { std::cout << "Hello, world!\n"; } }; But I'm not sure I like it that much... - About tagging the generated source code, I was thinking of something like: def on_click(self, event): # wxGlade: MyFrame.<event_handler> pass (this has actually been generated by my "event-aware" wxGlade) But the real issue is: what to do if someone changes the event handler name? To be safe, we shouldn't try to remove on_click from the code, as it could contain all sort of stuff. But this only if the user mixes his/her code with the generated one. But if (s)he is "nice" and uses subclassing, whenever some handler is renamed, the code becomes dirtier because of the remaining (and unused) all handlers... My vote goes to not try to touch the handlers once they are written, and this is actually what the actual experimental code does... - Finally (for now ;-), always for C++ output, should we generate event tables (more familiar to wxWidgets' users) or use the dynamic wxEvtHandler::Connect() calls (probably easier) ? As you can see, it's not trivial... this doesn't mean it's impossible of course, and actually I'm positive on it, but we need some more discussion. So, thanks again for opening it! Comments very welcome, Alberto |
From: Alberto G. <al...@qu...> - 2004-05-08 09:56:34
|
> hi, > > I've a couple of fixes for wxGlade problems with wxPython 2.5.2.1 / > new namespace ... Thanks! Alberto |
From: Alberto G. <al...@qu...> - 2004-05-08 09:56:34
|
> On May 5, 2004, at 5:37 PM, Alberto Griggio wrote: > >> # first, destroy the popup menu... > >> if Platform != "__WXMAC__": > >> if self._rmenu: self._rmenu.Destroy() > > > > Done. > > Unfortunately it isn't the cure I was hoping it was... It does > stop > the immediate crash I was seeing, but if you use other pop-up menu > items it will still crash after a while, so there is more digging I > will have to do to find the cause. The above doesn't hurt anything, > though, and does postpone the crash in the first few uses of the > pop-up menus. Ok, sorry that I can't help here :-( However, should we hold v0.3.3 until this is figured out, or go on with the release? Alberto |
From: Alberto G. <al...@qu...> - 2004-05-08 09:56:34
|
> In short, > Sorry to waiste your time, I'l be happy to test more when I have a > solid environment. Hmmm, first this is not a waste of time, I'd really like to understand what's going on. I have a wx 2.5 here (GTK2), and it seems to work, but I haven't tested all the dark corners yet. On windows it seems to work as well, so why do the default packages of major distros fail? My guess is that's a unicode-related thing: I'll try to recompile my version with unicode enable, and then let you know... Alberto |
From: Alberto G. <al...@qu...> - 2004-05-08 09:56:34
|
> Hi all, > > I haven't updated my wxGlade instalation since version 0.2.2. It did > the job very good, and still does :) > > Now, I'd like to try new versions. Which is recommended as stable? > And which is "not so stable" but works ok? Well, it depends on the platform and wxPython version. If you are on windows, you can use the .exe that should have no problems (or at least definitely less bugs than v0.2.2) > Also, I still have Python 2.2 on one, and Python 2.3 on other > computer. Which version of Python is recommended? It's been a while since I switched to 2.3, but AFAICT everything should work with 2.2 as well. > Third, I have WxWindows (wxWidgets) version 2.4.0. So, once more, > which version of wxWindows and wxPython are recommended for use with > wxGlade currently? The generated code works for both 2.4 and 2.5. As for the wxPython version, probably the safest choice is 2.4.2.4 (again, only if you don't use the .exe version of wxGlade) Cheers, Alberto |