Re: wxWindows2.5 and pgadmin - Mailing list pgadmin-hackers

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