From: Henning T. <le...@he...> - 2012-09-24 17:57:15
|
When switching from wxcore-0.13.2 to GIT HEAD from https://github.com/jodonoghue/wxHaskell the TextCtrl does no longer use a monospaced font. This may be caused by the recent patch commented with "Fix for unexpected TextCtrl behaviour on OS X. This is the equivalent of patch f225d0c on master." I create the text field this way: WX.textCtrl panel [ font := fontFixed, wrap := WrapNone ] In the past TextCtrl always used a monospaced font, but when I entered text at the end of a text field it happened sometimes that the font had no longer fixed width characters. This might be a wxwidgets bug or even a gtk bug. However, now the TextCtrl does not use the monospace font anymore. |
From: Heinrich A. <apf...@qu...> - 2012-09-25 08:41:00
|
Henning Thielemann wrote: > When switching from wxcore-0.13.2 to GIT HEAD from > https://github.com/jodonoghue/wxHaskell the TextCtrl does no longer use a > monospaced font. This may be caused by the recent patch commented with > > "Fix for unexpected TextCtrl behaviour on OS X. This is the equivalent > of patch f225d0c on master." > > I create the text field this way: > WX.textCtrl panel [ font := fontFixed, wrap := WrapNone ] > > In the past TextCtrl always used a monospaced font, but when I entered > text at the end of a text field it happened sometimes that the font had no > longer fixed width characters. This might be a wxwidgets bug or even a gtk > bug. However, now the TextCtrl does not use the monospace font anymore. You can use the textCtrlEx function and pass additional style flags to it to create text controls with the old behavior. I think the previous source code was textCtrlEx parent (wxTE_MULTILINE .+. wxTE_RICH2) props Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com |
From: Henning T. <le...@he...> - 2012-09-25 12:41:31
|
On Tue, 25 Sep 2012, Heinrich Apfelmus wrote: > Henning Thielemann wrote: >> When switching from wxcore-0.13.2 to GIT HEAD from >> https://github.com/jodonoghue/wxHaskell the TextCtrl does no longer use a >> monospaced font. This may be caused by the recent patch commented with >> >> "Fix for unexpected TextCtrl behaviour on OS X. This is the equivalent >> of patch f225d0c on master." >> >> I create the text field this way: >> WX.textCtrl panel [ font := fontFixed, wrap := WrapNone ] >> >> In the past TextCtrl always used a monospaced font, but when I entered >> text at the end of a text field it happened sometimes that the font had no >> longer fixed width characters. This might be a wxwidgets bug or even a gtk >> bug. However, now the TextCtrl does not use the monospace font anymore. > > You can use the textCtrlEx function and pass additional style flags to > it to create text controls with the old behavior. I think the previous > source code was > > textCtrlEx parent (wxTE_MULTILINE .+. wxTE_RICH2) props I see. It sounds reasonable, too. Unfortunately switching back to this line does not work. Even if it would, it would bypass the improvement that was introduced with the last patch. There were not many lines that changed, so I tried to revert them one by one and found that this change caused the problem: - (\tc -> (textCtrlGetValue tc, \s -> do textCtrlClear tc; textCtrlWriteText tc s)) $ + (\tc -> (textCtrlGetValue tc, \s -> do textCtrlChangeValue tc s)) $ It may be related to my observation that the textCtrl sometimes chooses a variable-space font if I enter text at the end of a text Ctrl in an otherwise mono-spaced text. That is, it seems to be important _how_ a text is inserted. Maybe this is even a Wx bug? |
From: Heinrich A. <apf...@qu...> - 2012-09-29 08:00:28
|
Henning Thielemann wrote: > Heinrich Apfelmus wrote: > >> You can use the textCtrlEx function and pass additional style flags to >> it to create text controls with the old behavior. I think the previous >> source code was >> >> textCtrlEx parent (wxTE_MULTILINE .+. wxTE_RICH2) props > > I see. It sounds reasonable, too. Unfortunately switching back to this > line does not work. Even if it would, it would bypass the improvement that > was introduced with the last patch. The idea would be to keep the source as it is, but use the textCtrlEx function instead of the ordinary textCtrl function in the cases where you desire a text entry field with a monospace font. > There were not many lines that changed, so I tried to revert them one by > one and found that this change caused the problem: > > - (\tc -> (textCtrlGetValue tc, \s -> do textCtrlClear tc; textCtrlWriteText tc s)) $ > + (\tc -> (textCtrlGetValue tc, \s -> do textCtrlChangeValue tc s)) $ I made this change because the old version actually crashes on MacOS X in some circumstances... > It may be related to my observation that the textCtrl sometimes chooses a > variable-space font if I enter text at the end of a text Ctrl in an > otherwise mono-spaced text. That is, it seems to be important _how_ a text > is inserted. > > Maybe this is even a Wx bug? Most likely. It seems that in order to support monospace font, the text entry control is converted to Rich Text Formatting, and then you have font control commands as part of the input data. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com |
From: Henning T. <le...@he...> - 2012-10-28 20:35:03
|
On Sat, 29 Sep 2012, Heinrich Apfelmus wrote: > Henning Thielemann wrote: > >> It may be related to my observation that the textCtrl sometimes chooses a >> variable-space font if I enter text at the end of a text Ctrl in an >> otherwise mono-spaced text. That is, it seems to be important _how_ a text >> is inserted. >> >> Maybe this is even a Wx bug? > > Most likely. > > It seems that in order to support monospace font, the text entry control > is converted to Rich Text Formatting, and then you have font control > commands as part of the input data. I have added a 'case' that chooses the old code for GTK and apfelmus' one for other systems: http://code.haskell.org/~thielema/wxhaskell/ Can someone check my change on Windows and eventually add the patch to the main repo? Shall this patch be added to the wxwidgets-2.9 branch, too? |