Thread: Re: wxWindows2.5 and pgadmin
Ron wrote: >Howdy, > >A little later tonight I should be uploading wx2.5.1.1 packages >to experimental. Andreas, what is the current state of pgadmin >regarding wx.. do you guys still need extra patches, if so what >do we need to do to get them merged (to the satisfaction of >everyone :) with mainstream wx -- and hence finally get pgadmin >off the Debian wnpp list and into the archive proper. > > Ron > > > > Hi Ron, we still need patches. There are 3 patches pending, as old as July :-( There was quite some work done in wx, so I believe there might be some more patches necessary, or workarounds/modifications in the pgadmin3 code. Unfortunately, those 3 patches are not circumventable unless a vast amount of code (e.g. all controls) is duplicated in pgadmin3 code. Now that 2.5.1 has settled, I'll be upgrading our snapshot to that version in the next few weeks, and make pgadmin3 working with that (I promised that multiple times earlier, I know...). I'm still completely unfamiliar with the new wx' bakefile stuff, hopefully we can integrate it smoothly into pgadmin3 as an embedded package. As a vision (and to put some pressure on me), I'd like to have pgadmin3 Debian-ready and showing on Linuxtag. Regards, Andreas
On Tue, Mar 16, 2004 at 01:42:46PM +0100, Andreas Pflug wrote: > we still need patches. There are 3 patches pending, as old as July :-( Yes, recent events in wx space have done little to help that, though I hope we are well past the worst of that now. At least one of them I know was contentious, and though I didn't look into it very deeply myself at the time, Vadim's argument about not making localised fixes in many places did seem reasonably sound to me at the time. > There was quite some work done in wx, so I believe there might be some > more patches necessary, or workarounds/modifications in the pgadmin3 > code. Unfortunately, those 3 patches are not circumventable unless a > vast amount of code (e.g. all controls) is duplicated in pgadmin3 code. Can we start with the simplest of them first and try to get consensus on wx-dev to have them applied. I'll be happy to actually get them committed for you if you provide updated patches for current HEAD, but I'm afraid you are going to have to 'run the gauntlet' in that forum again first for all but the most obviously correct changes. > I'm still completely unfamiliar with the new wx' bakefile stuff, > hopefully we can integrate it smoothly into pgadmin3 as an embedded > package. I'm not sure what you mean by this. Aside from being slower than the old build system, you should be able to pretty safely ignore most of what bakefile has changed. For autoconf builds you might need to tweak a couple of the options you pass to wx-config, but that should be about it. (and that is more related to the new multiple lib format than bakefile per se) > As a vision (and to put some pressure on me), I'd like to have pgadmin3 > Debian-ready and showing on Linuxtag. Cool. I can't promise an easy passage through wx-dev, but it would be nice to close this fork so I'll do what I can to help. cheers, Ron
Ron wrote: > >At least one of them I know was contentious, and though I didn't >look into it very deeply myself at the time, Vadim's argument about >not making localised fixes in many places did seem reasonably sound >to me at the time. > > Ron, have a look at it. It adds a single simple line setFont(parent->getFont()) to controls which missed that line. Vadim wishes some miraculous inheritance implementation, which *at least* needs such a line in every control. The setting of the font can *not* be done in the constructor, nor in a base ::create method, since it must happen after the win32 HWND or gtk widget is created. Ever other solution would need more code, I bet! >Can we start with the simplest of them first and try to get consensus >on wx-dev to have them applied. I'll be happy to actually get them >committed for you if you provide updated patches for current HEAD, >but I'm afraid you are going to have to 'run the gauntlet' in that >forum again first for all but the most obviously correct changes. > > > That oldest patch fixes a Unicode/non-Unicode clipboard paste problem (leading to an assert failure in debug mode). The fix isn't aesthetically satisfying, but hey! it's not my fault that win32 and gtk use several clipboard formats for the same thing, i.e. simple text, this 'is' ugly! But there is no obvious elegant way to do it differently without major and unnecessary impact in the apps. You'd certainly expect to be able to cut and paste text from any text app into an stc edit control, wouldn't you? The mails I wrote about this are legion, and I doubt writing more would help more. The third fix might be obsolet in the meantime, has to be checked. wxCalendarCtrl is said to be reworked in a major fashion, that might be for better or for worse. >>I'm still completely unfamiliar with the new wx' bakefile stuff, >>hopefully we can integrate it smoothly into pgadmin3 as an embedded >>package. >> >> > >I'm not sure what you mean by this. Aside from being slower than the >old build system, you should be able to pretty safely ignore most of >what bakefile has changed. For autoconf builds you might need to >tweak a couple of the options you pass to wx-config, but that should >be about it. (and that is more related to the new multiple lib format >than bakefile per se) > > Just downloaded cvs head (jup!) and it installed smoothly (for linux). Don't know what will happen on win32, and how we could integrate wx as a subfolder into our source tree, using an integrated configure/make for all. > > >>As a vision (and to put some pressure on me), I'd like to have pgadmin3 >>Debian-ready and showing on Linuxtag. >> >> > >Cool. I can't promise an easy passage through wx-dev, but it would be >nice to close this fork so I'll do what I can to help. > > Of course, I'm not particularly fond of our own fork. But obviously, the wx core developers are not too interested, and things they don't interest are delayed. See the rant on wx-dev about additional committers... Regards, Andreas