User:Rcrowther/project proposal

Desktop dictionary editor

• By: Andre Street
• email: rcrowther141@gmail.com
• apertium forum email: rcrowther.forums.npost.co.uk
• IRC nick: rob494

Note: Online I go by the name 'Robert Crowther'. All usernames, email, Github etc. is referenced to this name. The name has been used in informal situations.

Synopsis

Write a basic dictionary editor in Python3/Gtk.

This proposal is a variation on an idea proposed for GSOC; that Apertium should have a dictionary editor connected to Apy. This proposal is smaller, considers Apy only as a later addition.

Benefits to the Apertium project

Apertium builds a bridge between two different disciples, the study of language, and computing. While there are substantial areas of crossover, this means that interfaces for the Apertium project are not an add-on convenience. In the current state of Apertium, the interfaces of 'modes' and apertium-viewer are key projects. Requests for a GUI editor have been posted by email, to wishlists, and are a current GSOC aim posted to the wiki.

Previous efforts at a GUI editor e.g. DixTool, DixToolSuite, appear to have failed. This proposal addresses these concerns.

Deliverables

A GUI interface that can edit Apertium dictionary files.

The interface should be able to navigate to dix files, launch from a '.dix' file extension, and have basic editing of the 'section'/'entry' tags. Paradigms and sdefs will not necessarily be supported. Depending on progress, bidex may be supported.

The editor will be a minimal table display. No source data persistence beyond the original file is intended. No alternate views or MVC or similar structures are planned.

Within supported environments, after installation, the GUI should work stand-alone, with no evident data loading or connections required.

Background rationale

Aims

Any GUI project for Apertium must address,

Maintainability

Key. Apertium projects are likely to outlast their initial creation. Given that Apertium is Open Source, the GUI must be robust, and not make large demands on maintainers.

Extensiblity

Since Apertium itself has changed in key ways.

Performance

Apertium dictionaries are large and require XML parsing. The final project will be improved if loading those dictionaries never overwhelms the GUI.

Note that 'cross-platform' code is not listed as a key aim.

A first general proposal - KIS

Too many Open Source projects flounder on ambition. Especially GUI projects, where the base technology will keep moving. I have programmed in several toolkits, seen several codebases. So this proposal is for a project that Keeps It Simple.

The aim is to have working code almost immediately, even if featureless. But to build code that can be used by others, and developed and maintained by others. Here are ways the project can Keep It Simple,

Have working code almost immediately

Stub code will do

Stub code and static implementations are fine if they have documentation and enable the above aim.

Do not attempt a great scope of input

A read of monodix entries, no paradigms or defs, will have a use, and be a base to build on.

Do not attempt a great scope of functionality

Build for the base needs of users

Spend time that comes available on selection actions, drag and drop, file saving, preferences, help pages etc. These GUI tasks are tedious, but make the difference.

Build for coders base needs

Ample documentation. Prioritise APIs and plugins over non-fundamental editing features.

A second general proposal - multiple small scope GUIs

This is an aside, but relevant, and can be expanded on if requested.

This proposal, within the aim of KIS, will not clash with the application apertium-viewer. Apertium-viewer is largely a mode visualiser, whereas this project will be a dictionary editor.

Though an unusual approach, I see multiple GUIs as reflecting the use by Apertium of a loose underlying toolchain, connected only by the text streams. Such an approach is also an alternative approach to cross-platform provision i.e. 'We have small (easily maintainable and robust) applications, which do much the same thing, in much the same way, for Apple, Windows, KDE... machines'.

Choice of technologies

Using existing IDEs was considered. The only one to offer any possible advantage was Eclipse. But Eclipse is big and complex; it will not run on smaller and older computers.

After that, there are many widget toolkits, and languages to wrap them. But the solution with a known advantage is Python/Gtk. The combination has been used before in projects for Apertium e.g. apertium-tolk which, years after being coded, is running.

Project Details/implementation

On the technologies

The two main codebase requirements are Gtk and an XML parser. Gtk has a known and established Python wrap (which has recently become introspective). Python includes a simple fast XML parser in the core library. One of the first jobs will be to assess available parsers, to maybe save time later e.g. https://wiki.python.org/moin/PythonXml.

Models for the project

Some models the author has in mind,

Let's Build a Compiler, by Jack Crenshaw

By using KIS, and a wide knowledge base, Mr. Crenshaw reduced volumes of books to a few posts, while expanding the subject,

http://www.compilers.iecc.com/crenshaw/

Gaupol

The start of this project. As inspiration, and because it uses Python/Gtk. This proposal could be subtitled 'Gaupol, but for Apertium dictionaries',

http://otsaloma.io/gaupol/

apertium-tolk

It may be deprecated, it may need a DBus restart. But, without evident maintenance, it runs, it is lightweight. Apertium-tolk is my tool for demonstration and fast user-view assessment,

http://wiki.apertium.org/wiki/Apertium-tolk

Schedule

A suggestion about timing

I suggest that we halve the allocated time period to six weeks. For this unusual proposal a reduced period gives both sides a known deadline for assessing progress, and assessing the possibility and potential for continuing.

Work plan

I know from experience that this project will not have a steady timeline. Some GUI construction, such as table building, and icon creation, requires long work. Any switch in technology, such as a move to CPython, will result in research time. But the timeline illustrates the KIS basic aims.

Week 1

Build a GUI

Widgets only, if necessary, as this may suggest features easy or difficult to implement, or new possibilities.

Week 2

Connect, load and save data, to dictionaries

This order is the reverse of normal GUI development, but the model we are working with, 'dix', is well-established.

Week 3

Selection and editing

Selection especially needs to be explicitly built, and can take time. It would be the main purpose/usage of the proposed GUI, so time is allocated for this task.

Week 4

Build the inner environment of the GUI

Preference saving, help, 'recently used' files, icons etc. These make the difference for a GUI that feels mature and usable.

Week 5

Establish the wider environment of the GUI

For example, Debian/RPM packaging, licensing. A build environment suitable for release.

Week 6

Feature implications

The proposal for this project is that it finishes as a release. However, a key aim is that the work can be adopted by others. At least, APIs should be documented. If possible, or by this stage decided to be desirable, further API work may be considered, such as plugins or APY connection.

Biography

Details on my position

I am unemployed, so can make the required time (though I must justify that time, and so make this application).

My commitments over the next few months are few. I spend maybe three mornings a week doing odd jobs. I will attend a wedding during February (perhaps three days away). During March I will house-sit. During the house-sit, I will be physically relocated. However, the house has internet access, and I will be able to work with few interruptions; an improvement on my current situation.

Qualifications

From a long time ago, I hold Joint Hons in Electronics and Computer Science.

For the last ten years, though not employed as a developer, I have ad-hoc programmed in various computer languages. Easier to mention gaps; I have not learned the wider environments of large languages (never investigated Java Hibernate, for example) and have never coded in a full functional language like Haskell. I refer to my experience where relevant.

Previous work with Apertium

I've produced my own 'nursery' level language pair, implemented an 'apy' server and html-tools behind nginx (running on a salvaged computer in a spare room). Before this application I contributed several Wiki edits and new articles.

Why this project

Nearly all my activity on Apertium so far has implied projects. I've (accidentally) added two entries to the Unhammer wishlist. But if I attempt a larger project, I'd like a match between my skills and the project. I have no background in commercial programming, so would like to keep the project low level, then see what we can do.

I make no claims for my Python programming. On my scale, 2/5. I've only programmed in Python for two months, but should be able to improve rapidly. I have produced several GUIs already e.g. https://github.com/rcrowther/sitebuilder

Gtk I know very well. I'm not up to speed, don't know the binding, but a few years ago now, I coded custom widgets in 'c'. 5/5? For example, I know that producing tables of data in the MVC widgets of Gtk is not trivial. It will not be easy to enable live editing of table entries, maybe requiring custom renderers.

But when I saw Gaupol, I thought, 'I'd like that as an Apertium dictionary editor'. And I said to myself, if I get the opportunity, I'll do it.