lily4jedit-devel

[Lily4jedit-devel] Some thoughts about LilyPondTool, etc.

[Valentin V. <v.v...@gm...>]

Hi Bertalan,

I have committed a few minor changes in LPT sources (editing icons is
one of the only things I can do...) Feel free to revert whatever you
don't like :-)

Just for the record, I'm currently trying to rewrite my EasyLilyPond
as a cross-platform common launching that would allow to install and
update both LilyPond and jEdit, provide easy access to the
documentation etc.

Today, I've been having a LilyPond/jEdit install party with my pupils;
this was a huge deployment (well, a dozen laptops actually, but
still), and while explaining them how to use all this I had some
thoughts:

-- There should really be some kind of way to automatically configure
LilyTool... For instance, it could automatically detect the lilypond
binaries and the external PDF viewer (using some platform-specific
conditional code for instance; if Windows is detected, read a registry
key; if it's linux, look into /usr/bin or /usr/local/bin or ~/bin,
etc...). If you begin writing some code about it I can help with the
implementation, but of course I definitely can't do it from scratch on
my own.

Oh, by the way I can't find where the New-Score wizard localization
files are; I thought I had sent you a patch for the French translation
a year ago, but I can't find it anymore...

-- The props files you mentioned looks interesting; it would be great
if we could have a way to localize (some of) jEdit this way -- maybe
this should be considered as a separate plugin though?

I've been thinking about the integrated LilyPond Documentation, that
is currently English-only. (The "other languages" links at the bottom
of the pages are broken.)

The point is: LPT is already *huge* (in terms of size), and I'm afraid
the bundle would become too heavy if we were to include translated
docs in it... I see two solutions:

- Could we create a set of symlinks (or whatever) to allow the users
to click on "This page is available in French", and then let them see
the online docs within the JavaHelp browser?
This has two downsides:
- translated docs would be unavailable offline
- the "Automatic language selection" JavaScript would probably not
work in JavaHelp, and therefore users would be constantly brought back
to English docs.

- Could there be a way to make LilyJHelp automatically fetch the
latest doc tarball at
http://download.linuxaudio.org/lilypond/binaries/documentation/, then
expand it somewhere in ~/.jedit/downloaded-docs/, and then open it in
the browser? This would make the jar considerably lighter... and this
way users could have up-to-date docs even without updating the whole
LilyTool plugin.

-- Currently, the search function included in the help browser gives
unsorted results, most of them being from the Internals Reference and
from regtests. Could there be a way to "filter" these results, by
putting: first the Learning Manual, then the Notation Reference, and
only then the IR and things from input/*?

-- For quite some times, I've been desperately trying to make the
JPedal viewer dockable in the "perspective". You may have heard about
what Wilbert is doing with his LilyKDE project (which I haven't
tested); from what I understand, he docks the PDF preview alongside
with the code editor, and the PDF is automatically refreshed whenever
the source is compiled. It would be just great if we could have
something similar... All we need to know is the name of the
function/class/whatever to add in dockable.xml...

Cheers,
Valentin

Re: [Lily4jedit-devel] Some thoughts about LilyPondTool, etc.

[Bertalan F. <lil...@or...>]

Hi Valentin, thanks for the commits.


> -- There should really be some kind of way to automatically configure
> LilyTool... For instance, it could automatically detect the lilypond
> binaries and the external PDF viewer (using some platform-specific
> conditional code for instance; if Windows is detected, read a registry
> key; if it's linux, look into /usr/bin or /usr/local/bin or ~/bin,
> etc...). If you begin writing some code about it I can help with the
> implementation, but of course I definitely can't do it from scratch on
> my own.
>   
Well, that would not be so hard, because the operating system can be 
determined with one simple call (there is already code for this). The 
only not so trivial part is ensuring backward compatibilty, ie. don't 
break settings created by existing users (when they just update the plugin).
> Oh, by the way I can't find where the New-Score wizard localization
> files are; I thought I had sent you a patch for the French translation
> a year ago, but I can't find it anymore...
>   
I don't remember. But IIRC the patch is already applied.
> -- The props files you mentioned looks interesting; it would be great
> if we could have a way to localize (some of) jEdit this way -- maybe
> this should be considered as a separate plugin though?
>   
Yes, that's a very good idea. It would be quite easy to provide 
localizations as plugins. They could also localize all plugins which use 
the standard props file way of setting messages.
> - Could we create a set of symlinks (or whatever) to allow the users
> to click on "This page is available in French", and then let them see
> the online docs within the JavaHelp browser?
>   
No, that's not feasible.
> - Could there be a way to make LilyJHelp automatically fetch the
> latest doc tarball at
> http://download.linuxaudio.org/lilypond/binaries/documentation/, then
> expand it somewhere in ~/.jedit/downloaded-docs/, and then open it in
> the browser? This would make the jar considerably lighter... and this
> way users could have up-to-date docs even without updating the whole
> LilyTool plugin.
>   
This is the way to go. We should provide our own means of downloading 
the LilyJHelp.jar which contains the documentation.
> -- Currently, the search function included in the help browser gives
> unsorted results, most of them being from the Internals Reference and
> from regtests. Could there be a way to "filter" these results, by
> putting: first the Learning Manual, then the Notation Reference, and
> only then the IR and things from input/*?
>   
We have control on this only at generation. So we either make the 
Regression Tests and Internals Reference unsearchable or live together 
with this. For me I found no problem with this.
> -- For quite some times, I've been desperately trying to make the
> JPedal viewer dockable in the "perspective". You may have heard about
> what Wilbert is doing with his LilyKDE project (which I haven't
> tested); from what I understand, he docks the PDF preview alongside
> with the code editor, and the PDF is automatically refreshed whenever
> the source is compiled. It would be just great if we could have
> something similar... All we need to know is the name of the
> function/class/whatever to add in dockable.xml...
>   
That's not so easy, because JPedal viewer is a toplevel window and can't 
be just embedded into a dockable window panel. So we must rewrite that 
and think again about the file opening logic. Quite much work.

Bert