Automation is preferred whenever possible. Thus, instead of working around this by asking the human to set wrapping modes manually, I can suggest two options.
Looking at scripts/touchpad.py, I notice a function called gedit_wrap_none, which should take care of setting wrapping to a sane value. However it seems to use the old gconf API:
import gconf
wrap_mode = client.get_string('/apps/gedit-2/preferences/editor' '/wrap_mode/wrap_mode')
this returns nothing, whereas it should return 'word' (the wrapping mode I have set up on my system).
Instead, this should probably use the new GSettings API (and GObject introspection, baby!):
SInce the test needs to be reworked, the second alternative I may suggest is to use a simple Gtk app that presents a ScrolledWindow with a TextView inside. This is not much more complicated than fixing the current test (at 61 lines, and the Gtk app implementation is a bit over 70 lines) and may be easier to port/extend in the future.
I'll attach a bzr branch with the Gtk app and we can decide which solution is best.
Automation is preferred whenever possible. Thus, instead of working around this by asking the human to set wrapping modes manually, I can suggest two options.
Looking at scripts/ touchpad. py, I notice a function called gedit_wrap_none, which should take care of setting wrapping to a sane value. However it seems to use the old gconf API:
import gconf get_string( '/apps/ gedit-2/ preferences/ editor'
' /wrap_mode/ wrap_mode' )
wrap_mode = client.
this returns nothing, whereas it should return 'word' (the wrapping mode I have set up on my system).
Instead, this should probably use the new GSettings API (and GObject introspection, baby!):
from gi.repository import Gio
gedit_settings = Gio.Settings. new("org. gnome.gedit. preferences. editor" ) get_string( 'wrap_mode' ) set_string( 'wrap_mode' ,'none' )
wrap_mode = gedit_settings.
gedit_settings.
SInce the test needs to be reworked, the second alternative I may suggest is to use a simple Gtk app that presents a ScrolledWindow with a TextView inside. This is not much more complicated than fixing the current test (at 61 lines, and the Gtk app implementation is a bit over 70 lines) and may be easier to port/extend in the future.
I'll attach a bzr branch with the Gtk app and we can decide which solution is best.