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 743918 - gtkmm's devhelp index doesn't include functions for Window and Widget.
gtkmm's devhelp index doesn't include functions for Window and Widget.
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: reference documentation
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on: 743920
Blocks:
 
 
Reported: 2015-02-03 10:23 UTC by Murray Cumming
Modified: 2015-02-11 15:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Murray Cumming 2015-02-03 10:23:47 UTC
We generate an index file for devhelp (from a doxygen .tag file, run through an .xsl file), but it isn't working for all classes. For instance, you'll see nothing in the list of symbols if you type "Gtk::Widget::" or "Gtk::Window::", though you will if you type "Gtk::AccelMap::", for instance.

This seems to be a doxygen tagfile-generation problem. At first I thought it was a problem with files that contain more than one class. For instance, TreeModelColumnBase is the second class mentioned in treemodelcolumn.h:
https://git.gnome.org/browse/gtkmm/tree/gtk/gtkmm/treemodelcolumn.h

If I add this method to the TreeModelColumnBase class:
  void murraycdocstest();
and then run the documentation generation again, I see the new function as listed against the TreeModelColumn class in the gtkmm-3.0.tag file:

  <compound kind="class">
    <name>Gtk::TreeModelColumn</name>
    <filename>classGtk_1_1TreeModelColumn.html</filename>
    <templarg>T</templarg>
    <base>Gtk::TreeModelColumnBase</base>
    <member kind="typedef">
      <type>T</type>
      <name>ElementType</name>
      <anchorfile>classGtk_1_1TreeModelColumn.html</anchorfile>
      <anchor>a548b32f98d1fb957559ebc4c709b8b3f</anchor>
      <arglist></arglist>
    </member>
    ...
    <member kind="function">
      <type>void</type>
      <name>murraycdocstest</name>
      <anchorfile>classGtk_1_1TreeModelColumnBase.html</anchorfile>
      <anchor>a85b4148ae33919a63391cec10f98c565</anchor>
      <arglist>()</arglist>
    </member>

Likewise, the existing 
Gtk::TreeModelColumnBase::TreeModelColumnBase (constuctor) method is available via the obviously-wrong Gtk::TreeModelColumn::TreeModelColumnBase index entry.

However, even after I split up gtk/src/window.hg to put WindowGroup in its own gtk/src/windowgroup.hg, I still see Gtk::Window::set_wmclass() bizarrely listed under AboutDialog along with loads of other functions from Gtk::Window and Gtk::Dialog:

  <compound kind="class">
    <name>Gtk::AboutDialog</name>
    <filename>classGtk_1_1AboutDialog.html</filename>
    <base>Gtk::Dialog</base>
    <member kind="function" virtualness="virtual">
      <type>virtual</type>
      <name>~AboutDialog</name>
      <anchorfile>classGtk_1_1AboutDialog.html</anchorfile>
      <anchor>a47057f8bd15b11a02f75ad57dde19dbe</anchor>
      <arglist>()</arglist>
    </member>
    ...
    <member kind="function">
      <type>void</type>
      <name>set_wmclass</name>
      <anchorfile>classGtk_1_1Window.html</anchorfile>
      <anchor>ac6a7119c34bcfc31fdc27a8061a6f8f1</anchor>
      <arglist>(const Glib::ustring &amp;wmclass_name, const Glib::ustring &amp;wmclass_class)</arglist>
    </member>
Comment 1 Murray Cumming 2015-02-03 10:25:31 UTC
I pushed the Window/WindowGroup file split anyway:
https://git.gnome.org/browse/gtkmm/commit/?id=85d375c6f6244cf3627fb523bc2db78f1e5ef973

That makes it easier to show that the 2 classes in 1 file was not the trigger for this doxygen problem.
Comment 2 Murray Cumming 2015-02-03 10:48:13 UTC
doxygen outputs many of these warnings, which might be relevant:

Generating Sqlite3 output for class Gtk::Window
Generating Sqlite3 output for class Gtk::Window
sqlite3_step failed: NOT NULL constraint failed: derivedcompoundref.base
sqlite3_step failed: NOT NULL constraint failed: derivedcompoundref.base
sqlite3_step failed: NOT NULL constraint failed: derivedcompoundref.base
sqlite3_step failed: NOT NULL constraint failed: derivedcompoundref.base
sqlite3_step failed: NOT NULL constraint failed: derivedcompoundref.base
Generating Sqlite3 output for class Gtk::WindowGroup
Generating Sqlite3 output for class Gtk::WindowGroup
Comment 3 Murray Cumming 2015-02-03 11:57:34 UTC
I seem to have fixed this by adding our regular "#ifndef DOXYGEN_SHOULD_SKIP_THIS" around the *_Class prototype declarations, in glibmm:
https://git.gnome.org/browse/glibmm/commit/?id=a3b4eeff1bb475d29f92fdfd2b2975274750e081
and in gtkmm:
https://git.gnome.org/browse/gtkmm/commit/?id=00fa70e71b2637735360cce56f9f1bc2afc8674a

It has even fixed the problem with GtkTreeModeColumnBase, which isn't even generated. So maybe doxygen was just very confused.

I still suspect that it might be the lack of a newline between the declarations rather than the existence of the prototype at all, which triggers the doxygen problem, but this works.
Comment 4 Kjell Ahlstedt 2015-02-11 15:01:24 UTC
I have tested with and without the two patches in comment 3, and with
different versions of doxygen. Comparing the generated tag files for gtkmm,
the results are:

Doxygen version    Without patches   With patches
---------------    ---------------   ------------
1.8.7              A, wrong          A, wrong
1.8.8 Ubuntu       B, wrong          B, wrong
1.8.9              C, correct        C, correct
1.8.9.1            C, correct        C, correct

"1.8.8 Ubuntu" is the version of doxygen delivered with Ubuntu 14.10.
Doxygen 1.8.8 fetched from ftp://ftp.stack.nl/pub/users/dimitri/ crashes.
A, B and C are differences in the generated tag files. A and B files are almost
identical. C files differ much more from A and B files.

The patches don't affect the generated tag files. Different versions of
doxygen generate different tag files, except that 1.8.9 and 1.8.9.1 generate
identical files.

The errors in tag files A and B are similar to the errors described in doxygen
bug 707971 and bug 736992, i.e. it depends on the alphabetical ordering of
class names in an inheritance hierarchy.

Example 1:
  class Widget : public ...
  class Container : public Widget
  class Bin : public Container
  class Window : public Bin
  class Dialog : public Window
  class AboutDialog : public Dialog

AboutDialog precedes all its base classes when the names are sorted
alphabetically. All members of the base classes are listed as belonging to
AboutDialog.

Example 2:
  class CellRenderer : public ...
  class CellRendererText : public CellRenderer
  class CellRendererAccel : public CellRendererText

The alphabetic order is: CellRenderer, CellRendererAccel, CellRendererText.
CellRendererText's members are listed under CellRendererAccel. They are not
listed under CellRenderer, because members are only "down-cast" to a subclass,
never "up-cast" to a base class.