Gtk2Hs: Ticket Queryhttp://trac.haskell.org/gtk2hs/query?group=status&milestone=1.0&row=description
The Gtk2Hs projecten-USGtk2Hshttp://projects.haskell.org/gtk2hs/Gtk2Hs-bug-tracker-banner-nobg.pnghttp://trac.haskell.org/gtk2hs/query?group=status&milestone=1.0&row=description
Trac 0.11.1http://trac.haskell.org/gtk2hs/ticket/1094
http://trac.haskell.org/gtk2hs/ticket/1094#1094: Enumeration documentation needs updatingMon, 05 Mar 2007 11:19:40 GMTduncan<p>
The gtk/Graphics/UI/Gtk/General/Enums.chs.pp module has not seen much love. In particular the documentation has never been updated.
</p>
<p>
I think what needs to be done is that the code gen should be modified to deal with them as follows: for enums used only in a single module, they should be defined, documented and exported from that module; for enums that are shared they should be defined and documented in a shared module.
</p>
<p>
Currently the code gen does not deal with generating definitions for enums at all.
</p>
Resultshttp://trac.haskell.org/gtk2hs/ticket/1094#changeloghttp://trac.haskell.org/gtk2hs/ticket/1219
http://trac.haskell.org/gtk2hs/ticket/1219#1219: gtk fails to build - ghc: out of memoryFri, 06 May 2011 19:41:47 GMTguest<p>
i'm trying to build gtk (gtk2hs), but everytime it spits out this error message, that it's out of memory.
i've tried with different ghc-options (setting +RTS etc), but they don't help. don't know how to solve this.
</p>
<p>
OS: OpenBSD 4.9
Arch: amd64
GHC version: 6.12.3
Cabal version: 1.8.0.6
</p>
<p>
Attached is the build log.
</p>
Resultshttp://trac.haskell.org/gtk2hs/ticket/1219#changeloghttp://trac.haskell.org/gtk2hs/ticket/1112
http://trac.haskell.org/gtk2hs/ticket/1112#1112: "Xlib: unexpected async reply" with threaded RTS and --sync command line parameterMon, 24 Mar 2008 01:23:49 GMTguest<p>
A trivial program which uses unsafeInitGUIForThreadedRTS, and doesn't even start additional threads, causes the above error message when started with the "--sync" command line parameter. It has to be compiled with "-threaded", but multithreading doesn't need to be enabled at runtime for the error to occur. The same problem occurs even without the "--sync" parameter, but only in a much more complex program. All the parameter does is tell X to report errors synchronously.
</p>
<p>
Calling XInitThreads at the start of main makes the error disappear, which indicates that Haskell calls Gtk (which in turn calls X) from multiple OS threads.
</p>
<p>
The attached archive contains three versions of the same program:
</p>
<ol><li>broken.hs prints the error and hangs. Some fierce resizing (i. e. Expose events) may be necessary to trigger the error.
</li><li>working.hs merely adds a call to XInitThreads and doesn't hang regardless of the amount of resizing.
</li><li>test.c is an equivalent program in C, which works fine without calling XInitThreads.
</li></ol>Resultshttp://trac.haskell.org/gtk2hs/ticket/1112#changeloghttp://trac.haskell.org/gtk2hs/ticket/1128
http://trac.haskell.org/gtk2hs/ticket/1128#1128: Support cabal installWed, 25 Jun 2008 21:45:39 GMTguest<p>
soegtk-9.12.2 fails to build. I get the following error message:
</p>
<pre class="wiki">~/tmp/soegtk-0.9.12.2: cabal install
Resolving dependencies...
Configuring soegtk-0.9.12.2...
Preprocessing library soegtk-0.9.12.2...
Building soegtk-0.9.12.2...
Graphics/SOE/Gtk.hs:94:17:
Could not find module `System.Time':
it is a member of package old-time-1.0.0.0, which is hidden
cabal: Error: some packages failed to install:
soegtk-0.9.12.2 failed during the building phase. The exception was:
exit: ExitFailure 1
</pre>Resultshttp://trac.haskell.org/gtk2hs/ticket/1128#changeloghttp://trac.haskell.org/gtk2hs/ticket/1234
http://trac.haskell.org/gtk2hs/ticket/1234#1234: build failure in glib-0.12.0 using ghc 7.2.1Thu, 25 Aug 2011 18:09:46 GMTguest<p>
With ghc 7.2.1 the following error is found:
</p>
<pre class="wiki"> Implicit import declaration:
Ambiguous module name `Prelude':
it was found in multiple packages: base haskell98-2.0.0.0
make: *** [build-ghc-stamp] Error 1
</pre>Resultshttp://trac.haskell.org/gtk2hs/ticket/1234#changeloghttp://trac.haskell.org/gtk2hs/ticket/1296
http://trac.haskell.org/gtk2hs/ticket/1296#1296: Broken links at Graphics.UI.Gtk.Abstract.Separator in HackageMon, 24 Mar 2014 15:37:41 GMTguest<p>
Most links on the class hierarchy in this page are broken:
<a class="ext-link" href="http://hackage.haskell.org/package/gtk-0.12.5.6/docs/Graphics-UI-Gtk-Abstract-Separator.html"><span class="icon">http://hackage.haskell.org/package/gtk-0.12.5.6/docs/Graphics-UI-Gtk-Abstract-Separator.html</span></a>
</p>
<p>
For example, the following pages do not exist:
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/package/gtk-0.12.5.6/docs/Graphics-UI-Gtk-Ornaments.html#t:HSeparator"><span class="icon">http://hackage.haskell.org/package/gtk-0.12.5.6/docs/Graphics-UI-Gtk-Ornaments.html#t:HSeparator</span></a>
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/package/gtk-0.12.5.6/docs/Graphics-UI-Gtk-Ornaments.html#t:VSeparator"><span class="icon">http://hackage.haskell.org/package/gtk-0.12.5.6/docs/Graphics-UI-Gtk-Ornaments.html#t:VSeparator</span></a>
</p>
<p>
and they should be, respectively:
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/package/gtk-0.12.5.6/docs/Graphics-UI-Gtk-Ornaments-HSeparator.html#t:HSeparator"><span class="icon">http://hackage.haskell.org/package/gtk-0.12.5.6/docs/Graphics-UI-Gtk-Ornaments-HSeparator.html#t:HSeparator</span></a>
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/package/gtk-0.12.5.6/docs/Graphics-UI-Gtk-Ornaments-VSeparator.html#t:VSeparator"><span class="icon">http://hackage.haskell.org/package/gtk-0.12.5.6/docs/Graphics-UI-Gtk-Ornaments-VSeparator.html#t:VSeparator</span></a>
</p>
Resultshttp://trac.haskell.org/gtk2hs/ticket/1296#changeloghttp://trac.haskell.org/gtk2hs/ticket/1167
http://trac.haskell.org/gtk2hs/ticket/1167#1167: Think about resource managementThu, 14 May 2009 09:15:34 GMTguest<p>
It is very easy to get a memory leak. For example these buttons will never get freed:
</p>
<pre class="wiki"> replicateM_ 1234 $ do
b &lt;- buttonNew
onStateChanged b $ \_ -&gt; widgetGetSize b &gt;&gt;= print
</pre><p>
You can correct this example with eventGetWindow, but that doesn't apply to signals.
</p>
<p>
The memory leaks in a typical app are small. However, avoiding these leaks may involve API changes so it's important to think about. I suggest, at least, an explicit "objectUnref" action that cancels the finalizer. Then app writers can take care of memory management.
</p>
<p>
As a nicer API, since a UI is just a tree, perhaps Containers could automatically manage the refs for their children.
</p>
Resultshttp://trac.haskell.org/gtk2hs/ticket/1167#changeloghttp://trac.haskell.org/gtk2hs/ticket/1226
http://trac.haskell.org/gtk2hs/ticket/1226#1226: castToSpinner not availableThu, 07 Jul 2011 15:40:32 GMTguest<p>
I'm using Glade and I want a spinner in a UI. But castToSpinner doesn't exist or is hidden somewhere, so I can't access a spinner from a Builder object.
</p>
Resultshttp://trac.haskell.org/gtk2hs/ticket/1226#changelog