[Webkit-unassigned] [Bug 43054] WebBackForwardList.get_{back|forward}_list_with_limit not introspectable

Fri Aug 13 12:29:55 PDT 2010

https://bugs.webkit.org/show_bug.cgi?id=43054

Gustavo Noronha (kov) <gns at gnome.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|webkit-unassigned at lists.web |gns at gnome.org
                   |kit.org                     |
  Attachment #64364|                            |review?
               Flag|                            |

--- Comment #1 from Gustavo Noronha (kov) <gns at gnome.org>  2010-08-13 12:29:55 PST ---
Created an attachment (id=64364)
 --> (https://bugs.webkit.org/attachment.cgi?id=64364)
proposed patch

This should fix the problem, including the crash lucian told me about when getting the WebBackForwardList from the view more than once (GI thought the ownership was being transferred, but it was not). You'll notice the patch moves all of the docstrings to the header file, and here's why:

The g-ir-scanner is currently unable to parse .cpp files. That is why we only feed it .h files in our build system, I imagine. That means any annotation added to the .cpp file docstrings are going to be ignored. The first thing that came to my mind, that would not be too disruptive is to add a smaller docstring in the header file that would only have the information required by the introspection. I tried that, but it breaks our documentation generation horribly. gtk-doc prefers the docstring it finds in the header, and ignores the one in the .cpp file. If I tell gtk-doc to ignore the header file it generates a rather empty page that only lists the example \o/

So I believe our only way out here, other than fixing the g-ir-scanner to read the .cpp files, is to move all doc strings to .h files. If we have a consensus around this, I will do follow-up patches moving the docstrings for each object, and trying to add the required GI annotation to all of them in the process. Comments?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.