GUI toolkit selection for a text editor widget

Discussion in 'Python' started by Srinath Avadhanula, Nov 8, 2003.

  1. Hello,

    Sorry to be bringing up what seems to be a somewhat beaten up topic...

    This is what I wanted to do:

    Create a _simple_ text editor widget which supports VI(M) style
    keybindings but works with arbitrary fonts/unicode characters. Vi(m)
    unfortunately, does not support Devanagari (or proportional fonts) and
    it looks like it will take quite some time for these things to work. As
    and when Vim supports Devanagari on Windows, I will give up this effort.

    My current aims are:
    1. Simple Vi(m) style keybindings.
    2. Syntax highlighting for arbitrary files based on Vim-style syntax
    highlighting definitions. Vim defines syntax highlighting for files
    based on a very flexible regexp style approach. Thus you can define
    syntax hightlighting for new file types just by writing some regexps.
    3. Should be able to load/edit files written in unicode.
    4. Macro capability.
    5. I want to implement this purely in python.
    6. Should work on windows.
    7. I do not really care much about speed/looks etc as long as the thing is
    functional.

    The choice of the GUI toolkit is therefore almost exclusively depends on
    how these conditions can be met. This is my take so far:

    1. PyQT: Unfortunately, the qtext module which extends the scintilla module
    to QT is available only under a commercial license for windows. The
    QMultiLineEdit widget does not support any text styling at all. Hence
    PyQT seems to be ruled out straight away.

    2. wxPython: The wxStyledTextCtrl widget showed great promise. It has
    almost everything one would wish for. Except for a _major_ bug while
    editing unicode. The text caret which shows where the text insertion
    will happen is offset from the actual insertion point in complex
    scripts like devangari or arabic. This looks like its a problem with
    calculating text extents. Robin Dunn has acknowledged this bug, but
    unfortunately, unless there is a workaround, I cannot do anything with
    wxStyledTextCtrl at all.

    wxPython also has wxTextCtrl which has far lesser features than
    wxStyledTextCtrl, but at least does not have the bug with the text
    caret. Unfortunately, it looks like it does not provide some necessary
    functions. For one, if I desire to do syntax highlighting based on it, I
    would need to find out the current range of text displayed in the
    window. But I couldn't find any way of finding out which lines are
    actually displayed. The various wxScrollBar functions (which wxTextCtrl
    inherits) do not give useful information.

    3. Tkinter: I looked briefly at Tkinter and the Text widget looked very
    impressive indeed! It looks like the way it highlights text is even
    more powerful than Vim in that each character (or range) has multiple
    "tags" associated with it and the most recent tag takes precedence.
    This looks like something which might be very handy. It even supports
    inserting bitmaps etc. All in all, very neat looking.

    But there seems to be some limitations:
    1. How do I recognize control key inputs? I tried
    self.bind('<Key>', function)
    but how to find out if CTRL-a has been pressed in the function. When
    I ran a simple app, event.char reports 'a' when I press CTRL-A. So
    does event.keysym and event.keycode... wxPython has something called
    event.ControlDown() for keyEvents...

    2. There seems to be a problem with displaying unicode which Text
    suffers from too :( The problem is not as severe as the one
    wxStyledTextCtrl suffers from and it looks like it can be "lived
    with". When moving over certain "composing character" strings in
    unicode, the caret seems to move _between_ the characters. Ideally,
    each sequence of composing characters would be considered a single
    "glyph"... I will elaborate if someone needs clarification.

    3. Although the Text widget itself is powerful, from what I gather in
    this newsgroup and on the web, Tkinter does not provide things like
    a tree control widget which might be essential later on. This looks
    like something which can be worked around, because idle, the editor
    provided with Python 2.3 seems to have all these things constructed
    using the basic primitives...

    Infact, I am wondering whether I should just modify Idle to accept Vi
    style key-bindinds...

    I would greatly appreciate any comments.

    Thank you,
    Regards,
    Srinath
     
    Srinath Avadhanula, Nov 8, 2003
    #1
    1. Advertisements

  2. .
    .
    .
    .
    .
    .
    Tcl/Tk experts make the Text widget do remarkable things.
    I'm sure they've already implemented vi bindings at least
    once <URL: http://wiki.tcl.tk/ctext >. Your questions
    would be welcome in comp.lang.tcl, if you don't find
    satisfaction elsewhere.
    1. While I don't have access to a Tkinter just
    now, and so can't usefully exercise code
    examples, <URL: http://wiki.tcl.tk/keysyms >
    should model a solution to your keysym
    difficulties.
    3. You'll want to read <URL: http://wiki.tcl.tk/tree >.
     
    Cameron Laird, Nov 8, 2003
    #2
    1. Advertisements

  3. Don't forget pygtk, bindings for GTK+. GTK+ has a very powerful
    GtkTextView widget. There is also a GtkSourceView widget that has recently
    been wrapped for python use. GTK+ supports custom keybindings throughout.
    GTK+ works well on Windows. GTK+ on Windows XP uses the XP themeing
    system, so GTK+ apps look native on Windows XP. The Windows classic
    theme, although not perfect, works very similarly to native Windows
    widgets.

    If you use pygtk but would rather use the Scintilla widget you may be
    interested in this: http://sra.itc.it/people/cavada/PyScintilla2.html
     
    J. Random Hacker, Nov 9, 2003
    #3
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.