LilyPond GUI

From LilyPond Wiki

Jump to: navigation, search

This page is set up to collect ideas for developing a new Graphical User Interface (GUI) for LilyPond. There are various third-party applications that either export to LilyPond's file format or integrate with LilyPond by providing a customized text editing environment, but the two versions of LilyPad that ship with LilyPond installers are sorely lacking in features.

Instead, it would be nice to develop a cross-platform GUI that could ship with both the Windows and Mac OSX installers, and possibly the *nix installers too. This way, improvements to the editor could happen through one code base instead of WinAPI and PyObjC.

The code name for this project: EasyLilyPond.

Contents

[edit] Brainstorming

  • Programming language: Python. (Or Scheme?)
  • Graphical toolkit: GTK+.
    • LilyPond already uses Pango/Glib, so GTK+ is the natural choice.
  • Bindings:
    • Python bindings with PyGTK
    • Or maybe Scheme bindings using guile-gtk[1] (discontinued) or Guile-GNOME[2] -- but we don't want to become GNOME dependent.
      • BTW, guile-gnome only compiles GNOME bindings if its configure script finds GNOME libraries on the host system. If we don't use the libgnome bindings, we won't be GNOME-dependent. Pnorcks 21:37, 22 October 2009 (UTC)
    • I'm starting to like the idea of using guile-gtk. Scheme would be more natural for me (at least right now). And if guile-gtk is too out-of-date, let's learn how to write a port and update the port.  :-) That would be a challenge for the both of us, I'm sure. Pnorcks 00:18, 10 October 2009 (US: Pacific)
      • Update: I adopted and fixed the guile-gtk package in the AUR: [3]. It seems to work okay. I can't compile guile-gnome due to this bug: [4]. So, I'll just play around with guile-gtk for now. Pnorcks 21:37, 22 October 2009 (UTC)
  • Build tools
    • Preferably Waf (or Autotools), since LilyPond is switching to it eventually.
    • I'm wondering if both Waf and Autotools would be needed though. John's initial request for testing required an invocation of autogen.sh in order to work correctly. Or is this just not implemented yet? Pnorcks 00:18, 10 October 2009 (US: Pacific)
  • Build environment: GUB, both as part of the Lily build and as a standalone application too.
  • Inspiration:
    • jEdit/LilyPondTool [5] (cross-platform, Java-dependent)
    • LilyKDE/Frescobaldi [6] (possibly cross-platform, KDE4-dependent)
    • K-Lily [7] (possibly cross-platform, KDE3-dependent)
    • LilyEditor [8] (Win only, .net dependent)
    • Denemo [9] embeds a GTK code-editor component (with Scheme bindings AFAICS). It's cross-platform but limited.
  • Non-inspiration: [10] :-)

[edit] Initials TODOs

  • Set up a repo.
    • Git (I love git, so I won't compromise here :-)
    • repo.or.cz or Github or Gitorious.
      • Or a repo on lilynet's server: for instance at git://94.23.42.70/easylily.git Pers 11:29, 6 October 2009 (UTC)
    • BTW, it's too bad Google Code doesn't natively support Git yet. It would be nice to have an issue tracker and homepage for free!
      • Yeah, but otoh it's great that we have a cool bugtracker on [11] :-)
  • Learn Python (Patrick has been slacking)
  • Licensing
    • GPLv2 or later.

[edit] Text-Processing Features

Primarily, EasyLilyPond will be a text editor specifically written to use with LilyPond. So many features should be made available related to text processing.

  • Search / Search and Replace with regular expressions
    • Fairly straightforward (hopefully) once things get going
  • Syntax highlighting
    • Note: Ideally, the highlighting should be context-sensitive, so that if you type \new in the wrong spot, it will not be highlighted. We might be able to extend Carl's yyout2grammar script to output LilyPond's grammar in a standard syntax highlight file format (if such a thing exists). Writing a framework that caters to 2.13.5 syntax is a bad idea; when GLISS happens, EasyLilyPond will have to be adjusted, which is an absolute maintenance nightmare. We should automate as much as possible. And writing a new parser should not be necessary.
      • Keep in mind that this is a suggestion for an ideal situation. It's likely difficult or impossible to automate syntax highlighting directly from LilyPond.
    • The improvements mentioned above will also help provide groundwork for improving the Vim and Emacs syntax files that ship with LilyPond; they could then be context-sensitive.
  • Automatic indentation
    • Must take Scheme into account too, since Scheme is indented differently than the standard LY syntax.
  • Foldable blocks
  • Proper UTF-8 support
    • This might be more difficult than we expect, since Unicode on Windows is a bit hazardous.
    • A solution would be to use an existing text-editing component such as Scintilla [12]. Many code editors already use it (among others, the popular Windows editor Notepad++). And there are bindings for GTK and PyGTK [13] (the latter doesn't seem to be maintained though).
  • Sensible shortcut keys
    • Fully customizable -- well, as much as possible.
  • LIGHTWEIGHT! (a few hundred KBs at best)
    • Yes, besides the GTK+ dependency, everything else should definitely be lightweight. This isn't saying GTK+ is not lightweight, but the text editor will be lighter. Pnorcks 00:23 October 10 2009 (US: Pacific)

[edit] Integrating with LilyPond

  • Buttons to compile LY->output (PDF, PS, SVG, etc.)
  • Menu options/dialogs to allow easy use of the scripts (lilypond-book, midi2ly, etc.)
  • Nice logos/branding.
  • Links to online documentation.

[edit] Other essential stuff

  • Add i18n and l10n support, using gettext/.po files for every user-visible string chars like in Frescobaldi.

[edit] Extra Features

  • Built-in PDF viewer/previewer
  • Auto-update mechanism (e.g. update from 2.13.5 to 3.0)
  • Ability to launch other LilyPond editing environments (LilyPondTool, etc.)
Personal tools