Text cursor movement on Windows
Hi, The GTK cursor movement convention used to move the cursor one word forward (CTRL+Right) differs from what is normal in MS Windows (Wimp-theme does not solve this). The normal behavior in MS Windows is to move to the start of the next word (include the space) and on GTK it only moves to the end of the word. For text editing intensive applications this is an annoyance for experienced users. Does anyone have hints on how to go about make this configurable in a client application or if this needs changes at the GTK core? Regards, Fredrik ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Text cursor movement on Windows
Replying to myself.
I found a semi working solution here:
http://ubuntuforums.org/showpost.php?p=9202312postcount=6
It changes the key binding for forward word using the gtkrc file so
that it generates two move-cursor events:
bind ControlRight { move-cursor (words, 2, 0) move-cursor
(words, -1, 0) }
However that does not work for the last word in the buffer as it in
that case just moves one forward and one back.
After some experimentation I came up with this instead that seem to
work better for my application:
bind ControlRight { move-cursor (words, 1, 0) move-cursor
(logical-positions, 1, 0) }
Obviously this does not jump to the start of the next word if there
are more spaces (or other chracters) than one but that is not so
common in natural language that my application is used for.
The real solution would probably be to create a new move unit (or user
parameter to the word unit) that move to start of next word.
However even if this quick solution is buggy my users seem to prefer
it over the default GTK behavior.
I've attached the gtkrc in case it would be of interest for anyone.
/Fredrik
On Mon, Jul 12, 2010 at 12:11 PM, Fredrik Corneliusson
fredrik.cornelius...@gmail.com wrote:
Hi,
The GTK cursor movement convention used to move the cursor one word
forward (CTRL+Right) differs from what is normal in MS Windows
(Wimp-theme does not solve this).
The normal behavior in MS Windows is to move to the start of the next
word (include the space) and on GTK it only moves to the end of the
word.
For text editing intensive applications this is an annoyance for
experienced users.
Does anyone have hints on how to go about make this configurable in a
client application or if this needs changes at the GTK core?
Regards,
Fredrik
gtkrc
Description: Binary data
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Distinct performance issues with Japanese only on win32 systems
Hi Tor, I managed to create a modified version of the pango_win32_get_hfont function called pango_win32_peek_hfont that do not break the rendering. Patch now uses the hfont script for the script cache mapping. Regards, Fredrik On Mon, Apr 12, 2010 at 4:59 PM, Fredrik Corneliusson fredrik.cornelius...@gmail.com wrote: Hi Tor, I think its pango_win32_get_hfont in pangowin32.c. static HFONT pango_win32_get_hfont (PangoFont *font); I removed the static and defined it as external to be able to call it from basic-win32.c. Unfortunately calling the pango_win32_get_hfont in itemize_shape_and_place function seems to severely break the rendering. I do not understand the code well enough to know if I can get hfont in another way (and when) to not break the rendering. Does anyone have any hints? /Fredrik On Sun, Apr 11, 2010 at 9:36 PM, Tor Lillqvist t...@iki.fi wrote: I am not sure I would trust basing the hash on the pango_font_description_hash() value. I would prefer to use the specific HFONT for each run of glyphs from one physical font. I'm too lazy to look up right now how in the basic-win32.c code one can find that information... --tml pango_win32_uniscribe_patch_hfont-version.diff Description: Binary data ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: Distinct performance issues with Japanese only on win32 systems
Hi Tor, I think its pango_win32_get_hfont in pangowin32.c. static HFONT pango_win32_get_hfont (PangoFont *font); I removed the static and defined it as external to be able to call it from basic-win32.c. Unfortunately calling the pango_win32_get_hfont in itemize_shape_and_place function seems to severely break the rendering. I do not understand the code well enough to know if I can get hfont in another way (and when) to not break the rendering. Does anyone have any hints? /Fredrik On Sun, Apr 11, 2010 at 9:36 PM, Tor Lillqvist t...@iki.fi wrote: I am not sure I would trust basing the hash on the pango_font_description_hash() value. I would prefer to use the specific HFONT for each run of glyphs from one physical font. I'm too lazy to look up right now how in the basic-win32.c code one can find that information... --tml ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: Distinct performance issues with Japanese only on win32 systems
I just saw that I mentioned the wrong Pango version, It's actually a patch for Pango 1.26.2. not 1.16.2. I would like to thank Dave E Hollingsworth for finding and working on this issue in the first place. On Thu, Apr 8, 2010 at 8:17 PM, Fredrik Corneliusson fredrik.cornelius...@gmail.com wrote: Hi, It seems Pango uses the Uniscribe script cache in a sub optimal way. Pango always create new script caches and throws them away in each call to uniscribe_shape. But in the Uniscribe docs it does not say that the cache needs to be cleared between ScriptItemize calls. We did some experiments and made the script cache array static so it's only initialized once and reused in each call. This seems to solve the speed problem (generates a magnitude speedup). Note: I've checked and Arabic (complex script shaping) renders correctly as far as I can see. I've attached a crude patch (Pango version 1.16.2) with this change. Note: this patch probably leaks a bit of memory as the pango uniscribe shape caches are never freed. We need to find out if this is a problem and how it could be solved. Also it does not seem that this performance issue is isolated to Japanese but for other scripts that need uniscribe as well. I think Japanese however suffers more severely as it uses space separators between the characters and that causes shape fragmentation and thus will generate a lot more calls to uniscribe_shape. This will in turn make the caches quite useless. Some other observations made: Reading the uniscribe docs is seems that you should use a separate cache for every font+size combination. However in the pango code it just uses separate cache based on script (the SCRIPT_ANALYSIS.eScript) . I've tried to make it break by changing fonts and size used but I seems to work anyway which is strange (or I probably do not understand the code well enough). Also the array holding the script caches in Pango is static and set to 100 and it's indexed on script. However eScript datatype is a Opaque 10bit value. It seems to been working well so far in Pango but could this be a issue if MS changes the implementation and use values 99? References: http://msdn.microsoft.com/en-us/library/dd368797%28v=VS.85%29.aspx http://msdn.microsoft.com/en-us/library/dd317726%28v=VS.85%29.aspx Regards, Fredrik On Thu, Sep 10, 2009 at 5:14 PM, David E Hollingsworth d...@fastanimals.com wrote: My apologies for not running gtk-demo to check before offering the patch! I'm not going to be able to look into it more for a while, so reverting may be the right choice at this time. David E Hollingsworth ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: Distinct performance issues with Japanese only on win32 systems
Hi, It seems Pango uses the Uniscribe script cache in a sub optimal way. Pango always create new script caches and throws them away in each call to uniscribe_shape. But in the Uniscribe docs it does not say that the cache needs to be cleared between ScriptItemize calls. We did some experiments and made the script cache array static so it's only initialized once and reused in each call. This seems to solve the speed problem (generates a magnitude speedup). Note: I've checked and Arabic (complex script shaping) renders correctly as far as I can see. I've attached a crude patch (Pango version 1.16.2) with this change. Note: this patch probably leaks a bit of memory as the pango uniscribe shape caches are never freed. We need to find out if this is a problem and how it could be solved. Also it does not seem that this performance issue is isolated to Japanese but for other scripts that need uniscribe as well. I think Japanese however suffers more severely as it uses space separators between the characters and that causes shape fragmentation and thus will generate a lot more calls to uniscribe_shape. This will in turn make the caches quite useless. Some other observations made: Reading the uniscribe docs is seems that you should use a separate cache for every font+size combination. However in the pango code it just uses separate cache based on script (the SCRIPT_ANALYSIS.eScript) . I've tried to make it break by changing fonts and size used but I seems to work anyway which is strange (or I probably do not understand the code well enough). Also the array holding the script caches in Pango is static and set to 100 and it's indexed on script. However eScript datatype is a Opaque 10bit value. It seems to been working well so far in Pango but could this be a issue if MS changes the implementation and use values 99? References: http://msdn.microsoft.com/en-us/library/dd368797%28v=VS.85%29.aspx http://msdn.microsoft.com/en-us/library/dd317726%28v=VS.85%29.aspx Regards, Fredrik On Thu, Sep 10, 2009 at 5:14 PM, David E Hollingsworth d...@fastanimals.com wrote: My apologies for not running gtk-demo to check before offering the patch! I'm not going to be able to look into it more for a while, so reverting may be the right choice at this time. David E Hollingsworth ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list basic-win32.c.patch Description: Binary data ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Problem compiling Pango on WIn32
Hi, I want to compile Pango on win32 (Windows XP SP3) to do some tests with fixing Japanese rendering slowness. I've managed to build Pango before on another computer a year ago, see post: http://www.mail-archive.com/gtk-list@gnome.org/msg27838.html When I tried to do the same now (pango-1.26.2 and pango-1.28.0) I it fails to create DLL's and this warning is displayed: Warning: linker path does not have real file for library -lintl When we looked into this it seems like libtool looks for libintl.dll but in the GTK bundle it's named intl.dll. If I rename the intl.dll to libintl.dll it works. However as it complains about more DLL's renaming seems like a bad solution. Do anyone have a clue what is causing it to prefix the DLL names it looks for with lib? My setup: * MinGW-5.1.6 * MSYS-1.0.11 * msysDTK-1.0.1 * gtk+-bundle_2.16.6-20100207 Also are there detailed build instructions how the official Win32 binaries are built? Regards, Fredrik ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Problem compiling Pango on WIn32
Replying to myself. I got it working by reinstalling this time I used the TDM MSYS distribution (tdm-mingw-1.908.0-4.4.1-2) instead of the standard MSYS. However MSYS and MSYS-DTK versions are the same as I used before. But I do not know why I had the problem in the first place.. /Fredrik On Wed, Apr 7, 2010 at 2:11 PM, Fredrik Corneliusson fredrik.cornelius...@gmail.com wrote: Hi, I want to compile Pango on win32 (Windows XP SP3) to do some tests with fixing Japanese rendering slowness. I've managed to build Pango before on another computer a year ago, see post: http://www.mail-archive.com/gtk-list@gnome.org/msg27838.html When I tried to do the same now (pango-1.26.2 and pango-1.28.0) I it fails to create DLL's and this warning is displayed: Warning: linker path does not have real file for library -lintl When we looked into this it seems like libtool looks for libintl.dll but in the GTK bundle it's named intl.dll. If I rename the intl.dll to libintl.dll it works. However as it complains about more DLL's renaming seems like a bad solution. Do anyone have a clue what is causing it to prefix the DLL names it looks for with lib? My setup: * MinGW-5.1.6 * MSYS-1.0.11 * msysDTK-1.0.1 * gtk+-bundle_2.16.6-20100207 Also are there detailed build instructions how the official Win32 binaries are built? Regards, Fredrik ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK 2.16 assertion `GTK_IS_TEXT_LAYOUT (layout)' failed
Hi Tor, Thanks for the quick reply. I just built and tested on gtk-2.16.0 on Linux and got the exact same assertion warning. However you said I should only file a bug if it was not present on Linux. Any hints on what will happen now? Cheers, Fredrik On Tue, Mar 31, 2009 at 5:12 PM, Tor Lillqvist t...@iki.fi wrote: In fact I notice that for each click, gtk_text_layout_set_preedit_string() is called twice, the second time with a NULL layout. Could it be that pygtk installs a log handler that filters out repeated identical messages? --tml ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK 2.16 assertion `GTK_IS_TEXT_LAYOUT (layout)' failed
Hi Again,
I created a test case in C that triggers this warning so it's not a
PyGtk issue. (attached)
The C test however always displays the warning after the container
remove action. So your assumption about PyGtk logger eating repeated
warnings is probably correct.
It could be a bug in my code I guess but as this has not been an issue
in any of the previous versions it could be due to changes in GTK.
I know that there has been some updates to the IM handling in 2.16,
maybe that can have something to do with it?
Thanks,
Fredrik
On Wed, Apr 1, 2009 at 1:20 PM, Tor Lillqvist t...@iki.fi wrote:
I just built and tested on gtk-2.16.0 on Linux and got the exact same
assertion warning.
However you said I should only file a bug if it was not present on Linux.
Any hints on what will happen now?
Well, it could still be a bug in gtk+ of course, but maybe it is more
probable that it is a bug in your code, or in pygtk, then?
--tml
#include gtk/gtk.h
struct cb_struct
{
GtkWidget *container;
GtkWidget *widget;
};
static void callback( GtkWidget *widget,
gpointer *cb_data)
{
g_object_ref(G_OBJECT(((struct cb_struct*) cb_data)-widget));
gtk_container_remove(GTK_CONTAINER(((struct cb_struct*) cb_data)-container),GTK_WIDGET(((struct cb_struct*) cb_data)-widget));
gtk_box_pack_start (GTK_BOX(((struct cb_struct*) cb_data)-container),
GTK_WIDGET(((struct cb_struct*) cb_data)-widget), TRUE, TRUE, 0);
g_object_unref(G_OBJECT(((struct cb_struct*) cb_data)-widget));
}
static gboolean delete_event( GtkWidget *widget,
GdkEvent *event,
gpointer data )
{
gtk_main_quit ();
return FALSE;
}
int main( int argc,
char *argv[] )
{
/* GtkWidget is the storage type for widgets */
GtkWidget *window;
GtkWidget *button;
GtkWidget *textview;
GtkWidget *box1;
struct cb_struct cb_data;
/* This is called in all GTK applications. Arguments are parsed
* from the command line and are returned to the application. */
gtk_init (argc, argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_title (GTK_WINDOW (window), GTK 2.16.0 assertion warning test);
g_signal_connect (G_OBJECT (window), delete_event,
G_CALLBACK (delete_event), NULL);
box1 = gtk_vbox_new (FALSE, 0);
gtk_container_add (GTK_CONTAINER (window), box1);
button = gtk_button_new_with_label (Button 1);
gtk_box_pack_start (GTK_BOX(box1), button, TRUE, TRUE, 0);
gtk_widget_show (button);
textview = gtk_text_view_new ();
cb_data.container = box1;
cb_data.widget = textview;
g_signal_connect (G_OBJECT (button), clicked,
G_CALLBACK (callback),(gpointer) cb_data);
gtk_box_pack_start(GTK_BOX (box1), textview, TRUE, TRUE, 0);
gtk_widget_show (textview);
gtk_widget_show (box1);
gtk_widget_show (window);
/* Rest in gtk_main and wait for the fun to begin! */
gtk_main ();
return 0;
}
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
GTK 2.16 assertion `GTK_IS_TEXT_LAYOUT (layout)' failed
Hi,
When using GTK 2.16 I now get this error when I remove a text view
from a container and re-add it:
GtkWarning: gtk_text_layout_set_preedit_string: assertion
`GTK_IS_TEXT_LAYOUT (layout)' failed
This assertion is only triggered once (when adding the widget after
the first remove). Subsequent remove and add operations works without
error.
I've attached a pygtk script that can be used to trigger the error.
This error did not occur in the previous GTK (2.16) releases.
I've tested on Win32 (Windows XP) and GTK bundle
gtk+-bundle_2.16.0-20090317_win32.zip.
Is this due to mistake in my code or is it a GTK bug?
Regards,
Fredrik
#!/usr/bin/env python
import gtk
msg = '''
In GTK 2.16 the first time you trigger a remove and readd of the this text
widget
by pressing the button the following assertion error is written to stderr:
GtkWarning: gtk_text_layout_set_preedit_string: assertion `GTK_IS_TEXT_LAYOUT
(layout)' failed
However after the first remove this no longer happens.
'''
class RemovedTextWidgetAssert(gtk.Window):
def __init__(self, parent=None):
# Create the toplevel window
gtk.Window.__init__(self)
self.connect('destroy', lambda *w: gtk.main_quit())
self.set_title(self.__class__.__name__)
self.set_default_size(450, 450)
self.set_border_width(0)
self.vbox = gtk.VBox()
self.add(self.vbox)
self.switch_button = gtk.Button('Remove and readd text widget')
self.switch_button.connect(clicked,self._remove_and_readd)
self.vbox.pack_start(self.switch_button,False,False)
self.text_view = gtk.TextView()
self.text_view.get_buffer().set_text(msg)
self.vbox.pack_start(self.text_view)
self.show_all()
def print_evt(w,*args):
print args
self.text_view.connect('unmap-event', print_evt)
def _remove_and_readd(self,*args):
self.vbox.remove(self.text_view)
# first time after a remove this triggers (stderr):
# GtkWarning: gtk_text_layout_set_preedit_string: assertion
`GTK_IS_TEXT_LAYOUT (layout)' failed
self.vbox.pack_start(self.text_view)
def main():
RemovedTextWidgetAssert()
gtk.main()
if __name__ == '__main__':
main()
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: MS Windows Input Method Editors and event box
Replying to myself .
I worked around this issue by doing an explicit call to the through
the Windows IME API when activating the widget.
I attached the code if someone else would find it helpful.
Cheers,
Fredrik
On Mon, Feb 9, 2009 at 4:55 PM, Fredrik Corneliusson
fredrik.cornelius...@gmail.com wrote:
Hi,
I have a problem with IME (Global Input Method Editors) on MS Windows
(Hindi,Japanese etc.).
When a TextView is packed inside a Event box the selected IME looses
it's binding to it when it's state is changed to insensitive or
hidden. (This is not the case if it's not in an event box.)
I found out that by hiding and raising the main window it is
reattached. However I obviously do not want to do that every time if I
can avoid it.
Any idea's of ways of telling the IME to rebind? Or even better avoid
loosing the IME binding altogether.
BTW,
I asked this on the GTK list last week but I figured this list might
be more appropriate hope it's ok.
Regards,
Fredrik
import ctypes
from ctypes.wintypes import HWND,DWORD,BOOL
prototype = ctypes.WINFUNCTYPE(DWORD, HWND)
ImmGetContext = prototype((ImmGetContext, ctypes.cdll.Imm32))
prototype = ctypes.WINFUNCTYPE(DWORD, HWND,DWORD)
ImmReleaseContext = prototype((ImmReleaseContext, ctypes.cdll.Imm32))
prototype = ctypes.WINFUNCTYPE(BOOL, HWND,BOOL)
ImmSetOpenStatus = prototype((ImmSetOpenStatus, ctypes.cdll.Imm32))
prototype = ctypes.WINFUNCTYPE(BOOL, DWORD)
ImmGetOpenStatus = prototype((ImmGetOpenStatus, ctypes.cdll.Imm32))
def enable_ime(hWnd):
'''
Enable IME input for a gdk Window.
@hWnd: the gdk windows handle (gdk.Window.handle)
'''
hImc = ImmGetContext(hWnd)
if hImc:
# Get current IME status
if not ImmSetOpenStatus(hImc, True):
print Error setting ImmSetOpenStatus
# Release input context
if not ImmReleaseContext(hWnd, hImc):
print Error doing ImmReleaseContext
else:
raise ValueError('could not get ImmGetContext')
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: Windows Input Method Editors and event box
Replying to myself .
I worked around this issue by doing an explicit call through the
Windows IME API when activating the widget.
I've attached the Python (pyGtk) code if someone else would find it helpful.
Cheers,
Fredrik
On Thu, Feb 5, 2009 at 12:05 PM, Fredrik Corneliusson
fredrik.cornelius...@gmail.com wrote:
Hi,
I have a problem with IME (Global Input Method Editors) on MS Windows
(Hindi,Japanese etc.).
When a TextView is packed inside a Event box the selected IME looses
it's binding to it when it's state is changed to insensitive or
hidden. (This is not the case if it's not in an event box.)
I found out that by hiding and raising the main window it is
reattached. However I obviously do not want to do that every time if I
can avoid it.
Any idea's of ways of telling the IME to rebind? Or even better avoid
loosing the IME binding altogether.
Regards,
Fredrik
import ctypes
from ctypes.wintypes import HWND,DWORD,BOOL
prototype = ctypes.WINFUNCTYPE(DWORD, HWND)
ImmGetContext = prototype((ImmGetContext, ctypes.cdll.Imm32))
prototype = ctypes.WINFUNCTYPE(DWORD, HWND,DWORD)
ImmReleaseContext = prototype((ImmReleaseContext, ctypes.cdll.Imm32))
prototype = ctypes.WINFUNCTYPE(BOOL, HWND,BOOL)
ImmSetOpenStatus = prototype((ImmSetOpenStatus, ctypes.cdll.Imm32))
prototype = ctypes.WINFUNCTYPE(BOOL, DWORD)
ImmGetOpenStatus = prototype((ImmGetOpenStatus, ctypes.cdll.Imm32))
def enable_ime(hWnd):
'''
Enable IME input for a gdk Window.
@hWnd: the gdk windows handle (gdk.Window.handle)
'''
hImc = ImmGetContext(hWnd)
if hImc:
# Get current IME status
if not ImmSetOpenStatus(hImc, True):
print Error setting ImmSetOpenStatus
# Release input context
if not ImmReleaseContext(hWnd, hImc):
print Error doing ImmReleaseContext
else:
raise ValueError('could not get ImmGetContext')
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
MS Windows Input Method Editors and event box
Hi, I have a problem with IME (Global Input Method Editors) on MS Windows (Hindi,Japanese etc.). When a TextView is packed inside a Event box the selected IME looses it's binding to it when it's state is changed to insensitive or hidden. (This is not the case if it's not in an event box.) I found out that by hiding and raising the main window it is reattached. However I obviously do not want to do that every time if I can avoid it. Any idea's of ways of telling the IME to rebind? Or even better avoid loosing the IME binding altogether. BTW, I asked this on the GTK list last week but I figured this list might be more appropriate hope it's ok. Regards, Fredrik ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Building Pango (1.22.4) on Win32
Hi, the current win32 Pango 1.22.2 binary build has a severe memory leak (#562574). I'm a build novice (I use PyGtk) but I managed to build Pango (1.22.4) myself using MinGW and it seems to be working well (even complex scripts). However I did not follow the README.win32 as it locked out of date and instead took a shot in the dark. What I did to compile Pango 1.22.4 (OS Win XP SP2): * Installed the current GTK win32 bundle in C:\GTK\2.0 (added C:\GTK\2.0\bin to path). * Installed Mingw , Msys and MsysDTK (in default locations) * Opened Msys (console) and configured make using with-included-modules flag: ./configure --with-included-modules * Compiled using make, it failed first time but continued on the 2:nd try. * Installed using make install. * The installed result was now present in C:\msys\1.0\local * Selected all and copied over the installed GTK (C:\GTK\2.0) replacing existing files. This seems almost too easy so I suspect I forgot something. Also, I do not know the parameters used for the the official builds. Is this documented someplace? Finally, Is there any time plan for the next updated of the Pango Win32 binaries? (I really trust them a lot more). Best Regards, Fredrik ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Next stable Pango release (with fix for bug #562574)
Hi, Is there any date set for the next stable release of Pango? Specifically a release with the fix for bug #562574 (critical win32 issue). http://bugzilla.gnome.org/show_bug.cgi?id=562574 Thanks, Fredrik ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Split cursor and win32
Hi there,
I'm adding BIDI support to a GTK applications textview. On Linux it
defaults to having a split cursor (with direction arrows) and this
seems like a really neat feature when working with BIDI. The problem
is that in the win32 version of GTK split-cursor is hard wired to be
switched of even if it is explicitly set it in the gtkrc.
The code that short circuits this setting is probably in
gdkproperty-win32 line 623 (GTK 2.10.14):
8
else if (strcmp (gtk-split-cursor, name) == 0)
{
GDK_NOTE(MISC, g_print(gdk_screen_get_setting(\%s\) : FALSE\n, name));
g_value_set_boolean (value, FALSE);
return TRUE;
}
---8
Is there any other way to turn this on without using the
gdkproperty-win32 code?
If not is there any chance of this behaviour to be changed in future
versions or is it disabled for reasons I'm missing?
Thanks for a great tool kit.
Regards,
Fredrik
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Getting text direction for BIDI content.
Hi, I need to know when a TextBuffer mark-set event enters a different text direction. I tied to get the text direction from a text iter. However I seems like it's always set to GTK_TEXT_DIR_NONE even if I can see it renders a RTL. Here's the pyGTK code I use to get the direction: 8--- textattrs = gtk.TextAttributes() iter.get_attributes(textattrs) textattrs .direction --8 I'm I doing something wrong or is there another way of getting the text direction? Another issue with BIDI in GTK that causes problems for me that GTK does not respect the gtk_widget_set_direction but always tries to guess the paragraph direction. See bug:http://bugzilla.gnome.org/show_bug.cgi?id=167746 Does anyone know if there is any solution in sight for this? Regards, Fredrik ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Arabic on win32
Thanks, I just did a quick test with the installer from gimp-win instead and it works! (http://gimp-win.sourceforge.net/) It's probably a Glade win32 build problem, but I have no clue what it is. Thanks Fredrik On 3/7/07, Tor Lillqvist [EMAIL PROTECTED] wrote: Fredrik Corneliusson writes: I got a problem with displaying Arabic text correctly on Win32 (Glade Win32 runtime 2.10). There is no such problem with the binaries from ftp.gtk.org. Do the gladewin32 people build Pango themselves without Uniscribe support? Or do you use some font with broken Arabic support? --tml ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list arabic_win32_working.PNG Description: PNG image ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
