Please consider funding my work on Glom so that I can implement all these features. Murray Cumming
- Internationalization via .po files: Add Export and Import buttons to Translations Window, so translators can use their usual .po file tools. Time: 10 hours.
* Add import and export buttons to the dialog in Glade. * Create signal handlers for those buttons in the dialog class. * In the signal handlers, read (parse) and write (generate) the .po text file format for the strings.
- GUI for creating the initial user, after asking for the root password.
* This can be a completely separate program. It can be in any programming language (Python with pygtk might be appropriate). * It should parse the postgres configuration files, and then change them where necessary.
- Warn when deleting used fields and relationships: If a field or relationship is on a layout or report, or a field is in a relationship, warn before deleting.
* Create a new warning dialog in the Glade file, and create a C++ class for it. * Add methods to the Document_Glom class, such as bool get_field_used(). Extra output parameters could return a string describing the use, or specific information about the layout, relationship, report, etc, on which it is used. * Whenever the UI allows someone to delete one of these things, call the method and show a dialog if necessary. * Depending on the dialog response, continue or cancel the deletion.
- Quickly add Relationship/Field: For instance, when adding a field to a layout, quickly add a relationship so that you can add a field from it, without closing the layout window, opening the relationships window, and opening the layout window again. Or to quickly add a field to the current table when adding a field to the layout dialog. Or, when specifying a related choices lists (in a Field'a default formatting). (30 hours)
* Add buttons to the dialogs in Glade. * Create signal handlers for those buttons in the dialog classes. * In the button signal handlers, open the appropriate dialogs - see the code that does the same from the regular menu signal handlers. Then update the current dialog to show the new available choices. * Ideally, think of a way to avoid this causing so many windows to be open at once, on top of each other.
- Related Records as Calendar: Display a portal of related records in a calendar, using a specified field as the date.
* This requires some small API additions to 'GtkCalendar.
- Drag-and-drop layout: Add a panel of available items and show visual feedback as they are moved around on the layout. But still use the automatic-layout system.
* Steal ideas from Glade. Time: 60 hours.
- Relationships Overview: See a picture of all the tables, with all their relationships to each other. Use a canvas and let the user drag the tables around. Time: 70 hours.
* This should almost certainly use goocanvas, which should probably be wrapped for C++ first, with gmmproc. * This is a bounty, so far for $400.
- Windows Port: Shouldn't be too difficult. All dependencies are portable. Time: 60 hours.
* This should use native GTK+ on Windows rather than X11 on Windows. * This should use g++, not MSCVC++.
Tasks requiring more experience
Some of these require you to have experience of, or learn about, the technologies marked in bold, such as Cairo, Avahi, or libgda.
- Custom Print Layout: For instance, a perfect-looking official invoice. Implement with Cairo and the GTK+ 2.10 printing API. Time: 80 hours.
- Automatic Server Detection: Patch postgres to use Avahi for ZeroConf/Bonjour/Rendezvous service broadcast. Postgres already uses Bonjour on MacOS X.
- Deal with lots of data The custom tree model should progressively gets only the record values that are visible in the scrolled window. The new libgda API apparently allows this by supporting database cursors. So we need to finish the libgdamm wrapper for the newer libgda version.
- Scripting: Most common actions should be standard features without the awkwardness of scripting, but maybe we need some way via the custom buttons to, for instance, on Contacts details create a related Invoice and take you to the Invoice details. For this, we must just present a python API for some parts of the Glom structure in addition to the current record object. This requires knowledge of the Python C API, which is used already for calculated fields. Alternatively, you may use boost::python if you are already familiar with it.
- Non-Indexed Calculated Fields: Optionally don't store values - just recalc them when seen/used, and therefore don't allow their use in relationships, though that's awkwardly technical when seen in FileMaker. Time-to-complete: 60 hours.
- Locking: Don't let a second user edit the same record. (Delay unlock for 5 seconds after entry loses focus). Update the display when the second user changes the same record. Time: 50 hours.
- Multi-column relationships: Match on 2 key fields instead of just one. Time: 30 hours.
- Performance:: Keep connection alive, do less by-value copying, more caching and hashing. libgda 2.0 (when finished) should help with this.
- Web UI: Possible in principle, though it couldn't be so responsive as a desktop application. All the needed information is in the .glom document. Something for a web developer, and there's no need to choose a favourite language/platform - just do it.
- Alien Tables: Allows some tables to get/set data in non-postgres sources, such as evolution-data-server, so people don't need to enter their contact information twice.