gtk2hs-devel Mailing List for Gtk2Hs - A GUI Library for Haskell

Thanks for the reminder. I took a look at the one pull request, but don't
see a second one.

~d

On Mon, Feb 23, 2015 at 7:48 AM, koral <ko...@ma...> wrote:

> Hello,
>
> Is anyone watching webkit's github repository ? I've made a pull request a
> month ago, without response, and there's another one from Oct 2014... Maybe
> the owners weren't notified ?
>
> Cheers.
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Gtk2hs-devel mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>
>

Hello,

Is anyone watching webkit's github repository ? I've made a pull request a month ago, without response, and there's another one from Oct 2014... Maybe the owners weren't notified ?

Cheers.

Excerpts from Norbert Zeh's message of 2014-09-14 16:33:00 -0700:
> EventM should export the type classes HasCoordinates, HasRootCoordinates,

As discussed in the documentation, these classes are intentionally not
exported to prevent users from declaring instances for these for types
that really don't support them. This would lead to a runtime error when
we ask Gtk for a coordinate that doesn't exist in the event.

~d

Hi Norbert --

These two changes (exporting Allocation + eta-reducing EventM) are now
pushed to the repo. Thanks for the suggestions.

~d

Excerpts from Norbert Zeh's message of 2014-10-30 04:07:42 -0700:
> Thanks.  I just added the export to Widget and manually compiled it here.
> I also changed the type definition of EventM as pointed out in an earlier
> message I sent.  This bug is still present in the current version of
> gtk2hs.  To elaborate: With the current definition of EventM
> 
> type EventM t a = ReaderT (Ptr t) IO a
> 
> it is impossible to use (EventM t) as an argument to a monad transformer,
> e.g.
> 
> type EventMWithState t a = StateT MyState (EventM t) a.
> 
> There are two ways to make this possible.  Either EventM becomes a newtype,
> along with the necessary boilerplate.  That's probably not necessary here.
> The second option is to define
> 
> type EventM t = ReaderT (Ptr t) IO.
> 
> This allows (EventM t) to be combined with monad transformers.
> 
> Cheers,
> Norbert
> 
> On Thu, Oct 30, 2014 at 3:32 AM, Axel Simon <Axe...@in...> wrote:
> 
> > Hi Norbert,
> >
> > On 29.10.2014, at 22:37, Norbert Zeh <nz...@cs...> wrote:
> >
> > > Hi folks,
> > >
> > > I just tried to connect to the sizeAllocate signal of the Widget type,
> > but the type of this signal is Signal self (Allocation -> IO ()).  Thus,
> > the function I provide as an argument needs to take an Allocation as an
> > argument, but I cannot declare a function of this type because Allocation
> > seems to be only exported by the hidden module
> > Graphics.UI.Gtk.General.Structs.  Any advice on how to react to
> > sizeAllocate signals?
> > >
> >
> > Well, it’s a bug, it should be exported from Widget. However, it’s only a
> > type synonym to Rectangle which is public, so using the Rectangle
> > constructor should be possible.
> >
> > Cheers,
> > Axel
> >
> > > Thanks,
> > > Norbert
> > >
> > ------------------------------------------------------------------------------
> > > _______________________________________________
> > > Gtk2hs-devel mailing list
> > > Gtk...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
> >
> >

Thanks.  I just added the export to Widget and manually compiled it here.
I also changed the type definition of EventM as pointed out in an earlier
message I sent.  This bug is still present in the current version of
gtk2hs.  To elaborate: With the current definition of EventM

type EventM t a = ReaderT (Ptr t) IO a

it is impossible to use (EventM t) as an argument to a monad transformer,
e.g.

type EventMWithState t a = StateT MyState (EventM t) a.

There are two ways to make this possible.  Either EventM becomes a newtype,
along with the necessary boilerplate.  That's probably not necessary here.
The second option is to define

type EventM t = ReaderT (Ptr t) IO.

This allows (EventM t) to be combined with monad transformers.

Cheers,
Norbert


On Thu, Oct 30, 2014 at 3:32 AM, Axel Simon <Axe...@in...> wrote:

> Hi Norbert,
>
> On 29.10.2014, at 22:37, Norbert Zeh <nz...@cs...> wrote:
>
> > Hi folks,
> >
> > I just tried to connect to the sizeAllocate signal of the Widget type,
> but the type of this signal is Signal self (Allocation -> IO ()).  Thus,
> the function I provide as an argument needs to take an Allocation as an
> argument, but I cannot declare a function of this type because Allocation
> seems to be only exported by the hidden module
> Graphics.UI.Gtk.General.Structs.  Any advice on how to react to
> sizeAllocate signals?
> >
>
> Well, it’s a bug, it should be exported from Widget. However, it’s only a
> type synonym to Rectangle which is public, so using the Rectangle
> constructor should be possible.
>
> Cheers,
> Axel
>
> > Thanks,
> > Norbert
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Gtk2hs-devel mailing list
> > Gtk...@li...
> > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>
>

Hi Norbert,

On 29.10.2014, at 22:37, Norbert Zeh <nz...@cs...> wrote:

> Hi folks,
> 
> I just tried to connect to the sizeAllocate signal of the Widget type, but the type of this signal is Signal self (Allocation -> IO ()).  Thus, the function I provide as an argument needs to take an Allocation as an argument, but I cannot declare a function of this type because Allocation seems to be only exported by the hidden module Graphics.UI.Gtk.General.Structs.  Any advice on how to react to sizeAllocate signals?
> 

Well, it’s a bug, it should be exported from Widget. However, it’s only a type synonym to Rectangle which is public, so using the Rectangle constructor should be possible.

Cheers,
Axel

> Thanks,
> Norbert
> ------------------------------------------------------------------------------
> _______________________________________________
> Gtk2hs-devel mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel

Hi folks,

I just tried to connect to the sizeAllocate signal of the Widget type, but
the type of this signal is Signal self (Allocation -> IO ()).  Thus, the
function I provide as an argument needs to take an Allocation as an
argument, but I cannot declare a function of this type because Allocation
seems to be only exported by the hidden module
Graphics.UI.Gtk.General.Structs.  Any advice on how to react to
sizeAllocate signals?

Thanks,
Norbert

More improvement suggestions:

EventM should export the type classes HasCoordinates, HasRootCoordinates,
etc.  I just ran into a situation where I wrote an action that retrieves
the event coordinates and then manipulates them, and I am using it in
different types of event handlers that all have coordinates. Doing this,
however, worked only after adding these type classes to EventM's export
list.

Cheers,
Norbert

On Wed, Sep 10, 2014 at 8:37 AM, Norbert Zeh <nz...@cs...> wrote:

> Hi folks,
>
> First of all, thanks for gtk2hs.  It's already awesome.  There are a
> number of improvements I would suggest and I may even be willing to work on
> if I can find the time.
>
> #1:  This one is a 10-second programming effort and is really necessary, I
> think.
>
> The current definition of EventM is
>
> type EventM t a = ReaderT (Ptr t) IO a
>
> This is unfortunate because it prevents users from wrapping this in a
> monad transformer, for example to carry application state around.  For
> example, if I were to try to define an action
>
> doSomething :: StateT MyState (EventM any) Bool
>
> the compiler complains because EventM expects two type arguments and was
> given only one.  The fix is simple:  Change the definition of EventM to
>
> type EventM t = ReaderT (Ptr t) IO.
>
> (Arguably, the plumbing should be hidden and EventM should be a newtype,
> but that would be more effort because it probably requires changes
> elsewhere in the gtk2hs code base.)
>
> #2:  MonadIO and type classes for EventM and Render
>
> Let me start by saying that I am not sure how hard this is to do, but it
> would help users a lot.  Again, the motivation is that applications often
> use monad transformers to carry state around, so the main monad may not be
> IO but something like StateT MyState IO.  Now using pretty much all the
> standard gtk functions requires cluttering the code with lots of calls to
> liftIO.  Changing the type signature of all gtk2hs functions as illustrated
> here for buttonNew would solve this:  Currently, the type of buttonNew is
>
> buttonNew :: IO Button
>
> Can't we make it
>
> buttonNew :: MonadIO m => m Button ?
>
> This would eliminate the need for lifting in the user code.  The same
> reasoning applies to Render and EventM, except that it requires more effort
> because one would have to define type classes such as MonadEventM and
> MonadRender.  The lack of this approach for EventM is quite a bit more
> annoying than the need to sprinkle liftIO's throughout the code because
> passing an event handler wrapped in a StateT transformer or similar to "on"
> explicitly requires packing and unpacking the state.
>
> Let me close by saying once more that I am happy gtk2hs exists because,
> even though I say "annoying" above, it would be more annoying not to have
> gtk2hs for GUI development in Haskell.  Thanks for your efforts, guys.
>
> Cheers,
> Norbert
>

Hi folks,

First of all, thanks for gtk2hs.  It's already awesome.  There are a number
of improvements I would suggest and I may even be willing to work on if I
can find the time.

#1:  This one is a 10-second programming effort and is really necessary, I
think.

The current definition of EventM is

type EventM t a = ReaderT (Ptr t) IO a

This is unfortunate because it prevents users from wrapping this in a monad
transformer, for example to carry application state around.  For example,
if I were to try to define an action

doSomething :: StateT MyState (EventM any) Bool

the compiler complains because EventM expects two type arguments and was
given only one.  The fix is simple:  Change the definition of EventM to

type EventM t = ReaderT (Ptr t) IO.

(Arguably, the plumbing should be hidden and EventM should be a newtype,
but that would be more effort because it probably requires changes
elsewhere in the gtk2hs code base.)

#2:  MonadIO and type classes for EventM and Render

Let me start by saying that I am not sure how hard this is to do, but it
would help users a lot.  Again, the motivation is that applications often
use monad transformers to carry state around, so the main monad may not be
IO but something like StateT MyState IO.  Now using pretty much all the
standard gtk functions requires cluttering the code with lots of calls to
liftIO.  Changing the type signature of all gtk2hs functions as illustrated
here for buttonNew would solve this:  Currently, the type of buttonNew is

buttonNew :: IO Button

Can't we make it

buttonNew :: MonadIO m => m Button ?

This would eliminate the need for lifting in the user code.  The same
reasoning applies to Render and EventM, except that it requires more effort
because one would have to define type classes such as MonadEventM and
MonadRender.  The lack of this approach for EventM is quite a bit more
annoying than the need to sprinkle liftIO's throughout the code because
passing an event handler wrapped in a StateT transformer or similar to "on"
explicitly requires packing and unpacking the state.

Let me close by saying once more that I am happy gtk2hs exists because,
even though I say "annoying" above, it would be more annoying not to have
gtk2hs for GUI development in Haskell.  Thanks for your efforts, guys.

Cheers,
Norbert

I have posted to the Gtk2Hs blog about adding Text support in 0.13
http://projects.haskell.org/gtk2hs/archives/2014/07/08/planned-013-release-to-add-text-support/

Here is the content of the blog post...

I have prepared a 0.13 release that will add support for using Text (for 
functions that currently only work with String). It does this with a new 
GlibString type class that has instances for both String and Text. All the 
functions that currently use String have been changed to use this type 
class instead. This allows you to switch your code easily from String to 
Text or use a mix of the two if you wish (but not in the same function 
call as it would make for more type inference issues).

This is a breaking change (hence the bump to 0.13). If you have issues 
with existing code then it will most likely be ambiguous type errors. 
The solution will probably be one of:

 * Stick with 0.12 for now - set an upper bound in the cabal file 
   (existing code should really have a <0.13 upper bound for Gtk2Hs 
   packages already).
 * Add type signatures - to help GHC infer the type of strings you are 
   using. Leksah required the addition of around 20 type signatures.

I think the most common issue will probably be when Nothing is passed to 
a function, because GHC cannot infer the type of thisNothing. One solution 
is to change it to (Nothing :: Maybe String).

The 0.13 code is currently in the master branches of the various 
https://github.com/gtk2hs repositories. Please try it out and let us know 
if there is anything we need to address before releasing it to Hackage. 
We can still fix stuff after that, but it would be nice to know if there is 
anything major that we should address now.

Hamish

Applied, thanks!

On 2014-05-15 04:16, Axel Simon wrote:
> Hi Daniel,
> 
> I'm attaching a patch to fix a parsing issue that gtk's c2hs has on
> Mac OS. I've tried to compile koral's webkit problem but I'm still
> struggling.
> 
> Cheers,
> Axel
> 
> 
> 
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform 
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> 
> _______________________________________________
> Gtk2hs-devel mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel

Hi Daniel,

I'm attaching a patch to fix a parsing issue that gtk's c2hs has on Mac OS. I've tried to compile koral's webkit problem but I'm still struggling.

Cheers,
Axel

Hi Daniel,

I'm attaching a patch to fix a parsing issue that gtk's c2hs has on Mac OS. I've tried to compile koral's webkit problem but I'm still struggling.

Cheers,
Axel

On Sun, Feb 23, 2014 at 7:46 AM, Axel Simon <Axe...@in...> wrote:
> Dear Don,
>
> I haven't tracked the developments of ghc's concurrency recently so I don't know if there is still this -threaded option or if everything is nowadays multithreaded. There used to be the necessity to install this call-back that would run the main loop of Gtk+ while the Haskell program has got nothing to do. If there is some sort of stall/backlag/timeout in connection with messages that make the popup disappear when it does not disappear in C then it might be related to this. Maybe you try to connect to unrealize/hide messages of the popup window and at least try to find out if it is hidden or destroyed?

I have another data point, discovered this morning on a hunch. First
of all, my setup is up-to-date 64-bit Arch Linux. I do not run a
desktop system, just a window manager, xmonad. When testing my
application, I start it from an xterm (as opposed, say, to dmenu).
Main window comes up, displaying the tree of accounts. I then
double-click an account to display its transactions in a register. The
register is the problem window. With all three windows on the screen,
I reliably get the bad behavior I've reported. This morning, I tried
minimizing (I import XMonad.Layout.Minimize) both the xterm and
account-tree windows, so that the register window was now the only
window on the screen. Right-clicked to get the popup and -- voila --
rock-solid. I repeated the experiment several times and the popup
behaves correctly.

Next, I tried shutting down xmonad and running fvwm instead. With all
three windows on the screen, I got the incorrect behavior. I then
iconified the xterm and account-tree window, leaving only the register
window. Just to further confuse us, the incorrect behavior occurred
persistently!

I think you are on to something in what you say in your message. The
behavior certainly smacks of some sort of a timeout occurring. The
first time you try to bring up a popup with all three windows on the
screen, it will remain on-screen for about 10 seconds, consistently.
I'll bet there is a 10 second timeout buried somewhere in the code.
I'll try to pursue your suggestion.

/Don

>
> Cheers,
> Axel
>
> On 21.02.2014, at 14:00, Donald Allen <don...@gm...> wrote:
>
>>
>>
>>
>> On Thu, Feb 20, 2014 at 2:55 PM, Daniel Wagner <da...@wa...> wrote:
>> Man, you have *got* to get into the habit of creating a minimal working
>> example. =)
>>
>> Yeah, I know. I only had a 45 year career in computer science, running software projects large and small (including the Tenex project at BBN when Tenex was the predominant host OS on the ArpaNet), wrote my first computer program in 1960 (IBM 1620 assembly code), so I'm still a newbie, still learning, but I'm trying.
>>
>> Seriously, I did attempt to reproduce the problem with a small example and got the same result you did -- the popup menu works correctly (our examples were almost identical, but I did try yours to be sure and it works correctly as it did for you). I have not been able to devote time to this since I sent my message, but returned to it yesterday, trying to find the difference between what my application is doing and both our small examples. This resulted in a useful bit of information: my application has another window, call it Window B, that also needs a popup, which I hadn't gotten to. I adapted the little snippet of code from the failing window (Window A) to produce a right-button popup in Window B. This one works correctly.
>>
>> Window A: a window containing a scrolled window containing a treeview. The treeview's model is a TreeModelSort whose child model is a ListStore. The popup fails in this window as described.
>> Window B: a window containing a scrolled window containing a treeview. The treeview's model is a TreeStore. The popup works correctly with this window.
>>
>> So I'm a bit closer to isolating what's going on here, but I'm not there yet.
>>
>> The minimal framework I could put around your code to make it run is
>> included below. It does not have the problem you describe. Does the code
>> below show the bad behavior you describe when you try it? If not, could
>> you please try to cook up the smallest piece of code that *does*
>> reproduce your problem?
>>
>> ~d
>>
>> import Control.Monad.IO.Class
>> import Graphics.UI.Gtk
>>
>> main = do
>>         initGUI
>>         w <- windowNew
>>         b <- buttonNewWithLabel "foo"
>>         on b buttonPressEvent (tryEvent (do button <- eventButton
>>                                             theTime <- eventTime
>>                                             case button of
>>                                                 RightButton -> liftIO
>> (mouseButtonPressed theTime)
>>                                                 _ -> stopEvent))
>>         containerAdd w b
>>         widgetShowAll w
>>         mainGUI
>>
>> mouseButtonPressed :: TimeStamp -> IO ()
>> mouseButtonPressed theTime
>>     = do menu <- menuNew
>>          print "mouseButtonPressed called"
>>          print ("time", theTime)
>>          menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
>>          on menuItem menuItemActivated (putStrLn "activated, lol")
>>          menuShellAppend menu menuItem
>>          menuItem <- menuItemNewWithLabel "Duplicate selected transaction
>> (ctrl-d)"
>>          menuShellAppend menu menuItem
>>          widgetShowAll menu
>>          print "about to call menuPopup"
>>          menuPopup menu (Just (RightButton, theTime))
>>
>> On 2014-02-18 20:17, Donald Allen wrote:
>>
>> > I am trying to pop up a menu when the right button is pressed with the
>> > cursor in a particular treeview. I set up the event handler as follows:
>> >
>> > -- Handle buttonPressEvent within the view
>> > on view buttonPressEvent (tryEvent (do button <- eventButton
>> > theTime <- eventTime
>> > case button of
>> > RightButton -> liftIO (mouseButtonPressed theTime accountRegister
>> > globals)
>> > _ -> stopEvent))
>> >
>> > and
>> >
>> > mouseButtonPressed :: TimeStamp -> AccountRegister -> Globals -> IO ()
>> > mouseButtonPressed theTime accountRegister globals
>> > = do menu <- menuNew
>> > print "mouseButtonPressed called"
>> > print ("time", theTime)
>> > menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
>> > on menuItem menuItemActivated (newTransaction accountRegister globals)
>> > menuShellAppend menu menuItem
>> > menuItem <- menuItemNewWithLabel "Duplicate selected transaction
>> > (ctrl-d)"
>> > menuShellAppend menu menuItem
>> > widgetShowAll menu
>> > print "about to call menuPopup"
>> > menuPopup menu (Just (RightButton, theTime))
>> >
>> > The first time I press the right button, the menu appears for perhaps
>> > 10 seconds and then disappears. During that time, I can click 'New
>> > transaction' and the right thing happens. The second time I press the
>> > right button, the menu appears very briefly, less than a second and
>> > then disappears. Subsequent right clicks behave the same. In other
>> > words, useless.
>> >
>> > The debugging prints in mouseButtonPressed all appear in response to
>> > the right clicks. The event time advances, as you would expect.
>> >
>> > I'm at a complete loss as to what might be causing this and can't
>> > continue with my project if this is not solved. Any suggestions would
>> > be appreciated.
>> >
>> > ------------------------------------------------------------------------------
>> > Managing the Performance of Cloud-Based Applications
>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> > Read the Whitepaper.
>> > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> > [1]
>> >
>> > _______________________________________________
>> > Gtk2hs-devel mailing list
>> > Gtk...@li...
>> > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel [2]
>>
>>
>>
>> Links:
>> ------
>> [1]
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&amp;iu=/4140/ostg.clktrk
>> [2] https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Gtk2hs-devel mailing list
>> Gtk...@li...
>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
>> Gtk2hs-devel mailing list
>> Gtk...@li...
>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>

Dear Don,

I haven't tracked the developments of ghc's concurrency recently so I don't know if there is still this -threaded option or if everything is nowadays multithreaded. There used to be the necessity to install this call-back that would run the main loop of Gtk+ while the Haskell program has got nothing to do. If there is some sort of stall/backlag/timeout in connection with messages that make the popup disappear when it does not disappear in C then it might be related to this. Maybe you try to connect to unrealize/hide messages of the popup window and at least try to find out if it is hidden or destroyed?

Cheers,
Axel

On 21.02.2014, at 14:00, Donald Allen <don...@gm...> wrote:

> 
> 
> 
> On Thu, Feb 20, 2014 at 2:55 PM, Daniel Wagner <da...@wa...> wrote:
> Man, you have *got* to get into the habit of creating a minimal working
> example. =)
> 
> Yeah, I know. I only had a 45 year career in computer science, running software projects large and small (including the Tenex project at BBN when Tenex was the predominant host OS on the ArpaNet), wrote my first computer program in 1960 (IBM 1620 assembly code), so I'm still a newbie, still learning, but I'm trying.
> 
> Seriously, I did attempt to reproduce the problem with a small example and got the same result you did -- the popup menu works correctly (our examples were almost identical, but I did try yours to be sure and it works correctly as it did for you). I have not been able to devote time to this since I sent my message, but returned to it yesterday, trying to find the difference between what my application is doing and both our small examples. This resulted in a useful bit of information: my application has another window, call it Window B, that also needs a popup, which I hadn't gotten to. I adapted the little snippet of code from the failing window (Window A) to produce a right-button popup in Window B. This one works correctly.
> 
> Window A: a window containing a scrolled window containing a treeview. The treeview's model is a TreeModelSort whose child model is a ListStore. The popup fails in this window as described.
> Window B: a window containing a scrolled window containing a treeview. The treeview's model is a TreeStore. The popup works correctly with this window.
> 
> So I'm a bit closer to isolating what's going on here, but I'm not there yet.
> 
> The minimal framework I could put around your code to make it run is
> included below. It does not have the problem you describe. Does the code
> below show the bad behavior you describe when you try it? If not, could
> you please try to cook up the smallest piece of code that *does*
> reproduce your problem?
> 
> ~d
> 
> import Control.Monad.IO.Class
> import Graphics.UI.Gtk
> 
> main = do
>         initGUI
>         w <- windowNew
>         b <- buttonNewWithLabel "foo"
>         on b buttonPressEvent (tryEvent (do button <- eventButton
>                                             theTime <- eventTime
>                                             case button of
>                                                 RightButton -> liftIO
> (mouseButtonPressed theTime)
>                                                 _ -> stopEvent))
>         containerAdd w b
>         widgetShowAll w
>         mainGUI
> 
> mouseButtonPressed :: TimeStamp -> IO ()
> mouseButtonPressed theTime
>     = do menu <- menuNew
>          print "mouseButtonPressed called"
>          print ("time", theTime)
>          menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
>          on menuItem menuItemActivated (putStrLn "activated, lol")
>          menuShellAppend menu menuItem
>          menuItem <- menuItemNewWithLabel "Duplicate selected transaction
> (ctrl-d)"
>          menuShellAppend menu menuItem
>          widgetShowAll menu
>          print "about to call menuPopup"
>          menuPopup menu (Just (RightButton, theTime))
> 
> On 2014-02-18 20:17, Donald Allen wrote:
> 
> > I am trying to pop up a menu when the right button is pressed with the
> > cursor in a particular treeview. I set up the event handler as follows:
> >
> > -- Handle buttonPressEvent within the view
> > on view buttonPressEvent (tryEvent (do button <- eventButton
> > theTime <- eventTime
> > case button of
> > RightButton -> liftIO (mouseButtonPressed theTime accountRegister
> > globals)
> > _ -> stopEvent))
> >
> > and
> >
> > mouseButtonPressed :: TimeStamp -> AccountRegister -> Globals -> IO ()
> > mouseButtonPressed theTime accountRegister globals
> > = do menu <- menuNew
> > print "mouseButtonPressed called"
> > print ("time", theTime)
> > menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
> > on menuItem menuItemActivated (newTransaction accountRegister globals)
> > menuShellAppend menu menuItem
> > menuItem <- menuItemNewWithLabel "Duplicate selected transaction
> > (ctrl-d)"
> > menuShellAppend menu menuItem
> > widgetShowAll menu
> > print "about to call menuPopup"
> > menuPopup menu (Just (RightButton, theTime))
> >
> > The first time I press the right button, the menu appears for perhaps
> > 10 seconds and then disappears. During that time, I can click 'New
> > transaction' and the right thing happens. The second time I press the
> > right button, the menu appears very briefly, less than a second and
> > then disappears. Subsequent right clicks behave the same. In other
> > words, useless.
> >
> > The debugging prints in mouseButtonPressed all appear in response to
> > the right clicks. The event time advances, as you would expect.
> >
> > I'm at a complete loss as to what might be causing this and can't
> > continue with my project if this is not solved. Any suggestions would
> > be appreciated.
> >
> > ------------------------------------------------------------------------------
> > Managing the Performance of Cloud-Based Applications
> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > Read the Whitepaper.
> > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> > [1]
> >
> > _______________________________________________
> > Gtk2hs-devel mailing list
> > Gtk...@li...
> > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel [2]
> 
> 
> 
> Links:
> ------
> [1]
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&amp;iu=/4140/ostg.clktrk
> [2] https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Gtk2hs-devel mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
> Gtk2hs-devel mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel

On Fri, Feb 21, 2014 at 8:00 AM, Donald Allen <don...@gm...>wrote:

>
>
>
> On Thu, Feb 20, 2014 at 2:55 PM, Daniel Wagner <da...@wa...>wrote:
>
>> Man, you have *got* to get into the habit of creating a minimal working
>> example. =)
>>
>
> Yeah, I know. I only had a 45 year career in computer science, running
> software projects large and small (including the Tenex project at BBN when
> Tenex was the predominant host OS on the ArpaNet), wrote my first computer
> program in 1960 (IBM 1620 assembly code), so I'm still a newbie, still
> learning, but I'm trying.
>
> Seriously, I did attempt to reproduce the problem with a small example and
> got the same result you did -- the popup menu works correctly (our examples
> were almost identical, but I did try yours to be sure and it works
> correctly as it did for you). I have not been able to devote time to this
> since I sent my message, but returned to it yesterday, trying to find the
> difference between what my application is doing and both our small
> examples. This resulted in a useful bit of information: my application has
> another window, call it Window B, that also needs a popup, which I hadn't
> gotten to. I adapted the little snippet of code from the failing window
> (Window A) to produce a right-button popup in Window B. This one works
> correctly.
>
> Window A: a window containing a scrolled window containing a treeview. The
> treeview's model is a TreeModelSort whose child model is a ListStore. The
> popup fails in this window as described.
> Window B: a window containing a scrolled window containing a treeview. The
> treeview's model is a TreeStore. The popup works correctly with this window.
>
> So I'm a bit closer to isolating what's going on here, but I'm not there
> yet.
>

More info, from experiments this morning.

The failing windows are account registers (my application is a personal
financial manager). If I attempt to display a popup in a register with a
lot of rows (transactions), I get the incorrect behavior (first time, the
popup remains on the screen for about 10 seconds; subsequent times, it's up
just for a moment). If I do the same thing with an account with few rows, I
usually get correct behavior. But if I have one of each on the screen and
induce the bad behavior in the one with many rows, I will then get the bad
behavior in the one with few rows. This will also induce the bad behavior
in what I described as Window B above (this is the tree of accounts).
Thinking this might be due to the use of the scrolling window and perhaps
the presence/absence of vertical scrollbars, I diked out the scrolling
window in the account registers; just assigned the view directly to the
window. No change in behavior. Didn't matter.

Again, I have working C version of this application that I began developing
in the summer of 2012 and which I've been using to manage my own finances
for about a year. I've become very interested in Haskell and have done a
few smaller applications in the language with very good results. My thought
was to re-implement the finance application in Haskell, because C is so
much more difficult to write and to read. I'm happy with the user-interface
I've implemented in C and I'm attempting to duplicate it in the Haskell
version. I am also satisfied with the architecture of gtk objects that I
chose in the C version and am replicating it in Haskell. So the Haskell
version does not differ much from the C version in terms of the overall
plan. And none of these issues with popups exist in the C version; it works
correctly. So at least given what I know now, this appears to be a gtk2hs
problem. Could be pilot error, too, but I haven't found it yet. I will keep
working on this as time permits and will share what I learn.

>
>> The minimal framework I could put around your code to make it run is
>> included below. It does not have the problem you describe. Does the code
>> below show the bad behavior you describe when you try it? If not, could
>> you please try to cook up the smallest piece of code that *does*
>> reproduce your problem?
>>
>> ~d
>>
>> import Control.Monad.IO.Class
>> import Graphics.UI.Gtk
>>
>> main = do
>>         initGUI
>>         w <- windowNew
>>         b <- buttonNewWithLabel "foo"
>>         on b buttonPressEvent (tryEvent (do button <- eventButton
>>                                             theTime <- eventTime
>>                                             case button of
>>                                                 RightButton -> liftIO
>> (mouseButtonPressed theTime)
>>                                                 _ -> stopEvent))
>>         containerAdd w b
>>         widgetShowAll w
>>         mainGUI
>>
>> mouseButtonPressed :: TimeStamp -> IO ()
>> mouseButtonPressed theTime
>>     = do menu <- menuNew
>>          print "mouseButtonPressed called"
>>          print ("time", theTime)
>>          menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
>>          on menuItem menuItemActivated (putStrLn "activated, lol")
>>          menuShellAppend menu menuItem
>>          menuItem <- menuItemNewWithLabel "Duplicate selected transaction
>> (ctrl-d)"
>>          menuShellAppend menu menuItem
>>          widgetShowAll menu
>>          print "about to call menuPopup"
>>          menuPopup menu (Just (RightButton, theTime))
>>
>> On 2014-02-18 20:17, Donald Allen wrote:
>>
>> > I am trying to pop up a menu when the right button is pressed with the
>> > cursor in a particular treeview. I set up the event handler as follows:
>> >
>> > -- Handle buttonPressEvent within the view
>> > on view buttonPressEvent (tryEvent (do button <- eventButton
>> > theTime <- eventTime
>> > case button of
>> > RightButton -> liftIO (mouseButtonPressed theTime accountRegister
>> > globals)
>> > _ -> stopEvent))
>> >
>> > and
>> >
>> > mouseButtonPressed :: TimeStamp -> AccountRegister -> Globals -> IO ()
>> > mouseButtonPressed theTime accountRegister globals
>> > = do menu <- menuNew
>> > print "mouseButtonPressed called"
>> > print ("time", theTime)
>> > menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
>> > on menuItem menuItemActivated (newTransaction accountRegister globals)
>> > menuShellAppend menu menuItem
>> > menuItem <- menuItemNewWithLabel "Duplicate selected transaction
>> > (ctrl-d)"
>> > menuShellAppend menu menuItem
>> > widgetShowAll menu
>> > print "about to call menuPopup"
>> > menuPopup menu (Just (RightButton, theTime))
>> >
>> > The first time I press the right button, the menu appears for perhaps
>> > 10 seconds and then disappears. During that time, I can click 'New
>> > transaction' and the right thing happens. The second time I press the
>> > right button, the menu appears very briefly, less than a second and
>> > then disappears. Subsequent right clicks behave the same. In other
>> > words, useless.
>> >
>> > The debugging prints in mouseButtonPressed all appear in response to
>> > the right clicks. The event time advances, as you would expect.
>> >
>> > I'm at a complete loss as to what might be causing this and can't
>> > continue with my project if this is not solved. Any suggestions would
>> > be appreciated.
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Managing the Performance of Cloud-Based Applications
>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> > Read the Whitepaper.
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> > [1]
>> >
>> > _______________________________________________
>> > Gtk2hs-devel mailing list
>> > Gtk...@li...
>> > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel [2]
>>
>>
>>
>> Links:
>> ------
>> [1]
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&amp;iu=/4140/ostg.clktrk<http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk>
>> [2] https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Gtk2hs-devel mailing list
>> Gtk...@li...
>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>>
>
>

On Thu, Feb 20, 2014 at 2:55 PM, Daniel Wagner <da...@wa...>wrote:

> Man, you have *got* to get into the habit of creating a minimal working
> example. =)
>

Yeah, I know. I only had a 45 year career in computer science, running
software projects large and small (including the Tenex project at BBN when
Tenex was the predominant host OS on the ArpaNet), wrote my first computer
program in 1960 (IBM 1620 assembly code), so I'm still a newbie, still
learning, but I'm trying.

Seriously, I did attempt to reproduce the problem with a small example and
got the same result you did -- the popup menu works correctly (our examples
were almost identical, but I did try yours to be sure and it works
correctly as it did for you). I have not been able to devote time to this
since I sent my message, but returned to it yesterday, trying to find the
difference between what my application is doing and both our small
examples. This resulted in a useful bit of information: my application has
another window, call it Window B, that also needs a popup, which I hadn't
gotten to. I adapted the little snippet of code from the failing window
(Window A) to produce a right-button popup in Window B. This one works
correctly.

Window A: a window containing a scrolled window containing a treeview. The
treeview's model is a TreeModelSort whose child model is a ListStore. The
popup fails in this window as described.
Window B: a window containing a scrolled window containing a treeview. The
treeview's model is a TreeStore. The popup works correctly with this window.

So I'm a bit closer to isolating what's going on here, but I'm not there
yet.

>
> The minimal framework I could put around your code to make it run is
> included below. It does not have the problem you describe. Does the code
> below show the bad behavior you describe when you try it? If not, could
> you please try to cook up the smallest piece of code that *does*
> reproduce your problem?
>
> ~d
>
> import Control.Monad.IO.Class
> import Graphics.UI.Gtk
>
> main = do
>         initGUI
>         w <- windowNew
>         b <- buttonNewWithLabel "foo"
>         on b buttonPressEvent (tryEvent (do button <- eventButton
>                                             theTime <- eventTime
>                                             case button of
>                                                 RightButton -> liftIO
> (mouseButtonPressed theTime)
>                                                 _ -> stopEvent))
>         containerAdd w b
>         widgetShowAll w
>         mainGUI
>
> mouseButtonPressed :: TimeStamp -> IO ()
> mouseButtonPressed theTime
>     = do menu <- menuNew
>          print "mouseButtonPressed called"
>          print ("time", theTime)
>          menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
>          on menuItem menuItemActivated (putStrLn "activated, lol")
>          menuShellAppend menu menuItem
>          menuItem <- menuItemNewWithLabel "Duplicate selected transaction
> (ctrl-d)"
>          menuShellAppend menu menuItem
>          widgetShowAll menu
>          print "about to call menuPopup"
>          menuPopup menu (Just (RightButton, theTime))
>
> On 2014-02-18 20:17, Donald Allen wrote:
>
> > I am trying to pop up a menu when the right button is pressed with the
> > cursor in a particular treeview. I set up the event handler as follows:
> >
> > -- Handle buttonPressEvent within the view
> > on view buttonPressEvent (tryEvent (do button <- eventButton
> > theTime <- eventTime
> > case button of
> > RightButton -> liftIO (mouseButtonPressed theTime accountRegister
> > globals)
> > _ -> stopEvent))
> >
> > and
> >
> > mouseButtonPressed :: TimeStamp -> AccountRegister -> Globals -> IO ()
> > mouseButtonPressed theTime accountRegister globals
> > = do menu <- menuNew
> > print "mouseButtonPressed called"
> > print ("time", theTime)
> > menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
> > on menuItem menuItemActivated (newTransaction accountRegister globals)
> > menuShellAppend menu menuItem
> > menuItem <- menuItemNewWithLabel "Duplicate selected transaction
> > (ctrl-d)"
> > menuShellAppend menu menuItem
> > widgetShowAll menu
> > print "about to call menuPopup"
> > menuPopup menu (Just (RightButton, theTime))
> >
> > The first time I press the right button, the menu appears for perhaps
> > 10 seconds and then disappears. During that time, I can click 'New
> > transaction' and the right thing happens. The second time I press the
> > right button, the menu appears very briefly, less than a second and
> > then disappears. Subsequent right clicks behave the same. In other
> > words, useless.
> >
> > The debugging prints in mouseButtonPressed all appear in response to
> > the right clicks. The event time advances, as you would expect.
> >
> > I'm at a complete loss as to what might be causing this and can't
> > continue with my project if this is not solved. Any suggestions would
> > be appreciated.
> >
> >
> ------------------------------------------------------------------------------
> > Managing the Performance of Cloud-Based Applications
> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > Read the Whitepaper.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> > [1]
> >
> > _______________________________________________
> > Gtk2hs-devel mailing list
> > Gtk...@li...
> > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel [2]
>
>
>
> Links:
> ------
> [1]
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&amp;iu=/4140/ostg.clktrk
> [2] https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Gtk2hs-devel mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>

Man, you have *got* to get into the habit of creating a minimal working 
example. =)

The minimal framework I could put around your code to make it run is 
included below. It does not have the problem you describe. Does the code 
below show the bad behavior you describe when you try it? If not, could 
you please try to cook up the smallest piece of code that *does* 
reproduce your problem?

~d

import Control.Monad.IO.Class
import Graphics.UI.Gtk

main = do
	initGUI
	w <- windowNew
	b <- buttonNewWithLabel "foo"
	on b buttonPressEvent (tryEvent (do button <- eventButton
	                                    theTime <- eventTime
	                                    case button of
	                                    	RightButton -> liftIO 
(mouseButtonPressed theTime)
	                                    	_ -> stopEvent))
	containerAdd w b
	widgetShowAll w
	mainGUI

mouseButtonPressed :: TimeStamp -> IO ()
mouseButtonPressed theTime
    = do menu <- menuNew
         print "mouseButtonPressed called"
         print ("time", theTime)
         menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
         on menuItem menuItemActivated (putStrLn "activated, lol")
         menuShellAppend menu menuItem
         menuItem <- menuItemNewWithLabel "Duplicate selected transaction 
(ctrl-d)"
         menuShellAppend menu menuItem
         widgetShowAll menu
         print "about to call menuPopup"
         menuPopup menu (Just (RightButton, theTime))

On 2014-02-18 20:17, Donald Allen wrote:

> I am trying to pop up a menu when the right button is pressed with the 
> cursor in a particular treeview. I set up the event handler as follows:
> 
> -- Handle buttonPressEvent within the view
> on view buttonPressEvent (tryEvent (do button <- eventButton
> theTime <- eventTime
> case button of
> RightButton -> liftIO (mouseButtonPressed theTime accountRegister 
> globals)
> _ -> stopEvent))
> 
> and
> 
> mouseButtonPressed :: TimeStamp -> AccountRegister -> Globals -> IO ()
> mouseButtonPressed theTime accountRegister globals
> = do menu <- menuNew
> print "mouseButtonPressed called"
> print ("time", theTime)
> menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
> on menuItem menuItemActivated (newTransaction accountRegister globals)
> menuShellAppend menu menuItem
> menuItem <- menuItemNewWithLabel "Duplicate selected transaction 
> (ctrl-d)"
> menuShellAppend menu menuItem
> widgetShowAll menu
> print "about to call menuPopup"
> menuPopup menu (Just (RightButton, theTime))
> 
> The first time I press the right button, the menu appears for perhaps 
> 10 seconds and then disappears. During that time, I can click 'New 
> transaction' and the right thing happens. The second time I press the 
> right button, the menu appears very briefly, less than a second and 
> then disappears. Subsequent right clicks behave the same. In other 
> words, useless.
> 
> The debugging prints in mouseButtonPressed all appear in response to 
> the right clicks. The event time advances, as you would expect.
> 
> I'm at a complete loss as to what might be causing this and can't 
> continue with my project if this is not solved. Any suggestions would 
> be appreciated.
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk 
> [1]
> 
> _______________________________________________
> Gtk2hs-devel mailing list
> Gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel [2]



Links:
------
[1] 
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&amp;iu=/4140/ostg.clktrk
[2] https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel

I am trying to pop up a menu when the right button is pressed with the
cursor in a particular treeview. I set up the event handler as follows:

-- Handle buttonPressEvent within the view
on view buttonPressEvent (tryEvent (do button <- eventButton
                                       theTime <- eventTime
                                       case button of
                                          RightButton -> liftIO
(mouseButtonPressed theTime accountRegister globals)
                                          _ -> stopEvent))

and

mouseButtonPressed :: TimeStamp -> AccountRegister -> Globals -> IO ()
mouseButtonPressed theTime accountRegister globals
   = do menu <- menuNew
        print "mouseButtonPressed called"
        print ("time", theTime)
        menuItem <- menuItemNewWithLabel "New transaction (ctrl-n)"
        on menuItem menuItemActivated (newTransaction accountRegister
globals)
        menuShellAppend menu menuItem
        menuItem <- menuItemNewWithLabel "Duplicate selected transaction
(ctrl-d)"
        menuShellAppend menu menuItem
        widgetShowAll menu
        print "about to call menuPopup"
        menuPopup menu (Just (RightButton, theTime))

The first time I press the right button, the menu appears for perhaps 10
seconds and then disappears. During that time, I can click 'New
transaction' and the right thing happens. The second time I press the right
button, the menu appears very briefly, less than a second and then
disappears. Subsequent right clicks behave the same. In other words,
useless.

The debugging prints in mouseButtonPressed all appear in response to the
right clicks. The event time advances, as you would expect.

I'm at a complete loss as to what might be causing this and can't continue
with my project if this is not solved. Any suggestions would be appreciated.

On Mon, Feb 17, 2014 at 8:19 AM, Axel Simon <Axe...@in...> wrote:
> HI,
>
> On Feb 17, 2014, at 2:12 PM, Donald Allen <don...@gm...> wrote:
>>>
>>> I think your documentation changes apply to both Gtk+ 2.x and Gtk+ 3.x.
>>
>> Not true. For example, on the page describing
>> Graphics.UI.Gtk.Windows.Dialog, it says
>>
>> "Dialog boxes are created with a call to dialogNew or
>> dialogNewWithButtons. dialogNewWithButtons is recommended; it allows
>> you to set the dialog title, some convenient flags, and add simple
>> buttons.
>>
>> If 'dialog' is a newly created dialog, the two primary areas of the
>> window can be accessed using dialogGetUpper and dialogGetActionArea."
>>
>> dialogNewWithButtons doesn't exist in the gtk3 version, nor does
>> dialogGetUpper. I intend to remove the references to both and add a
>> reference to dialogGetContentArea, which is the gtk3 replacement for
>> dialogGetUpper.
>>
>> So please answer my question: do I need to conditionalize my
>> gtk3-specific changes? In other words, are you continuing to try to
>> support both gtk2 and gtk3?
>>
>
> Right. Well, I think for now the answer is "yes". If we abandon support for Gtk+ 2.x then we should do this by going through all the code and remove code between #ifs where the version is below 3. As long as this hasn't been done (and there is no particular advantage to this, except cases like yours where one has to be extra careful about documentation and cross-references), the binding supports Gtk+ 2.x.

And I presume that whatever you use to generate html from the comments
in the code sees the after-pre-processing version of the code? In
other words, conditionalizing the comments will actually affect what
appears on the hackage website?

/Don

HI,

On Feb 17, 2014, at 2:12 PM, Donald Allen <don...@gm...> wrote:
>> 
>> I think your documentation changes apply to both Gtk+ 2.x and Gtk+ 3.x.
> 
> Not true. For example, on the page describing
> Graphics.UI.Gtk.Windows.Dialog, it says
> 
> "Dialog boxes are created with a call to dialogNew or
> dialogNewWithButtons. dialogNewWithButtons is recommended; it allows
> you to set the dialog title, some convenient flags, and add simple
> buttons.
> 
> If 'dialog' is a newly created dialog, the two primary areas of the
> window can be accessed using dialogGetUpper and dialogGetActionArea."
> 
> dialogNewWithButtons doesn't exist in the gtk3 version, nor does
> dialogGetUpper. I intend to remove the references to both and add a
> reference to dialogGetContentArea, which is the gtk3 replacement for
> dialogGetUpper.
> 
> So please answer my question: do I need to conditionalize my
> gtk3-specific changes? In other words, are you continuing to try to
> support both gtk2 and gtk3?
> 

Right. Well, I think for now the answer is "yes". If we abandon support for Gtk+ 2.x then we should do this by going through all the code and remove code between #ifs where the version is below 3. As long as this hasn't been done (and there is no particular advantage to this, except cases like yours where one has to be extra careful about documentation and cross-references), the binding supports Gtk+ 2.x.

Cheers,
Axel


> 
> 
>> 
>> The #ifs should only concern which functions should be built. In very rare cases, the semantics of functions change. The change from "onSignal" to "on signal" has been done a while ago when there was only support for Gtk+ 2.x.
>> 
>> Cheers,
>> Axel
>> 
>>> /Don
>>> 
>>> 
>>> On Fri, Feb 14, 2014 at 7:30 AM, Donald Allen <don...@gm...> wrote:
>>> On Fri, Feb 14, 2014 at 1:52 AM, Axel Simon <Axe...@in...> wrote:
>>>> Hi Donald,
>>>> 
>>>> On Feb 14, 2014, at 4:27 AM, Donald Allen <don...@gm...> wrote:
>>>> 
>>>>> The
>>>>> 
>>>>> http://hackage.haskell.org/package/gtk3-0.12.5.2/docs/Graphics-UI-Gtk-Windows-Dialog.html
>>>>> 
>>>>> is really in tough shape. Among other things:
>>>>> 
>>>>> 1. The references to dialogNewWithButtons and dialogGetUpper are
>>>>> bogus; they don't exist.
>>>>> 2. The advice "A 'modal' dialog (that is, one which freezes the rest
>>>>> of the application from user input), can be created by calling
>>>>> windowSetModal on the dialog." is wrong. You have to set the
>>>>> windowModal attribute of the dialog to True.
>>>>> 
>>>> 
>>>> I think none of the developers would argue against any user saying that the documentation can be improved. I don't even know where dialogGetUpper has gone and if this is due to the Gtk3 transition.
>>>> 
>>>> If you're happy to use git to checkout the sources, then it would be of great help if you correct the details and send in a patch.
>>> 
>>> I've already forked my own repository, to submit a pull request for
>>> deletion of more incorrect assertions, so I'm already set up to make
>>> corrections to the documentation. I will do so as time permits.
>>> 
>>>> 
>>>> The "on signal" vs "onSignal" things is indeed a leftover from when we only had "onSignal". It might be documented where the "on" function is defined. We could add some documentation in a central place, except there is none for signals as Signals.chs is not exported and thus not visible in the documentation.
>>> 
>>> The problem is referring to the "onSignal things", as you put it, as
>>> Signals. Using that terminalology implies that they can be used with
>>> 'on', which is exactly what I tried to do. It took me awhile
>>> (including a look at the sources) to figure out what was going on.
>>> 
>>>> 
>>>> About returning Widget instead of Container: If the C code guarantees that the widget is always a container then we can just bind the function that way and safe the user the hassle. That is probably the case here. The C code often uses the wrong types since the compiler doesn't really care what pointer it is.
>>> 
>>> In C, you must use a cast to add something to the content area if you
>>> want your code to compile without warnings (something I always require
>>> of myself), since gtk_dialog_get_content_area returns a pointer to
>>> widget, not a container (as you would expect). I think this is a
>>> mistake in gtk. Because of this, gtk2hs was forced to do the same
>>> thing and the casting function you provide works, once you figure out
>>> what to do. Again, the documentation is an issue. If someone is going
>>> to use a dialog, she is going to have to put something in the content
>>> area, yes? Kind of a fundamental operation that ought to be
>>> prominently addressed in the documentation, especially since it's far
>>> from obvious how to do it, and right now there's nothing. I will fix
>>> this, to hopefully avoid having someone else waste the time I did
>>> yesterday wrestling with this.
>>> 
>>> /Don
>>> 
>>>> 
>>>> Cheers,
>>>> Axel
>>>> 
>>>>> On Thu, Feb 13, 2014 at 9:52 PM, Donald Allen <don...@gm...> wrote:
>>>>>> On Thu, Feb 13, 2014 at 1:40 PM, Donald Allen <don...@gm...> wrote:
>>>>>>> Graphics.UI.Gtk.Windows.Dialog
>>>>>>> 
>>>>>>> The documentation says "the two primary areas of the window can be
>>>>>>> accessed using dialogGetUpper and dialogGetActionArea." There is no
>>>>>>> dialogGetUpper. Is it now dialogGetContentArea?
>>>>>>> 
>>>>>>> The documentation says "The top section is a VBox,". If dialogGetUpper
>>>>>>> has been replaced by dialogGetContentArea, the latter returns an IO
>>>>>>> Widget, not a Vbox and Widget is not in the ContainerClass. So how do
>>>>>>> put something in the content area? In the C version of my project,
>>>>>>> which of course uses gtk3 directly, I simply do a gtk_container_add to
>>>>>>> the content area of the dialog. Works fine. The Haskell compiler won't
>>>>>>> allow this, because, as I said above, Widget is not in the
>>>>>>> ContainerClass, so I can't do a containerAdd. Can someone enlighten me
>>>>>>> as to how one adds, say, a calendar, to the container area of a
>>>>>>> dialog?
>>>>>> 
>>>>>> I took a more careful look at my C code that pops up a calendar in a
>>>>>> dialog, as well as looking at the relevant gtk3 routines and saw the
>>>>>> light. First of all, gtk_dialog_get_content_area returns a pointer to
>>>>>> a GtkWidget. The gtk2hs equivalent does the analogous thing. I made
>>>>>> gtk_container_add compile without complaint by using a GTK_CONTAINER
>>>>>> cast. gtk2hs offers something analogous -- castToContainer. Using the
>>>>>> latter, the Haskell code now compiles and the dialog with embedded
>>>>>> calendar now appears.
>>>>>> 
>>>>>> I still think there are documentation issues here that contributed to
>>>>>> my confusion. I'm guessing that the gtk3 support is a work-in-progress
>>>>>> and that the documentation is in a similar state of transition. If my
>>>>>> guess is right, then I'm grateful for the gtk3 support that exists and
>>>>>> looking forward to this being a more finished product. But if I'm
>>>>>> wrong and the thought is that this is finished, then I would argue
>>>>>> that it isn't, certainly not in the documentation department.
>>>>>> 
>>>>>>> 
>>>>>>> Graphics.UI.Gtk.Misc.Calendar
>>>>>>> 
>>>>>>> In the Signals section, we have
>>>>>>> 
>>>>>>> onDaySelected :: CalendarClass self => self -> IO () -> IO (ConnectId self)
>>>>>>> 
>>>>>>> This is a function, not a signal. It cannot be used with 'on'. I
>>>>>>> suspect what is going on here is that a change has been made from
>>>>>>> functions like this, with the signal name embedded in the function, to
>>>>>>> use of 'on', which takes a signal as an argument. The latter makes
>>>>>>> much more sense to me, a better design, in my opinion. But it looks
>>>>>>> like the transition is only partly done. If I'm right about this, it
>>>>>>> would really be helpful to warn users of this, and refer them to
>>>>>>> documentation for how to use the old-style and new-style signal
>>>>>>> connection. Perhaps I missed it, but I've found nothing in the
>>>>>>> documentation that says anything about this. Or perhaps I've got this
>>>>>>> wrong, in which case I'd appreciate an explanation.
>>>>>>> 
>>>>>>> /Don Allen
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> Android apps run on BlackBerry 10
>>>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>>>> Get your Android app in front of a whole new audience.  Start now.
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Gtk2hs-devel mailing list
>>>>> Gtk...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>>>> 
>>> 
>> 

On Mon, Feb 17, 2014 at 1:48 AM, Axel Simon <Axe...@in...> wrote:
>
> Hi Don,
>
> On Feb 16, 2014, at 5:06 PM, Donald Allen <don...@gm...> wrote:
>
> > Question regarding my making changes  to documentation:
> >
> > It appears that the web pages found on hackage.haskell.org are generated from comments in the source code. The source code is full of #ifs on the gtk version, so it appears that at least at present, you are trying to support gtk2 and gtk3 with variations of the same code. My interest is solely in gtk3 and the documentation changes I wish to make apply only to it. Have I got this right and therefore I need to make my documentation changes conditional on gtk3?
> >
>
> I think your documentation changes apply to both Gtk+ 2.x and Gtk+ 3.x.

Not true. For example, on the page describing
Graphics.UI.Gtk.Windows.Dialog, it says

"Dialog boxes are created with a call to dialogNew or
dialogNewWithButtons. dialogNewWithButtons is recommended; it allows
you to set the dialog title, some convenient flags, and add simple
buttons.

If 'dialog' is a newly created dialog, the two primary areas of the
window can be accessed using dialogGetUpper and dialogGetActionArea."

dialogNewWithButtons doesn't exist in the gtk3 version, nor does
dialogGetUpper. I intend to remove the references to both and add a
reference to dialogGetContentArea, which is the gtk3 replacement for
dialogGetUpper.

So please answer my question: do I need to conditionalize my
gtk3-specific changes? In other words, are you continuing to try to
support both gtk2 and gtk3?



>
> The #ifs should only concern which functions should be built. In very rare cases, the semantics of functions change. The change from "onSignal" to "on signal" has been done a while ago when there was only support for Gtk+ 2.x.
>
> Cheers,
> Axel
>
> > /Don
> >
> >
> > On Fri, Feb 14, 2014 at 7:30 AM, Donald Allen <don...@gm...> wrote:
> > On Fri, Feb 14, 2014 at 1:52 AM, Axel Simon <Axe...@in...> wrote:
> > > Hi Donald,
> > >
> > > On Feb 14, 2014, at 4:27 AM, Donald Allen <don...@gm...> wrote:
> > >
> > >> The
> > >>
> > >> http://hackage.haskell.org/package/gtk3-0.12.5.2/docs/Graphics-UI-Gtk-Windows-Dialog.html
> > >>
> > >> is really in tough shape. Among other things:
> > >>
> > >> 1. The references to dialogNewWithButtons and dialogGetUpper are
> > >> bogus; they don't exist.
> > >> 2. The advice "A 'modal' dialog (that is, one which freezes the rest
> > >> of the application from user input), can be created by calling
> > >> windowSetModal on the dialog." is wrong. You have to set the
> > >> windowModal attribute of the dialog to True.
> > >>
> > >
> > > I think none of the developers would argue against any user saying that the documentation can be improved. I don't even know where dialogGetUpper has gone and if this is due to the Gtk3 transition.
> > >
> > > If you're happy to use git to checkout the sources, then it would be of great help if you correct the details and send in a patch.
> >
> > I've already forked my own repository, to submit a pull request for
> > deletion of more incorrect assertions, so I'm already set up to make
> > corrections to the documentation. I will do so as time permits.
> >
> > >
> > > The "on signal" vs "onSignal" things is indeed a leftover from when we only had "onSignal". It might be documented where the "on" function is defined. We could add some documentation in a central place, except there is none for signals as Signals.chs is not exported and thus not visible in the documentation.
> >
> > The problem is referring to the "onSignal things", as you put it, as
> > Signals. Using that terminalology implies that they can be used with
> > 'on', which is exactly what I tried to do. It took me awhile
> > (including a look at the sources) to figure out what was going on.
> >
> > >
> > > About returning Widget instead of Container: If the C code guarantees that the widget is always a container then we can just bind the function that way and safe the user the hassle. That is probably the case here. The C code often uses the wrong types since the compiler doesn't really care what pointer it is.
> >
> > In C, you must use a cast to add something to the content area if you
> > want your code to compile without warnings (something I always require
> > of myself), since gtk_dialog_get_content_area returns a pointer to
> > widget, not a container (as you would expect). I think this is a
> > mistake in gtk. Because of this, gtk2hs was forced to do the same
> > thing and the casting function you provide works, once you figure out
> > what to do. Again, the documentation is an issue. If someone is going
> > to use a dialog, she is going to have to put something in the content
> > area, yes? Kind of a fundamental operation that ought to be
> > prominently addressed in the documentation, especially since it's far
> > from obvious how to do it, and right now there's nothing. I will fix
> > this, to hopefully avoid having someone else waste the time I did
> > yesterday wrestling with this.
> >
> > /Don
> >
> > >
> > > Cheers,
> > > Axel
> > >
> > >> On Thu, Feb 13, 2014 at 9:52 PM, Donald Allen <don...@gm...> wrote:
> > >>> On Thu, Feb 13, 2014 at 1:40 PM, Donald Allen <don...@gm...> wrote:
> > >>>> Graphics.UI.Gtk.Windows.Dialog
> > >>>>
> > >>>> The documentation says "the two primary areas of the window can be
> > >>>> accessed using dialogGetUpper and dialogGetActionArea." There is no
> > >>>> dialogGetUpper. Is it now dialogGetContentArea?
> > >>>>
> > >>>> The documentation says "The top section is a VBox,". If dialogGetUpper
> > >>>> has been replaced by dialogGetContentArea, the latter returns an IO
> > >>>> Widget, not a Vbox and Widget is not in the ContainerClass. So how do
> > >>>> put something in the content area? In the C version of my project,
> > >>>> which of course uses gtk3 directly, I simply do a gtk_container_add to
> > >>>> the content area of the dialog. Works fine. The Haskell compiler won't
> > >>>> allow this, because, as I said above, Widget is not in the
> > >>>> ContainerClass, so I can't do a containerAdd. Can someone enlighten me
> > >>>> as to how one adds, say, a calendar, to the container area of a
> > >>>> dialog?
> > >>>
> > >>> I took a more careful look at my C code that pops up a calendar in a
> > >>> dialog, as well as looking at the relevant gtk3 routines and saw the
> > >>> light. First of all, gtk_dialog_get_content_area returns a pointer to
> > >>> a GtkWidget. The gtk2hs equivalent does the analogous thing. I made
> > >>> gtk_container_add compile without complaint by using a GTK_CONTAINER
> > >>> cast. gtk2hs offers something analogous -- castToContainer. Using the
> > >>> latter, the Haskell code now compiles and the dialog with embedded
> > >>> calendar now appears.
> > >>>
> > >>> I still think there are documentation issues here that contributed to
> > >>> my confusion. I'm guessing that the gtk3 support is a work-in-progress
> > >>> and that the documentation is in a similar state of transition. If my
> > >>> guess is right, then I'm grateful for the gtk3 support that exists and
> > >>> looking forward to this being a more finished product. But if I'm
> > >>> wrong and the thought is that this is finished, then I would argue
> > >>> that it isn't, certainly not in the documentation department.
> > >>>
> > >>>>
> > >>>> Graphics.UI.Gtk.Misc.Calendar
> > >>>>
> > >>>> In the Signals section, we have
> > >>>>
> > >>>> onDaySelected :: CalendarClass self => self -> IO () -> IO (ConnectId self)
> > >>>>
> > >>>> This is a function, not a signal. It cannot be used with 'on'. I
> > >>>> suspect what is going on here is that a change has been made from
> > >>>> functions like this, with the signal name embedded in the function, to
> > >>>> use of 'on', which takes a signal as an argument. The latter makes
> > >>>> much more sense to me, a better design, in my opinion. But it looks
> > >>>> like the transition is only partly done. If I'm right about this, it
> > >>>> would really be helpful to warn users of this, and refer them to
> > >>>> documentation for how to use the old-style and new-style signal
> > >>>> connection. Perhaps I missed it, but I've found nothing in the
> > >>>> documentation that says anything about this. Or perhaps I've got this
> > >>>> wrong, in which case I'd appreciate an explanation.
> > >>>>
> > >>>> /Don Allen
> > >>
> > >> ------------------------------------------------------------------------------
> > >> Android apps run on BlackBerry 10
> > >> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> > >> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> > >> Get your Android app in front of a whole new audience.  Start now.
> > >> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> > >> _______________________________________________
> > >> Gtk2hs-devel mailing list
> > >> Gtk...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
> > >
> >
>

Hi Don,

On Feb 16, 2014, at 5:06 PM, Donald Allen <don...@gm...> wrote:

> Question regarding my making changes  to documentation:
> 
> It appears that the web pages found on hackage.haskell.org are generated from comments in the source code. The source code is full of #ifs on the gtk version, so it appears that at least at present, you are trying to support gtk2 and gtk3 with variations of the same code. My interest is solely in gtk3 and the documentation changes I wish to make apply only to it. Have I got this right and therefore I need to make my documentation changes conditional on gtk3?
> 

I think your documentation changes apply to both Gtk+ 2.x and Gtk+ 3.x. The #ifs should only concern which functions should be built. In very rare cases, the semantics of functions change. The change from "onSignal" to "on signal" has been done a while ago when there was only support for Gtk+ 2.x.

Cheers,
Axel

> /Don
> 
> 
> On Fri, Feb 14, 2014 at 7:30 AM, Donald Allen <don...@gm...> wrote:
> On Fri, Feb 14, 2014 at 1:52 AM, Axel Simon <Axe...@in...> wrote:
> > Hi Donald,
> >
> > On Feb 14, 2014, at 4:27 AM, Donald Allen <don...@gm...> wrote:
> >
> >> The
> >>
> >> http://hackage.haskell.org/package/gtk3-0.12.5.2/docs/Graphics-UI-Gtk-Windows-Dialog.html
> >>
> >> is really in tough shape. Among other things:
> >>
> >> 1. The references to dialogNewWithButtons and dialogGetUpper are
> >> bogus; they don't exist.
> >> 2. The advice "A 'modal' dialog (that is, one which freezes the rest
> >> of the application from user input), can be created by calling
> >> windowSetModal on the dialog." is wrong. You have to set the
> >> windowModal attribute of the dialog to True.
> >>
> >
> > I think none of the developers would argue against any user saying that the documentation can be improved. I don't even know where dialogGetUpper has gone and if this is due to the Gtk3 transition.
> >
> > If you're happy to use git to checkout the sources, then it would be of great help if you correct the details and send in a patch.
> 
> I've already forked my own repository, to submit a pull request for
> deletion of more incorrect assertions, so I'm already set up to make
> corrections to the documentation. I will do so as time permits.
> 
> >
> > The "on signal" vs "onSignal" things is indeed a leftover from when we only had "onSignal". It might be documented where the "on" function is defined. We could add some documentation in a central place, except there is none for signals as Signals.chs is not exported and thus not visible in the documentation.
> 
> The problem is referring to the "onSignal things", as you put it, as
> Signals. Using that terminalology implies that they can be used with
> 'on', which is exactly what I tried to do. It took me awhile
> (including a look at the sources) to figure out what was going on.
> 
> >
> > About returning Widget instead of Container: If the C code guarantees that the widget is always a container then we can just bind the function that way and safe the user the hassle. That is probably the case here. The C code often uses the wrong types since the compiler doesn't really care what pointer it is.
> 
> In C, you must use a cast to add something to the content area if you
> want your code to compile without warnings (something I always require
> of myself), since gtk_dialog_get_content_area returns a pointer to
> widget, not a container (as you would expect). I think this is a
> mistake in gtk. Because of this, gtk2hs was forced to do the same
> thing and the casting function you provide works, once you figure out
> what to do. Again, the documentation is an issue. If someone is going
> to use a dialog, she is going to have to put something in the content
> area, yes? Kind of a fundamental operation that ought to be
> prominently addressed in the documentation, especially since it's far
> from obvious how to do it, and right now there's nothing. I will fix
> this, to hopefully avoid having someone else waste the time I did
> yesterday wrestling with this.
> 
> /Don
> 
> >
> > Cheers,
> > Axel
> >
> >> On Thu, Feb 13, 2014 at 9:52 PM, Donald Allen <don...@gm...> wrote:
> >>> On Thu, Feb 13, 2014 at 1:40 PM, Donald Allen <don...@gm...> wrote:
> >>>> Graphics.UI.Gtk.Windows.Dialog
> >>>>
> >>>> The documentation says "the two primary areas of the window can be
> >>>> accessed using dialogGetUpper and dialogGetActionArea." There is no
> >>>> dialogGetUpper. Is it now dialogGetContentArea?
> >>>>
> >>>> The documentation says "The top section is a VBox,". If dialogGetUpper
> >>>> has been replaced by dialogGetContentArea, the latter returns an IO
> >>>> Widget, not a Vbox and Widget is not in the ContainerClass. So how do
> >>>> put something in the content area? In the C version of my project,
> >>>> which of course uses gtk3 directly, I simply do a gtk_container_add to
> >>>> the content area of the dialog. Works fine. The Haskell compiler won't
> >>>> allow this, because, as I said above, Widget is not in the
> >>>> ContainerClass, so I can't do a containerAdd. Can someone enlighten me
> >>>> as to how one adds, say, a calendar, to the container area of a
> >>>> dialog?
> >>>
> >>> I took a more careful look at my C code that pops up a calendar in a
> >>> dialog, as well as looking at the relevant gtk3 routines and saw the
> >>> light. First of all, gtk_dialog_get_content_area returns a pointer to
> >>> a GtkWidget. The gtk2hs equivalent does the analogous thing. I made
> >>> gtk_container_add compile without complaint by using a GTK_CONTAINER
> >>> cast. gtk2hs offers something analogous -- castToContainer. Using the
> >>> latter, the Haskell code now compiles and the dialog with embedded
> >>> calendar now appears.
> >>>
> >>> I still think there are documentation issues here that contributed to
> >>> my confusion. I'm guessing that the gtk3 support is a work-in-progress
> >>> and that the documentation is in a similar state of transition. If my
> >>> guess is right, then I'm grateful for the gtk3 support that exists and
> >>> looking forward to this being a more finished product. But if I'm
> >>> wrong and the thought is that this is finished, then I would argue
> >>> that it isn't, certainly not in the documentation department.
> >>>
> >>>>
> >>>> Graphics.UI.Gtk.Misc.Calendar
> >>>>
> >>>> In the Signals section, we have
> >>>>
> >>>> onDaySelected :: CalendarClass self => self -> IO () -> IO (ConnectId self)
> >>>>
> >>>> This is a function, not a signal. It cannot be used with 'on'. I
> >>>> suspect what is going on here is that a change has been made from
> >>>> functions like this, with the signal name embedded in the function, to
> >>>> use of 'on', which takes a signal as an argument. The latter makes
> >>>> much more sense to me, a better design, in my opinion. But it looks
> >>>> like the transition is only partly done. If I'm right about this, it
> >>>> would really be helpful to warn users of this, and refer them to
> >>>> documentation for how to use the old-style and new-style signal
> >>>> connection. Perhaps I missed it, but I've found nothing in the
> >>>> documentation that says anything about this. Or perhaps I've got this
> >>>> wrong, in which case I'd appreciate an explanation.
> >>>>
> >>>> /Don Allen
> >>
> >> ------------------------------------------------------------------------------
> >> Android apps run on BlackBerry 10
> >> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> >> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> >> Get your Android app in front of a whole new audience.  Start now.
> >> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Gtk2hs-devel mailing list
> >> Gtk...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
> >
> 

Question regarding my making changes  to documentation:

It appears that the web pages found on hackage.haskell.org are generated
from comments in the source code. The source code is full of #ifs on the
gtk version, so it appears that at least at present, you are trying to
support gtk2 and gtk3 with variations of the same code. My interest is
solely in gtk3 and the documentation changes I wish to make apply only to
it. Have I got this right and therefore I need to make my documentation
changes conditional on gtk3?

/Don


On Fri, Feb 14, 2014 at 7:30 AM, Donald Allen <don...@gm...>wrote:

> On Fri, Feb 14, 2014 at 1:52 AM, Axel Simon <Axe...@in...> wrote:
> > Hi Donald,
> >
> > On Feb 14, 2014, at 4:27 AM, Donald Allen <don...@gm...>
> wrote:
> >
> >> The
> >>
> >>
> http://hackage.haskell.org/package/gtk3-0.12.5.2/docs/Graphics-UI-Gtk-Windows-Dialog.html
> >>
> >> is really in tough shape. Among other things:
> >>
> >> 1. The references to dialogNewWithButtons and dialogGetUpper are
> >> bogus; they don't exist.
> >> 2. The advice "A 'modal' dialog (that is, one which freezes the rest
> >> of the application from user input), can be created by calling
> >> windowSetModal on the dialog." is wrong. You have to set the
> >> windowModal attribute of the dialog to True.
> >>
> >
> > I think none of the developers would argue against any user saying that
> the documentation can be improved. I don't even know where dialogGetUpper
> has gone and if this is due to the Gtk3 transition.
> >
> > If you're happy to use git to checkout the sources, then it would be of
> great help if you correct the details and send in a patch.
>
> I've already forked my own repository, to submit a pull request for
> deletion of more incorrect assertions, so I'm already set up to make
> corrections to the documentation. I will do so as time permits.
>
> >
> > The "on signal" vs "onSignal" things is indeed a leftover from when we
> only had "onSignal". It might be documented where the "on" function is
> defined. We could add some documentation in a central place, except there
> is none for signals as Signals.chs is not exported and thus not visible in
> the documentation.
>
> The problem is referring to the "onSignal things", as you put it, as
> Signals. Using that terminalology implies that they can be used with
> 'on', which is exactly what I tried to do. It took me awhile
> (including a look at the sources) to figure out what was going on.
>
> >
> > About returning Widget instead of Container: If the C code guarantees
> that the widget is always a container then we can just bind the function
> that way and safe the user the hassle. That is probably the case here. The
> C code often uses the wrong types since the compiler doesn't really care
> what pointer it is.
>
> In C, you must use a cast to add something to the content area if you
> want your code to compile without warnings (something I always require
> of myself), since gtk_dialog_get_content_area returns a pointer to
> widget, not a container (as you would expect). I think this is a
> mistake in gtk. Because of this, gtk2hs was forced to do the same
> thing and the casting function you provide works, once you figure out
> what to do. Again, the documentation is an issue. If someone is going
> to use a dialog, she is going to have to put something in the content
> area, yes? Kind of a fundamental operation that ought to be
> prominently addressed in the documentation, especially since it's far
> from obvious how to do it, and right now there's nothing. I will fix
> this, to hopefully avoid having someone else waste the time I did
> yesterday wrestling with this.
>
> /Don
>
> >
> > Cheers,
> > Axel
> >
> >> On Thu, Feb 13, 2014 at 9:52 PM, Donald Allen <don...@gm...>
> wrote:
> >>> On Thu, Feb 13, 2014 at 1:40 PM, Donald Allen <don...@gm...>
> wrote:
> >>>> Graphics.UI.Gtk.Windows.Dialog
> >>>>
> >>>> The documentation says "the two primary areas of the window can be
> >>>> accessed using dialogGetUpper and dialogGetActionArea." There is no
> >>>> dialogGetUpper. Is it now dialogGetContentArea?
> >>>>
> >>>> The documentation says "The top section is a VBox,". If dialogGetUpper
> >>>> has been replaced by dialogGetContentArea, the latter returns an IO
> >>>> Widget, not a Vbox and Widget is not in the ContainerClass. So how do
> >>>> put something in the content area? In the C version of my project,
> >>>> which of course uses gtk3 directly, I simply do a gtk_container_add to
> >>>> the content area of the dialog. Works fine. The Haskell compiler won't
> >>>> allow this, because, as I said above, Widget is not in the
> >>>> ContainerClass, so I can't do a containerAdd. Can someone enlighten me
> >>>> as to how one adds, say, a calendar, to the container area of a
> >>>> dialog?
> >>>
> >>> I took a more careful look at my C code that pops up a calendar in a
> >>> dialog, as well as looking at the relevant gtk3 routines and saw the
> >>> light. First of all, gtk_dialog_get_content_area returns a pointer to
> >>> a GtkWidget. The gtk2hs equivalent does the analogous thing. I made
> >>> gtk_container_add compile without complaint by using a GTK_CONTAINER
> >>> cast. gtk2hs offers something analogous -- castToContainer. Using the
> >>> latter, the Haskell code now compiles and the dialog with embedded
> >>> calendar now appears.
> >>>
> >>> I still think there are documentation issues here that contributed to
> >>> my confusion. I'm guessing that the gtk3 support is a work-in-progress
> >>> and that the documentation is in a similar state of transition. If my
> >>> guess is right, then I'm grateful for the gtk3 support that exists and
> >>> looking forward to this being a more finished product. But if I'm
> >>> wrong and the thought is that this is finished, then I would argue
> >>> that it isn't, certainly not in the documentation department.
> >>>
> >>>>
> >>>> Graphics.UI.Gtk.Misc.Calendar
> >>>>
> >>>> In the Signals section, we have
> >>>>
> >>>> onDaySelected :: CalendarClass self => self -> IO () -> IO (ConnectId
> self)
> >>>>
> >>>> This is a function, not a signal. It cannot be used with 'on'. I
> >>>> suspect what is going on here is that a change has been made from
> >>>> functions like this, with the signal name embedded in the function, to
> >>>> use of 'on', which takes a signal as an argument. The latter makes
> >>>> much more sense to me, a better design, in my opinion. But it looks
> >>>> like the transition is only partly done. If I'm right about this, it
> >>>> would really be helpful to warn users of this, and refer them to
> >>>> documentation for how to use the old-style and new-style signal
> >>>> connection. Perhaps I missed it, but I've found nothing in the
> >>>> documentation that says anything about this. Or perhaps I've got this
> >>>> wrong, in which case I'd appreciate an explanation.
> >>>>
> >>>> /Don Allen
> >>
> >>
> ------------------------------------------------------------------------------
> >> Android apps run on BlackBerry 10
> >> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> >> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> >> Get your Android app in front of a whole new audience.  Start now.
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Gtk2hs-devel mailing list
> >> Gtk...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
> >
>

On Fri, Feb 14, 2014 at 1:52 AM, Axel Simon <Axe...@in...> wrote:
> Hi Donald,
>
> On Feb 14, 2014, at 4:27 AM, Donald Allen <don...@gm...> wrote:
>
>> The
>>
>> http://hackage.haskell.org/package/gtk3-0.12.5.2/docs/Graphics-UI-Gtk-Windows-Dialog.html
>>
>> is really in tough shape. Among other things:
>>
>> 1. The references to dialogNewWithButtons and dialogGetUpper are
>> bogus; they don't exist.
>> 2. The advice "A 'modal' dialog (that is, one which freezes the rest
>> of the application from user input), can be created by calling
>> windowSetModal on the dialog." is wrong. You have to set the
>> windowModal attribute of the dialog to True.
>>
>
> I think none of the developers would argue against any user saying that the documentation can be improved. I don't even know where dialogGetUpper has gone and if this is due to the Gtk3 transition.
>
> If you're happy to use git to checkout the sources, then it would be of great help if you correct the details and send in a patch.

I've already forked my own repository, to submit a pull request for
deletion of more incorrect assertions, so I'm already set up to make
corrections to the documentation. I will do so as time permits.

>
> The "on signal" vs "onSignal" things is indeed a leftover from when we only had "onSignal". It might be documented where the "on" function is defined. We could add some documentation in a central place, except there is none for signals as Signals.chs is not exported and thus not visible in the documentation.

The problem is referring to the "onSignal things", as you put it, as
Signals. Using that terminalology implies that they can be used with
'on', which is exactly what I tried to do. It took me awhile
(including a look at the sources) to figure out what was going on.

>
> About returning Widget instead of Container: If the C code guarantees that the widget is always a container then we can just bind the function that way and safe the user the hassle. That is probably the case here. The C code often uses the wrong types since the compiler doesn't really care what pointer it is.

In C, you must use a cast to add something to the content area if you
want your code to compile without warnings (something I always require
of myself), since gtk_dialog_get_content_area returns a pointer to
widget, not a container (as you would expect). I think this is a
mistake in gtk. Because of this, gtk2hs was forced to do the same
thing and the casting function you provide works, once you figure out
what to do. Again, the documentation is an issue. If someone is going
to use a dialog, she is going to have to put something in the content
area, yes? Kind of a fundamental operation that ought to be
prominently addressed in the documentation, especially since it's far
from obvious how to do it, and right now there's nothing. I will fix
this, to hopefully avoid having someone else waste the time I did
yesterday wrestling with this.

/Don

>
> Cheers,
> Axel
>
>> On Thu, Feb 13, 2014 at 9:52 PM, Donald Allen <don...@gm...> wrote:
>>> On Thu, Feb 13, 2014 at 1:40 PM, Donald Allen <don...@gm...> wrote:
>>>> Graphics.UI.Gtk.Windows.Dialog
>>>>
>>>> The documentation says "the two primary areas of the window can be
>>>> accessed using dialogGetUpper and dialogGetActionArea." There is no
>>>> dialogGetUpper. Is it now dialogGetContentArea?
>>>>
>>>> The documentation says "The top section is a VBox,". If dialogGetUpper
>>>> has been replaced by dialogGetContentArea, the latter returns an IO
>>>> Widget, not a Vbox and Widget is not in the ContainerClass. So how do
>>>> put something in the content area? In the C version of my project,
>>>> which of course uses gtk3 directly, I simply do a gtk_container_add to
>>>> the content area of the dialog. Works fine. The Haskell compiler won't
>>>> allow this, because, as I said above, Widget is not in the
>>>> ContainerClass, so I can't do a containerAdd. Can someone enlighten me
>>>> as to how one adds, say, a calendar, to the container area of a
>>>> dialog?
>>>
>>> I took a more careful look at my C code that pops up a calendar in a
>>> dialog, as well as looking at the relevant gtk3 routines and saw the
>>> light. First of all, gtk_dialog_get_content_area returns a pointer to
>>> a GtkWidget. The gtk2hs equivalent does the analogous thing. I made
>>> gtk_container_add compile without complaint by using a GTK_CONTAINER
>>> cast. gtk2hs offers something analogous -- castToContainer. Using the
>>> latter, the Haskell code now compiles and the dialog with embedded
>>> calendar now appears.
>>>
>>> I still think there are documentation issues here that contributed to
>>> my confusion. I'm guessing that the gtk3 support is a work-in-progress
>>> and that the documentation is in a similar state of transition. If my
>>> guess is right, then I'm grateful for the gtk3 support that exists and
>>> looking forward to this being a more finished product. But if I'm
>>> wrong and the thought is that this is finished, then I would argue
>>> that it isn't, certainly not in the documentation department.
>>>
>>>>
>>>> Graphics.UI.Gtk.Misc.Calendar
>>>>
>>>> In the Signals section, we have
>>>>
>>>> onDaySelected :: CalendarClass self => self -> IO () -> IO (ConnectId self)
>>>>
>>>> This is a function, not a signal. It cannot be used with 'on'. I
>>>> suspect what is going on here is that a change has been made from
>>>> functions like this, with the signal name embedded in the function, to
>>>> use of 'on', which takes a signal as an argument. The latter makes
>>>> much more sense to me, a better design, in my opinion. But it looks
>>>> like the transition is only partly done. If I'm right about this, it
>>>> would really be helpful to warn users of this, and refer them to
>>>> documentation for how to use the old-style and new-style signal
>>>> connection. Perhaps I missed it, but I've found nothing in the
>>>> documentation that says anything about this. Or perhaps I've got this
>>>> wrong, in which case I'd appreciate an explanation.
>>>>
>>>> /Don Allen
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Gtk2hs-devel mailing list
>> Gtk...@li...
>> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
>