After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 110788 - Atk/Gtk StateType confusion on widget page
Atk/Gtk StateType confusion on widget page
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: reference documentation
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2003-04-14 21:19 UTC by Ole Laursen
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ole Laursen 2003-04-14 21:19:46 UTC
If you go to the page for Gtk::Widget

  http://www.gtkmm.org/gtkmm2/docs/reference/html/classGtk_1_1Widget.html

and click any of the StateType links (just search for the nearest), you end
up with the page for Atk::StateType instead of Gtk::StateType. This is
really confusing - I spent quite some time investigating it when I got a
compiler error.

If it cannot be fixed within Doxygen, perhaps it would suffer to qualify
the StateType with Gtk:: in the source?
Comment 1 Murray Cumming 2003-04-15 12:29:24 UTC
Yes, that's annoying. We are lucky that it doesn't happen more often.

I guess we need to ask the doxygen people first. The code online has
not been newly built and updated for a while. Do you  know if this
still happens offline, with the most recent Doxygen version?
Comment 2 Murray Cumming 2003-04-21 11:45:04 UTC
I'm having difficult building doxygen 1.3 to test this.

If this doxygen bug does still exist then I don't think it will be a
problem to explicitly mention the namespace of types that exist in
more than one namespace.
Comment 3 Ole Laursen 2003-04-21 15:40:47 UTC
Debian has Doxygen 1.3-rc3 where the problem still appears. Question
is whether we can construct a simple test case for a bug report to the
Doxygen maintainer. Do you understand why the bug appears? I don't quite.
Comment 4 Murray Cumming 2003-04-22 06:36:16 UTC
I think a test case would just have the same type (an enum?) in 2 
namespaces, and 2 classes that used their respective types. I think 
doxygen just isn't as clever as C++ about identifying types.

Let's tell them and fix it for ourselves in gtkmm in the meantime.
Comment 5 Murray Cumming 2003-05-03 06:40:51 UTC
Hmm, even with the prefix it doesn't work properly:
http://www.gtkmm.org/gtkmm2/docs/reference/html/classGtk_1_1Widget.html
Comment 6 Murray Cumming 2003-05-28 07:37:03 UTC
Dimitri (maintainer of doxygen emeailed me with:
"
I would like to know if this bug persists in the latest CVS release
(or the forthcoming 1.3.1 release). If it does persists I would like to
have some instructions to reproduce the problem given the gtkmm sources.
"
Comment 7 Murray Cumming 2003-06-16 08:16:02 UTC
A new doxygen is now out (1.3.2). Could someone test it. I don't think
it builds on RedHat 9.
Comment 8 Ole Laursen 2003-06-16 21:01:40 UTC
I've tried with 1.3.1 just now. Doesn't work. Even though the text for
the link says Gtk::StateType, it still points to atkmmEnums.
Comment 9 Murray Cumming 2003-06-17 07:21:08 UTC
Thanks, but "A new doxygen is now out (1.3.2)".
Comment 10 Ole Laursen 2003-06-24 09:04:41 UTC
Sorry for the long processing time (exams) - it doesn't work with
1.3.2 either. The behaviour is exactly the same.
Comment 11 Murray Cumming 2003-06-24 13:43:09 UTC
OK, I will add a dependent doxygen bug when the doxygen bugzilla 
product is working.
Comment 12 Murray Cumming 2003-06-26 06:55:42 UTC
Dimitri said:
In the new CVS release, this bug should have been solved (but better 
check
before closing the bug ;-)

Dimitri, please reply in the bug instead of replying to the bug 
notification emails. There is some email interface to bugzilla but I 
don't know how it works.
Comment 13 Murray Cumming 2003-08-20 15:54:26 UTC
This seems to be fixed with doxygen 1.3.3. I have uploaded the
improved reference documentation. Thanks everybody.