Re: [Denemo-devel] libDenemo

[ben]

hi list,

Some reflection concerning a possible libDenemo. This is just a personal
point of view, to feed feed the discusion on about how could denemo be
modularized in the future...

IMHO, one of the issues is, for example, about DenemoDirective.

Each denemo core object ('note', 'chord'...) has a DenemoDirective
which contains specific types or code for various interfaces:
- lilypond text for the lilypond output
- drawing directives (mainly a GdkPixmap).
- also (upcoming) playing directives with MIDI objects,

This strongly binds the presentation stuff into the internal of the
musical structure. This means the non-ui stuff part of denemo would not
contain the musical core structures!

Some changes would be to move DenemoDirective members of the core
objects to another place:

- note/chord/etc.. to have no directive member, but a user_data gpointer
- DenemoScore to be renamed as a 'score' (being then a core object)
- a set of function would be added to set/get user_data into core objs.

Checking interface binding issue such as this one would then lead to put
the core objects into libdenemo as a non-ui, non-midi, non-lilypond
aware, generic (western-music) score library.

Then, the score widget module (say for example 'libdenemo-widget')
- the DenemoDirective type would be there.
- a DenemoScore would appear here, adding ui members to a score.
- the module would use the provided set/get to link a DenemoDirective
  to a core element user_data member.


some advantages of such a separation into 2 libraries (and abstract
library + a widget library) can be:
- maintenance/improvement be really easyer for both libs.
- let _any_ graphical, or performance library to use
  libdenemo to manage (western) muscial data w/o to be bound to Gtk.

The DenemoDirective may not be the only type on which this operation
could be done, but that is a good example to tell my point of view.

Another future issue may appear with MIDI as a DenemoDirective: should
the score widget have also the role to manage (indirectly or directly)
the midi interface ?

thanks for discussing,
- ben

Jeremiah Benham a écrit :
> On Tue, 2009-02-17 at 21:51 +0100, ben wrote:
>> Nils Gey a écrit :
>>> Hi list,
>>>
>>> I just remembered a talk from a while back about the GUI of Denemo and 
>>> different interfaces. Just now I had a talk in #denemo about Denemo on 
>>> MacOS which needs X11 and is clumsy. I rememberd that Ardour tried to get 
>>> rid of X11 in MacOS, too. And there was this small discussion about Denemo 
>>> on a NintendoDS, as Notepad for Notation.
>>>
>>> Many (open source) apps are diveded in frontend and backend. Of course for 
>>> a notation-editor this makes no primary sense because having a GUI is a 
>>> central point. But even here it would have some benefits like having 
>>> special GUIs for different purposes which are more then just command-sets. 
>>>
>>> Linuxsampler for example has a QT and a JAVA GUI, Ardour has a 
>>> stripped-down GUI for educational use. 
>>>
>>> Even on a command line you could do batch-conversion or other Denemo-tasks 
>>> which don't need a GUI.
>>>
>>> To come to the core of this:
>>>
>>> Do you think it would be a benefit to change Denemo to a Backend/Frontend 
>>> architecture?
>>>
>>> Nils
>> definitely yes!
>> that could be separated into:
>> - libdenemo: shared object for non-ui stuff
>> - libdenemo-ui: for the score widget
>> - denemo[-gtk]: the acutal program that would depend on the 2 libs.
> 
> I like the idea but I don't know about how to go about doing it. My
> iphone does not have gtk but it does have gcc and glib. I also have long
> commutes to work where it is often too crowded on the train to take out
> my laptop. I doubt I would ever have time to create a iphone interface
> because my iphone will be running android before I have time I am
> guessing.
> 
> Jeremiah