Disable tooltips globally doesn't work with wxGTK

[Joachim Bürmann]

Hello,

I'm trying to disable tooltips globally in my program with
wxToolTip::Enable(false) but the tooltips remains to show up when
hovering with the mouse over the relating controls.

I can reproduce this in the samples/text example. Also here I cannot
switch off the tooltips via the menu entry.

I'm using wxGtk 2.8.11 (and I cannot upgrade to 3.0) with Ubuntu 10.04
LTS. I also didn't find any hints in the changelog. Perhaps a Gtk issue?

Does anyone have an idea about this behaviour and how I can fix it.

Best regards

Joachim

[Joachim Bürmann]

P.S. The wxMSW 2.8.11 port works as expected.

Post by Joachim Bürmann
Hello,
I'm trying to disable tooltips globally in my program with
wxToolTip::Enable(false) but the tooltips remains to show up when
hovering with the mouse over the relating controls.
I can reproduce this in the samples/text example. Also here I cannot
switch off the tooltips via the menu entry.
I'm using wxGtk 2.8.11 (and I cannot upgrade to 3.0) with Ubuntu 10.04
LTS. I also didn't find any hints in the changelog. Perhaps a Gtk issue?
Does anyone have an idea about this behaviour and how I can fix it.
Best regards
Joachim

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to wx-users+***@googlegroups.com
or visit http://groups.google.com/group/wx-users

[Vadim Zeitlin]

On Thu, 31 Jul 2014 09:31:03 +0200 Joachim BÃŒrmann wrote:

JB> I'm trying to disable tooltips globally in my program with
JB> wxToolTip::Enable(false) but the tooltips remains to show up when
JB> hovering with the mouse over the relating controls.
JB>
JB> I can reproduce this in the samples/text example. Also here I cannot
JB> switch off the tooltips via the menu entry.
JB>
JB> I'm using wxGtk 2.8.11

All I can say is that disabling tooltips does work for me with wxGTK 3.0.

JB> (and I cannot upgrade to 3.0)

Out of curiosity, why?

JB> Does anyone have an idea about this behaviour and how I can fix it.

You might be able to find a fix to backport into 2.8 by examining the
differences between it and 3.0.

Regards,
VZ

[Joachim Bürmann]

Hello Vadim,

thank you very much for pointing this out.
Unfortunatelly we have to stay with wxWidgets 2.8.11 for an indefinite
time. It's not that I'm not willing to switch to wxWidgets 3.0 (I am).
At the moment we are very happy with 2.8.11 and we just cannot effort
the time to port our applications to 3.0. We will do it sooner or later
and I'm sure after the porting we will never go back again ;-) but we
have to wait for the appropriate time.

Disabling tooltips globally is not so important for me, I just wondered
why it doesn't work with wxGTK 2.8.11.

So - again - thanks for your hint and best regards

Joachim

Post by Vadim Zeitlin
JB> I'm trying to disable tooltips globally in my program with
JB> wxToolTip::Enable(false) but the tooltips remains to show up when
JB> hovering with the mouse over the relating controls.
JB>
JB> I can reproduce this in the samples/text example. Also here I cannot
JB> switch off the tooltips via the menu entry.
JB>
JB> I'm using wxGtk 2.8.11
All I can say is that disabling tooltips does work for me with wxGTK 3.0.
JB> (and I cannot upgrade to 3.0)
Out of curiosity, why?
JB> Does anyone have an idea about this behaviour and how I can fix it.
You might be able to find a fix to backport into 2.8 by examining the
differences between it and 3.0.
Regards,
VZ

[Vadim Zeitlin]

On Fri, 01 Aug 2014 21:36:20 +0200 Joachim BÃŒrmann wrote:

JB> Unfortunatelly we have to stay with wxWidgets 2.8.11 for an indefinite
JB> time. It's not that I'm not willing to switch to wxWidgets 3.0 (I am).
JB> At the moment we are very happy with 2.8.11 and we just cannot effort
JB> the time to port our applications to 3.0. We will do it sooner or later
JB> and I'm sure after the porting we will never go back again ;-) but we
JB> have to wait for the appropriate time.

Well, the idea is that porting to wx 3.0 shouldn't take much time. Of
course, it depends on the project and on its size but I do believe that
time wasted on 2.8 bugs (which, realistically, will never get fixed)
exceeds the time saved on not doing the migration pretty quickly in the
life of an active project.

Regards,
VZ

[Lauri Nurmi]

Post by Vadim Zeitlin
JB> Unfortunatelly we have to stay with wxWidgets 2.8.11 for an indefinite
JB> time. It's not that I'm not willing to switch to wxWidgets 3.0 (I am).
JB> At the moment we are very happy with 2.8.11 and we just cannot effort
JB> the time to port our applications to 3.0.
Well, the idea is that porting to wx 3.0 shouldn't take much time. Of
course, it depends on the project and on its size

If you've always used the ANSI build of wx 2.8, and used a mix of
wxString/std::string/char*, it can be a huge task to fix such a project
to properly convert between wxStrings and the other types. Making it
compile with 3.0 is one thing, ensuring that behavior hasn't changed is
another, perhaps even more complicated a thing.

LN

[Vadim Zeitlin]

On Sat, 02 Aug 2014 00:45:51 +0300 Lauri Nurmi wrote:

LN> 1.8.2014 23:54, Vadim Zeitlin kirjoitti:
LN> > On Fri, 01 Aug 2014 21:36:20 +0200 Joachim BÃŒrmann wrote:
LN> >
LN> > JB> Unfortunatelly we have to stay with wxWidgets 2.8.11 for an indefinite
LN> > JB> time. It's not that I'm not willing to switch to wxWidgets 3.0 (I am)..
LN> > JB> At the moment we are very happy with 2.8.11 and we just cannot effort
LN> > JB> the time to port our applications to 3.0.
LN> >
LN> > Well, the idea is that porting to wx 3.0 shouldn't take much time. Of
LN> > course, it depends on the project and on its size
LN>
LN> If you've always used the ANSI build of wx 2.8, and used a mix of
LN> wxString/std::string/char*, it can be a huge task to fix such a project
LN> to properly convert between wxStrings and the other types. Making it
LN> compile with 3.0 is one thing, ensuring that behavior hasn't changed is
LN> another, perhaps even more complicated a thing.

This depends on what encoding the strings are in. It's actually simpler to
upgrade from ANSI build of wx 2.8 or earlier than from Unicode build
because we always preferred to break compatibility with the latter rather
than the former when it was impossible to keep it with both (if you're
curious, that's because we thought that people already using Unicode would
be more able to fix their code than those who stayed with ANSI). So if your
narrow strings are in the default locale encoding, things really should
just work -- this was the overarching goal of all wx 3.0 changes and I
think we achieved it pretty well.

Of course, if you don't know what is the encoding of your strings, which
is a situation which seems to unfortunately arise much more often than I
would have thought, then things are more difficult and the conversions can
indeed fail. Still, the most common case of conversion failure is when
converting from (Unicode) wxString to narrow strings: this will invariably
fail when not using UTF-8 locale (i.e. always under Windows). But then the
original 2.8 ANSI build didn't deal with Unicode at all, so while it's a
pretty serious bug, it's not a regression according to the strict
definition of the word...

Regards,
VZ

[Lauri Nurmi]

Post by Vadim Zeitlin
LN> If you've always used the ANSI build of wx 2.8, and used a mix of
LN> wxString/std::string/char*, it can be a huge task to fix such a project
LN> to properly convert between wxStrings and the other types. Making it
LN> compile with 3.0 is one thing, ensuring that behavior hasn't changed is
LN> another, perhaps even more complicated a thing.
This depends on what encoding the strings are in.

Besides encoding, one big problem I've personally encountered is using
wxString together with e.g. sprintf:

wxString s;
sprintf(buf, "hello, %s", s.c_str());

This works fine with 2.8 ANSI build, but does not with 3.0. It is not
hard to solve per se, but if such a pattern occurs a thousand times in a
project, it's quite tedious to change them all (and maintain
compilability with 2.8). Probably it was "wrong" to write such code in
the first place, I know; just sharing my experience on why real-world
projects may not migrate to 3.0 as easily as one could hope.

Post by Vadim Zeitlin
Still, the most common case of conversion failure is when
converting from (Unicode) wxString to narrow strings: this will invariably
fail when not using UTF-8 locale (i.e. always under Windows).

Indeed, IIRC, .ToSTdString() returns an empty string if the wxString
contains anything that can't be expressed as ASCII. I'm hoping it can be
globally forced to return UTF-8-std::strings instead by assigning
wxConvCurrent = wxConvUTF8. (I didn't test yet whether this works; if
not, then it's yet another obstacle on the way to 3.0.)

Post by Vadim Zeitlin
But then the original 2.8 ANSI build didn't deal with Unicode at all,

It didn't deal with Unicode, but in practise ANSI builds of wxGTK and
wxMac worked mostly okay with UTF-8 locales as long as wx wasn't asked
to convert anything between charsets.


LN

[Vadim Zeitlin]

On Sat, 02 Aug 2014 19:41:46 +0300 Lauri Nurmi wrote:

LN> Besides encoding, one big problem I've personally encountered is using
LN> wxString together with e.g. sprintf:
LN>
LN> wxString s;
LN> sprintf(buf, "hello, %s", s.c_str());

Yes, this is one of the very few unavoidable breakages -- we just can't
make this work with vararg functions (and contrary to another reply in this
thread, C++11 changes absolutely nothing for sprintf() and friends which
don't magically become variadic templates in it).

In practice the best way to fix this is to:

1. Compile your program with g++ (or clang) which flag all such uses of
c_str() as errors.

2. Replace sprintf() with wxSprintf() (and similarly for all the other
functions).

It's a pretty mechanical transformation which does the right thing.
Unfortunately, it does require a standard conforming compiler that doesn't
allow passing non-PODs to vararg functions -- i.e. not MSVC.

LN> This works fine with 2.8 ANSI build, but does not with 3.0. It is not
LN> hard to solve per se, but if such a pattern occurs a thousand times in a
LN> project, it's quite tedious to change them all (and maintain
LN> compilability with 2.8). Probably it was "wrong" to write such code in
LN> the first place

No, there is absolutely nothing wrong with it and if we could make it work
without changes, we would have done it. Unfortunately I'm pretty sure there
is no way to do it.

LN> > Still, the most common case of conversion failure is when
LN> > converting from (Unicode) wxString to narrow strings: this will invariably
LN> > fail when not using UTF-8 locale (i.e. always under Windows).
LN>
LN> Indeed, IIRC, .ToSTdString() returns an empty string if the wxString
LN> contains anything that can't be expressed as ASCII. I'm hoping it can be
LN> globally forced to return UTF-8-std::strings instead by assigning
LN> wxConvCurrent = wxConvUTF8. (I didn't test yet whether this works; if
LN> not, then it's yet another obstacle on the way to 3.0.)

No, mb_str() uses wxConvLibc, not wxConvCurrent by default. To use UTF-8
you need to explicitly use wxConvUTF8 or, better, utf8_str().

There is however a problem with ToStdString() not taking wxMBConv
parameter at all. I'm afraid this is just an oversight and we should indeed
add such parameter to make it possible to write ToStdString(wxConvUTF8).

LN> > But then the original 2.8 ANSI build didn't deal with Unicode at all,
LN>
LN> It didn't deal with Unicode, but in practise ANSI builds of wxGTK and
LN> wxMac worked mostly okay with UTF-8 locales

I.e. never under Windows...

Regards,
VZ

[petah]

On Sat, 2 Aug 2014 20:16:24 +0200

Post by Vadim Zeitlin
LN> Besides encoding, one big problem I've personally encountered is using
LN>
LN> wxString s;
LN> sprintf(buf, "hello, %s", s.c_str());
Yes, this is one of the very few unavoidable breakages -- we just can't
make this work with vararg functions (and contrary to another reply in this
thread, C++11 changes absolutely nothing for sprintf() and friends which
don't magically become variadic templates in it).

Stroustrup replaces sprintf() entirely, something like:

template<typename T, typename ... Args>
std::string xsprintf(const char *s, T val, Args ... args)
{
std::ostringstream oss;
(...)
switch (fmt_c)
{
(...)
case 's':
{
if (is_same<T, string>()) oss << val;
else if (is_same<T, wxString>()) oss << val.ToStdString();
else if (is_convertible<T, const char*>()) oss << val;
else throw runtime_error("bad xsprintf() string format");
break;
(...)
}
(...)
return oss.str() + xsprintf(s, args ...); // recurse
}

In practice more juggling is required for specializations but compared to one huge macro it's a lot easier to guide compilation, add static & runtime checks and step through the code.

Obviously it can't magically figure out a raw byte buffer's encoding.

-- p

[Vadim Zeitlin]

On Sat, 2 Aug 2014 22:21:54 +0200 petah wrote:

p> On Sat, 2 Aug 2014 20:16:24 +0200
p> Vadim Zeitlin <***@wxwidgets.org> wrote:
p>
p> > On Sat, 02 Aug 2014 19:41:46 +0300 Lauri Nurmi wrote:
p> >
p> > LN> Besides encoding, one big problem I've personally encountered is using
p> > LN> wxString together with e.g. sprintf:
p> > LN>
p> > LN> wxString s;
p> > LN> sprintf(buf, "hello, %s", s.c_str());
p> >
p> > Yes, this is one of the very few unavoidable breakages -- we just can't
p> > make this work with vararg functions (and contrary to another reply in this
p> > thread, C++11 changes absolutely nothing for sprintf() and friends which
p> > don't magically become variadic templates in it).
p>
p> Stroustrup replaces sprintf() entirely

Yes, but this is not the point. We already have perfectly safe wxSprintf()
(and yes, it'd be great if we could use variadic templates for its
implementation instead of the macro trickery as we do now, but this is
completely immaterial for the users of the library). You still need to use
it instead of sprintf() and friends, i.e. you still need to change your
code when upgrading to 3.0 and the main problem is that people don't
realize that the simplest change is to just do this and instead write ugly
casts like (const char*)s.c_str().

Regards,
VZ

[Steve Barnes]

Post by Vadim Zeitlin
p> On Sat, 2 Aug 2014 20:16:24 +0200
p>
p> >
p> > LN> Besides encoding, one big problem I've personally encountered is using
p> > LN>
p> > LN> wxString s;
p> > LN> sprintf(buf, "hello, %s", s.c_str());
p> >
p> > Yes, this is one of the very few unavoidable breakages -- we just can't
p> > make this work with vararg functions (and contrary to another reply in this
p> > thread, C++11 changes absolutely nothing for sprintf() and friends which
p> > don't magically become variadic templates in it).
p>
p> Stroustrup replaces sprintf() entirely
Yes, but this is not the point. We already have perfectly safe wxSprintf()
(and yes, it'd be great if we could use variadic templates for its
implementation instead of the macro trickery as we do now, but this is
completely immaterial for the users of the library). You still need to use
it instead of sprintf() and friends, i.e. you still need to change your
code when upgrading to 3.0 and the main problem is that people don't
realize that the simplest change is to just do this and instead write ugly
casts like (const char*)s.c_str().
Regards,
VZ

The other thing to point out is that, thanks to the wx developers
efforts to maintain backwards compatibility, AFAIK any code that starts
out working on 2.8 and has the changes made to make it 3.0 compatible
will still compile and work on 2.8 just with fewer potential bugs, (I
haven't tried this with C++ but have done a lot with wxPython), as
additional checks are made in a lot of places in 3.0 that prevent poorly
defined behaviour from being used. As a result you could start to make
your code 3.0 ready, (by doing test builds & tests), while maintaining
your current 2.8 deployment. Just to reinforce the point *every* change
I have made to my code base to resolve 3.0 issues has worked seamlessly
on 2.8 so the things that 3.0 was complaining about I probably should
never have been doing in 2.8 in the first place. In my experience the
only time that you will break 2.8 compatibility is when you start to use
new features in 3.0.

The real trick as Vadim points out above is to *use* the abstractions
that wx provides such as wxString::Printf rather than doing ugly hacks.

Gadget/Steve

[Domingo Becker]

Post by Vadim Zeitlin
p> On Sat, 2 Aug 2014 20:16:24 +0200
p>
p> >
p> > LN> Besides encoding, one big problem I've personally encountered is using
p> > LN>
p> > LN> wxString s;
p> > LN> sprintf(buf, "hello, %s", s.c_str());
p> >
p> > Yes, this is one of the very few unavoidable breakages -- we just can't
p> > make this work with vararg functions (and contrary to another reply in this
p> > thread, C++11 changes absolutely nothing for sprintf() and friends which
p> > don't magically become variadic templates in it).
p>
p> Stroustrup replaces sprintf() entirely
Yes, but this is not the point. We already have perfectly safe wxSprintf()
(and yes, it'd be great if we could use variadic templates for its
implementation instead of the macro trickery as we do now, but this is
completely immaterial for the users of the library). You still need to use
it instead of sprintf() and friends, i.e. you still need to change your
code when upgrading to 3.0 and the main problem is that people don't
realize that the simplest change is to just do this and instead write ugly
casts like (const char*)s.c_str().

In my case, I had no problems with "(const char *) cadwx.mb_str()"
with sprintf and printf, when switching from 2.6 to 2.8 and then to
3.0.

I realised that the problem was me, I was coding incorrectly, in a non
portable way.

Post by Vadim Zeitlin
The other thing to point out is that, thanks to the wx developers efforts to
maintain backwards compatibility, AFAIK any code that starts out working on
2.8 and has the changes made to make it 3.0 compatible will still compile
and work on 2.8 just with fewer potential bugs, (I haven't tried this with
C++ but have done a lot with wxPython), as additional checks are made in a
lot of places in 3.0 that prevent poorly defined behaviour from being used.
As a result you could start to make your code 3.0 ready, (by doing test
builds & tests), while maintaining your current 2.8 deployment. Just to
reinforce the point every change I have made to my code base to resolve 3.0
issues has worked seamlessly on 2.8 so the things that 3.0 was complaining
about I probably should never have been doing in 2.8 in the first place. In
my experience the only time that you will break 2.8 compatibility is when
you start to use new features in 3.0.

And yes, the new features in 3.0 make it worth moving to that version.

Now I ask to myself how I made it with 2.8 ! And I did it.

Post by Vadim Zeitlin
The real trick as Vadim points out above is to use the abstractions that wx
provides such as wxString::Printf rather than doing ugly hacks.

I never tried that, and it's my bad.

cheers

Domingo Becker