From GIMP Developer Wiki
< User:Jehan
Revision as of 23:36, 19 February 2014 by Jehan (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Here are some of the things that I would love to see happen and that I think could be suited for a 1-summer coding and specifying by a student. Note that I like to include a part of specification-making and designing into my projects. I do believe a developer should not be a "stupid coder", and one should be able to think, discuss and propose ideas.

Also I do not necessarily know already how I would myself implement any of these.

Create a plugin management framework

Current plugin management is manual: we ask users to download archives from random places, without much security, to uncompress them in some config directory and restart GIMP. If these are C plugins, there may even be a compilation phase, obviously repulsive for many users. This manual procedure lacks simplicity, feedback, does not allow plugin automatic updates, lack security, and is hard to manage (you can't be sure what you installed, which version, are they new versions?).

It would be extremely beneficial to design a plugin management system. This implies updating the current plugin format (existing plugins should still work, but will need to be updated to be integrated as managed plugins) by writing the specification of a manifest format to manage extensions. The finale goal would be to have a public repository with signed extensions, auto-updates and version management, and maybe why not in the future have user comments and notation.

The GsoC boundaries would be to specify the base features for management and download/installation/update and develop a proof-of-concept. The proof of concept would not have to be extremely advanced. In particular just browse online extensions, download, install them and have update checks at restarts. Security would likely not have to be implemented at all in the GsoC boundaries (better than nothing approach), but it should be considered in specifications.

Optimal student requirements:

  • Basic GTK+ knowledge for the "plugin browser".
  • Good specification knowledge, love of file formats and protocols.

GIMP auto-update, version checks

Users currently have to get update news of GIMP, old fashion: mailing list, website, RSS, etc. It would be very beneficial if GIMP had an auto-update feature, with verification of new versions from time to time. The auto-update could be disabled at compile time, and replaced by a simple version check & notify, or even nothing (for instance for repository with their own versionning system, like Free Software OSes package management systems, or recently proposed "Steam". They don't want auto-update). Such a feature should include a strong security because we can't allow binaries to update themselves lightly. This implies OS and network security (signed archive downloaded over a secure layer).

Optimal student requirements:

  • Good OS knowledge (at least for the main platforms supported by GIMP: Linux, Windows and OSX);
  • Good knowledge of security protocols.

Improve graphics tablet support

Current support of graphics tablet is terrible, in particular on some OS (Windows is the worst, from what I hear), but even under Linux. Even the device management UI is terrible, broken into several different windows and annoying to use and understand.

A good student project could be to improve as much as possible device usage. It could be a good idea to base the project on the gtk3-port branch for this, since it will bring a lot of improvement to device management, and backport as many as possible to the master branch at the end of the project.

Optimal student requirements:

  • MUST have one's own tablet. Not necessarily an expensive one.
  • Good OS knowledge (device part).
  • Good GTK+ knowledge.
  • Regularly uses GIMP with a tablet oneself (aware to GIMP limitations and issues).

Unlimited-sized Layers

Some users like to control layer size to prevent from accidentaly drawing outside of fixed limitation. But other users want to be able to freely increase layer size and not bother. A typical use case is moving a layer, and consequently have some of the layer borders inside the image borders. While you don't notice it immediately, your next stroke gets stopped in the middle by the border, forcing you to break your workflow to resize the layer.

There are 2 angles to consider this feature: layer without visible borders ("apparently" unlimited, though obviously internal data won't be unlimited); or layers with visible border but auto-increasing on need (when you stroke over the border for instance).

Optimal student requirements:

  • Good GTK+ knowledge.

"Smart Objects"

The feature idea is to be able to link another image file (either XCF or any format supported by GIMP), either full or partly, as a layer in another image. This concept is known as "smart object" in Photoshop or "linked objects" in Blender. This would be a very good feature to have in GIMP.

Optimal student requirements:

  • GTK+ knowledge.

Make GIMP UI scriptable

Right now scripts can create their own UI, or can add menus and meny items. But you can't improve existing UI. For instance you may have plugins adding layer features, thus you would want to add a small button in the layer dialog, or even next to each layer item. You may even want to replace some widgets in the layer dialog or just remove/hide them.

You should be able to: add widgets in various places, create new optional docks, hide existing widgets. And this should all be available in GIMP plugin interfaces.

Optimal student requirements:

  • Good GTK+ knowledge.
  • API based thinking.