Re: [Hydrogen-devel] RFC ::: desired changes before 1.0 ::: RFC

[Jérémy Z. <je...@as...>]

On Tuesday 17 April 2018  10:16, IOhannes m zmölnig (Debian/GNU) wrote :
> hi,
> 
> On 2018-04-17 08:59, Jérémy Zurcher wrote:
> > 
> > Hi everyone,
> > 
> > there are a few changes I would like to make happen before 1.0.
> > 
> > 
> > 1 : I would like to remove 'data' from the system data path
> > 
> >     /usr/share/hydrogen/data/… -> /usr/share/hydrogen/…
> > 
> >     - share is for data, no need to specify it in the path
> 
> no, it's not.
> or rather, i doubt that the term "data" used by hier(7) has only the
> specific notation of "auxiliary assets" in mind which you seem to imply.
> the important part about /usr/share in the the FHS is really the this is
> the place to put stuff "that can be shared among different architectures
> of the same OS".
> this includes soundfiles, but also code that is not compiled (into
> architecture specific formats).
> as such, i don't see any problem with /usr/share/hydrogen/data/ in general.
> however, i would move stuff that is clearly not generic data up one
> level, e.g. to /usr/share/hydrogen/i18n and /usr/share/hydrogen/doc
> 
> 
> >     - no other project is doing that
> >     - it should be harmless as system data is not supposed to be accessed/modified by users
> > 
> >     $ ls -l /usr/share/ | wc -l
> >     439
> > 
> >     $ find /usr/share/ -maxdepth 2 -type d -name data
> >     /usr/share/bsdgames/data
> >     /usr/share/marble/data
> >     /usr/share/imlib2/data
> >     /usr/share/stardict/data
> >     /usr/share/gtk-doc/data
> 
> i would call that "no" projects.
> also, your personal preferences of installing software, is probably
> biasing this a lot.
> 
> ~~~
> $ apt-file find -x "^/usr/share/[^/]*/data/" | sed -e 's|^.*:
> \(/usr/share/[^/]*/data/\).*|\1|' | sort -u  | grep -c .
> 140
> $ apt-file find -l -x "^/usr/share/[^/]*/data/" | grep -c .
> 263
> ~~~
> 
> so in current Debian/sid there is a total of 263 binary packages that
> install stuff into a total of 140 /usr/share/<component>/data/ dirctories.
> this is not much, but not nothing.

but you got what I mean ;)

hier(7) :
    This directory contains subdirectories with specific application data,
    that can be shared among different architectures of the same OS

if /usr/share/<component> means 'shareable application data'
what does 'shareable application data'/data mean ?!?
it's meaningless or vague, at least unecessary.

so unless a sounding argument aginst that move,
I will eradicate 'data' from that path.

> 
> > 
> > 2-a: following the above, split it into ~/.config/hydrogen.conf and ~/.local/…
> > 
> >     - to follow xdg specification
> >     - hydrogen can easily do it at startup and notify the user
> 
> +1

I was expecting voices against that point not the share/data ;))))

> 
> > 
> > 2-ab: or at least, remove 'data' from ~/.hydrogen/data/…
> > 
> >     - hydrogen can easily do it at startup and notify the user
> > 
> > 
> > 3 : rename drumkit_pattern.xsd into pattern.xsd
> > 
> >     - unless there are big plans for other types of pattern it's just a pattern
> >     - this is system data, the change is harmless to the users
> 
> why?
> what is the gain?
> even if there are no "big plans", why would you want to actively prevent
> extensions in the future?

IMHO nothing prevents future extensions.
if one day another kind of pattern rise ( ... one day )
we will simply rename the xsd file and update filesystem.h and filesystem.cpp.

btw, what else than 'a collection of notes each linked to an instrument' could
a pattern be ?!?

I fail to see a difference between a pattern for a drum, bass, guitar, piano, whatever.
that is why I was asking for bigger plans.
( I fail to see code bringing a new kind of pattern too )

> 
> > 4 : following the above, rename <drumkit_pattern> into <pattern>
> > 
> >     - backward compatibility will obviously be preserved (loading old xml)
> > 
> 
> again:
> why?
> what is the gain?
> even if there are no "big plans", why would you want to actively prevent
> extensions in the future?
> 
> apart from that, in my drumkit_pattern.xsd i see both
> <xs:element name="pattern"/>
> <xs:element name="drumkit_pattern"/>

there is absolutly no gain, for hydrogen, neither costs,
but it is important for my sanity, I dislike xml enough, tiping is not my thing,
I like to be precise, pedantic and short, when possible.

thus : that drumkit_pattern top level should be cut off.



there is no 'actively prevent extensions' from my part,
I'm trying to improve the global shape of hydrogen ;)

thanks a lot for your feedback !

> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Hydrogen-devel mailing list
> Hyd...@li...
> https://lists.sourceforge.net/lists/listinfo/hydrogen-devel