[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Denemo-devel] libDenemo
From: |
Jeremiah Benham |
Subject: |
Re: [Denemo-devel] libDenemo |
Date: |
Thu, 19 Feb 2009 09:46:24 -0600 |
I can create a branch for you if you would want to start writing some
code for it. It can be placed in a subdirectory in that branch.
Jeremiah
On Wed, 2009-02-18 at 22:05 +0100, ben wrote:
> 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
>
>
>
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel