Yggdrasil

Erland Isaksson edited this page Dec 31, 2015 · 1 revision

http://socialmusicdiscovery.googlecode.com/svn/yggdrasil/trunk/src/org.socialmusicdiscovery.yggdrasil.foundation/icons/logo/splash.png

Introduction

Yggdrasil is a rich client for the Social Music Discovery (SMD) project, built on the Eclipse Rich Client Platform (RCP).

The name Yggdrasil is taken from Norse mythology; it was said to be the world tree around which the nine worlds existed. The branches of Yggdrasil extend far into the heavens, and the tree is supported by three roots that extend far away into other locations.

In SMD, Yggdrasil connects metadata in the music library and allows the user to maintain both hard facts and subjective opinions about local or online music. It may not be the world tree around which everything revolves, but is the view into this tree - the SMD repository - and the instrument for connecting the tree with heavens and other locations.

Yggdrasil is not primarily an instrument for enjoying music, more about paving the ground for listening pleasure.

Legalese

The preliminary logo was downloaded from WikiMedia and slightly augmented with text. Credits and license details can be found here.

Eclipse RCP is licensed under the Eclipse Public license.

The Yggdrasil client itself is provided under the same license as the SMD project (New BSD license).

The Prototype RCP Client

Yggdrasil was born from the Prototype RCP Client. Most information on the prototype is still valid, but it has now become obsolete as the Yggdrasil client is growing more stable, and since server code changes prevents the prototype client from running.

To Download and Run

Latest pre-compiled nightly builds of the yggdrasil can be found here:

Download, unzip into desired location, drill down to find the launcher (on Windows, this will be called yggdrasil.exe).

More info to be added ...

To Do

Enhancements and defects are registered in our shared "todo list".

Apart from a vast number of details to implement or fix, there are a few major features missing:

  • Editors for the remaining core model entities (Work and Part)
  • An installer and an update site (p2 repository)
  • Editors for the subjective model

To Extend

The Yggdrasil client is designed to leverage the Eclipse extension architecture. We hope that other developers will extend our platform and initial application by developing more or better plug-ins to enhance the end-user experience.

More information on how to develop plug-ins can be found on the Extender's Guide To Yggdrasil.

To Develop

The short story:

For more info, read below.

Design Guidelines

Some brief and preliminary thoughts on the design principles for the RCP client. Structural info and guidelines can be found on the Yggdrasil Plugin Structure page. Comments expected and welcome!

  • JFace
    • JFace offers a convenience layer on top of SWT, making it much easier to work with. Application code should rarely touch an SWT component directly.
    • JFace data binding is perhaps the most important discriminator to separate a rich client from a thin. We bind widgets to properties using data binding, and we use observable label providers in grids.
    • Set rather than List or Collection. Design rationale: to ensure proper data binding and stable collections, we need a distinct collection type. By definition (?) a relational DB returns unique instances in undefined order. All grids sort rows on user request, and a Set is easier to diff/merge in general. All in all, Sets fit the bill better than Lists, and hence all core signatures accept and return Sets unless there is a specific reason.
  • Menus, Actions and Commands
    • Menu items (both main and popup) are primarily declared thru extension points, not attached directly to viewers. This makes common commands universally available; whenever and wherever an Artist is selected, a menu with all applicable Artist commands is available.
    • Actions vs. Commands - Commands are "new school" and more powerful, Actions are "old school" and less powerful. However, the command framework is pretty abstract and - to most people - confusing. We should use Commands to define "global" actions that we bind to keyboard shortcuts, but we use regular Actions and Runnables where a Command isn't required.
  • Nebula - if we want to stay RAP-compatible, we can probably not use any Nebula components. In time, we may offer alternative implementations (RCP vs RAP). If we ignore RAP compliance, these Nebula components would be of particular interest:
    • Grid - the Nebula grid offers most of the features that the standard Eclipse Tables and Trees lack. All lists, trees and tables could be replaced by the grid.
    • PShelf - could replace ExpandBar as the primary navigation widget.
  • UI Style and "Skins"
    • Now (Eclipse 3.x): we run with the default appearance produced by the Forms Toolkit.
    • Then (Eclipse 4): we use the new (CSS-oriented) way of styling the application. It is too much work to do that using the current platform.
  • Target platform - a pre-configured RCP target platform is downloaded and provided by Maven. This includes the RCP base framework and all desired plug-ins to avoid the dependency on individual installations.
  • Plug-in Component structure - we separate the client in a few main parts. The basic idea is to have a small base product that is easily installed and rarely updated, and to use an update site to maintain the other components.
    • Installer - an almost empty "bootstrap" to allow installation/update of other components from update site. At the time of writing, this does not exist.
    • Product - splash screens, license, intro pages, etc
    • Feature - a configuration of the base plug-ins
    • Foundation - fundamental UI components; custom widgets, utils, common abstractions, ...
    • Data Source (Server Connection) - abstracts the server facade and produces UI-friendly objects (lazily loaded, observable, named ...).
    • UI plugins:
      • Navigator UI - A PShelf presentation of "shallow" objects, with the ability to "inflate" any object and open an editor on it
      • Core model editors - EditorPart and EditorDialog subclasses that operate on SMDIdentity instances from the core model
      • Subjective model editors - EditorPart subclasses that operate on SMD instances from the subjective model
  • i18N
    • At the time of writing, the prototype is not localizable. We should of course change this at some point in time, using the built-in Eclipse/Java mechanisms to do so.
    • character set is UTF-8. All projects should have this setting defined, to avoid dependencies and failures due to bad workspace settings.
  • Naming conventions
    • Names of all plug-ins are fully qualified and prefixed by org.socialmusicdiscovery.yggdrasil. This includes Eclipse metadata ids, file system directories and Maven artifact ids.
    • -suffix: some projects carry a "dash suffix" in file system and Maven pom files to make them easy to spot in the file system and build logs. This pattern applies to projects that can benefit from this type of discriminator without causing conflicts with the Eclipse ID, e.g. -site or -product.

Developer Notes

A few notes that may or may not be useful for RCP developers.

"FAQ"

  • Launcher doesn't launch
    • Q: Sometime the launcher just won't launch stuff from within the IDE, even though everything seems to be in order.
    • A1: delete the launcher form the "Run Configurations" menu, and re-launch it by right-clicking the checked in launcher ("Run As - Eclipse Application")
    • A2: delete the launcher form the "Run Configurations" menu, and re-launch it by opening the .product file and clicking "Launch Eclipse Application"

External Links

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.