Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 01/08/2011 11:31, Edwin Leuven ha scritto:

Tommaso Cucinottatomm...@lyx.org  wrote:

Comments ?

no offense, but i think this feature is bloat...


perhaps the more extended explanations in:

  http://wiki.lyx.org/Devel/CreateFromEmptySample

will help in understanding the advantages of this (especially, check out 
the Advantages section).


Bye,

T.

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 01/08/2011 11:31, Edwin Leuven ha scritto:

Tommaso Cucinotta  wrote:

Comments ?

no offense, but i think this "feature" is bloat...


perhaps the more extended explanations in:

  http://wiki.lyx.org/Devel/CreateFromEmptySample

will help in understanding the advantages of this (especially, check out 
the Advantages section).


Bye,

T.

Re: Fwd: Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 16/08/2011 18:07, Liviu Andronic ha scritto:

On Tue, Aug 16, 2011 at 3:42 PM, Tommaso Cucinottatomm...@lyx.org  wrote:

as said above: with the last rework, no empty sample files are needed to be
shipped with LyX. Only if the user wants, he/she can install a few sample
empty files in .lyx/samples, and activate the create feature. Perhaps, one
might want to install multiple empty samples, and choose one of them in case
more than 1 is detected to match with the file extension (or chosen
template type, in the case of external templates).


It may make sense to add a message so that, when the user clicks on
'create' and no template is available, a window pops up to inform the
user about the location of templates on the wiki and the proper path
to install them. The wiki page could contain additional installation
instructions.


In the mean-time, I thought creating a wiki page for documentation purposes
is not too bad:

  http://wiki.lyx.org/Devel/CreateFromEmptySample

I could drop there a few templates, but I don't know how to possibly 
attach binary

elements to a wiki page. Anyone knows whether this is possible ?

Bye,

T.

Re: Fwd: Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 16/08/2011 18:07, Liviu Andronic ha scritto:

On Tue, Aug 16, 2011 at 3:42 PM, Tommaso Cucinotta  wrote:

as said above: with the last rework, no empty sample files are needed to be
shipped with LyX. Only if the user wants, he/she can install a few sample
empty files in .lyx/samples, and activate the "create" feature. Perhaps, one
might want to install multiple empty samples, and choose one of them in case
more than 1 is detected to "match" with the file extension (or chosen
template type, in the case of external templates).


It may make sense to add a message so that, when the user clicks on
'create' and no template is available, a window pops up to inform the
user about the location of templates on the wiki and the proper path
to install them. The wiki page could contain additional installation
instructions.


In the mean-time, I thought creating a wiki page for documentation purposes
is not too bad:

  http://wiki.lyx.org/Devel/CreateFromEmptySample

I could drop there a few templates, but I don't know how to possibly 
attach binary

elements to a wiki page. Anyone knows whether this is possible ?

Bye,

T.

Re: Fwd: Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 10/08/2011 18:24, Julien Rioux ha scritto:

On 06/08/2011 1:06 PM, Tommaso Cucinotta wrote:


So, in the end, is there any chance to get this patch in ? I think that
most users will at least appreciate the Edit button in the image
ext material dialogs (as witnessed by the corresponding bug in Trac).
Plus, only if they install empty samples in their .lyx folder then
they take advantage of the auto-file-creation feature.

In the case, what further changes/improvements would be needed, and when
would be a good time to commit ?


Personally, I would say that the create new feature is worthwhile, 
but the sample template files should go to the wiki, so that it is not 
in our hands to maintain and not bloating.


as said above: with the last rework, no empty sample files are needed to 
be shipped with LyX. Only if the user wants, he/she can install a few 
sample empty files in .lyx/samples, and activate the create feature. 
Perhaps, one might want to install multiple empty samples, and choose 
one of them in case more than 1 is detected to match with the file 
extension (or chosen template type, in the case of external templates).


The other feature, automatic detection, seems to have problems though.


can you detail, please ? What other feature are you referring about ? 
What problems are you experiencing ?


Thanks,

Tommaso

Re: Fwd: Re: Image Lifecycle (Create) Patch - Video

[Julien Rioux]

On 16/08/2011 9:42 AM, Tommaso Cucinotta wrote:

Il 10/08/2011 18:24, Julien Rioux ha scritto:

On 06/08/2011 1:06 PM, Tommaso Cucinotta wrote:


So, in the end, is there any chance to get this patch in ? I think that
most users will at least appreciate the Edit button in the image
ext material dialogs (as witnessed by the corresponding bug in Trac).
Plus, only if they install empty samples in their .lyx folder then
they take advantage of the auto-file-creation feature.

In the case, what further changes/improvements would be needed, and when
would be a good time to commit ?


Personally, I would say that the create new feature is worthwhile,
but the sample template files should go to the wiki, so that it is not
in our hands to maintain and not bloating.


as said above: with the last rework, no empty sample files are needed to
be shipped with LyX. Only if the user wants, he/she can install a few
sample empty files in .lyx/samples, and activate the create feature.
Perhaps, one might want to install multiple empty samples, and choose
one of them in case more than 1 is detected to match with the file
extension (or chosen template type, in the case of external templates).


One sample file should be enough for now.



The other feature, automatic detection, seems to have problems though.


can you detail, please ? What other feature are you referring about ?
What problems are you experiencing ?



See Pavel's message in this thread.


Thanks,

Tommaso



--
Julien

Re: Fwd: Re: Image Lifecycle (Create) Patch - Video

[Liviu Andronic]

Hello

On Tue, Aug 16, 2011 at 3:42 PM, Tommaso Cucinotta tomm...@lyx.org wrote:
 Personally, I would say that the create new feature is worthwhile, but
 the sample template files should go to the wiki, so that it is not in our
 hands to maintain and not bloating.

 as said above: with the last rework, no empty sample files are needed to be
 shipped with LyX. Only if the user wants, he/she can install a few sample
 empty files in .lyx/samples, and activate the create feature. Perhaps, one
 might want to install multiple empty samples, and choose one of them in case
 more than 1 is detected to match with the file extension (or chosen
 template type, in the case of external templates).

It may make sense to add a message so that, when the user clicks on
'create' and no template is available, a window pops up to inform the
user about the location of templates on the wiki and the proper path
to install them. The wiki page could contain additional installation
instructions.

Regards
Liviu

Re: Fwd: Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 10/08/2011 18:24, Julien Rioux ha scritto:

On 06/08/2011 1:06 PM, Tommaso Cucinotta wrote:


So, in the end, is there any chance to get this patch in ? I think that
most users will at least appreciate the "Edit" button in the image&
ext material dialogs (as witnessed by the corresponding bug in Trac).
Plus, only if they install empty samples in their .lyx folder then
they take advantage of the auto-file-creation feature.

In the case, what further changes/improvements would be needed, and when
would be a good time to commit ?


Personally, I would say that the "create new" feature is worthwhile, 
but the sample template files should go to the wiki, so that it is not 
in our hands to maintain and not bloating.


as said above: with the last rework, no empty sample files are needed to 
be shipped with LyX. Only if the user wants, he/she can install a few 
sample empty files in .lyx/samples, and activate the "create" feature. 
Perhaps, one might want to install multiple empty samples, and choose 
one of them in case more than 1 is detected to "match" with the file 
extension (or chosen template type, in the case of external templates).


The other feature, automatic detection, seems to have problems though.


can you detail, please ? What "other feature" are you referring about ? 
What problems are you experiencing ?


Thanks,

Tommaso

Re: Fwd: Re: Image Lifecycle (Create) Patch - Video

[Julien Rioux]

On 16/08/2011 9:42 AM, Tommaso Cucinotta wrote:

Il 10/08/2011 18:24, Julien Rioux ha scritto:

On 06/08/2011 1:06 PM, Tommaso Cucinotta wrote:


So, in the end, is there any chance to get this patch in ? I think that
most users will at least appreciate the "Edit" button in the image&
ext material dialogs (as witnessed by the corresponding bug in Trac).
Plus, only if they install empty samples in their .lyx folder then
they take advantage of the auto-file-creation feature.

In the case, what further changes/improvements would be needed, and when
would be a good time to commit ?


Personally, I would say that the "create new" feature is worthwhile,
but the sample template files should go to the wiki, so that it is not
in our hands to maintain and not bloating.


as said above: with the last rework, no empty sample files are needed to
be shipped with LyX. Only if the user wants, he/she can install a few
sample empty files in .lyx/samples, and activate the "create" feature.
Perhaps, one might want to install multiple empty samples, and choose
one of them in case more than 1 is detected to "match" with the file
extension (or chosen template type, in the case of external templates).


One sample file should be enough for now.



The other feature, automatic detection, seems to have problems though.


can you detail, please ? What "other feature" are you referring about ?
What problems are you experiencing ?



See Pavel's message in this thread.


Thanks,

Tommaso



--
Julien

Re: Fwd: Re: Image Lifecycle (Create) Patch - Video

[Liviu Andronic]

Hello

On Tue, Aug 16, 2011 at 3:42 PM, Tommaso Cucinotta  wrote:
>> Personally, I would say that the "create new" feature is worthwhile, but
>> the sample template files should go to the wiki, so that it is not in our
>> hands to maintain and not bloating.
>
> as said above: with the last rework, no empty sample files are needed to be
> shipped with LyX. Only if the user wants, he/she can install a few sample
> empty files in .lyx/samples, and activate the "create" feature. Perhaps, one
> might want to install multiple empty samples, and choose one of them in case
> more than 1 is detected to "match" with the file extension (or chosen
> template type, in the case of external templates).
>
It may make sense to add a message so that, when the user clicks on
'create' and no template is available, a window pops up to inform the
user about the location of templates on the wiki and the proper path
to install them. The wiki page could contain additional installation
instructions.

Regards
Liviu

Re: Fwd: Re: Image Lifecycle (Create) Patch - Video

[Julien Rioux]

On 06/08/2011 1:06 PM, Tommaso Cucinotta wrote:

Il 31/07/2011 22:18, Tommaso Cucinotta ha scritto:


If you agree, a nice trade-off could be for LyX:
1) to be shipped without any binary blob;
2) to allow users for placing empty sample files in their
$HOME/.lyx/samples folder, then being automatically recognized by this
feature and being proposed as empty templates for new material
(feature to be documented in the manual and its existence properly
advertised in the tooltip of the Edit/Create button).
3) [optional]: to provide a separate package file lyx-samples,
shipping a bunch of empty files, that a user might try to optionally
install.


So, in the end, is there any chance to get this patch in ? I think that
most users will at least appreciate the Edit button in the image
ext material dialogs (as witnessed by the corresponding bug in Trac).
Plus, only if they install empty samples in their .lyx folder then
they take advantage of the auto-file-creation feature.

In the case, what further changes/improvements would be needed, and when
would be a good time to commit ?

On a related note, what's the current development/releasing status of
(the upcoming versions of) LyX ?

Thx,

T.




Personally, I would say that the create new feature is worthwhile, but 
the sample template files should go to the wiki, so that it is not in 
our hands to maintain and not bloating.


The other feature, automatic detection, seems to have problems though.

--
Julien

Re: Fwd: Re: Image Lifecycle (Create) Patch - Video

[Julien Rioux]

On 06/08/2011 1:06 PM, Tommaso Cucinotta wrote:

Il 31/07/2011 22:18, Tommaso Cucinotta ha scritto:


If you agree, a nice trade-off could be for LyX:
1) to be shipped without any binary blob;
2) to allow users for placing empty sample files in their
$HOME/.lyx/samples folder, then being automatically recognized by this
feature and being proposed as empty templates for new material
(feature to be documented in the manual and its existence properly
advertised in the tooltip of the "Edit/Create" button).
3) [optional]: to provide a separate package file "lyx-samples",
shipping a bunch of empty files, that a user might try to optionally
install.


So, in the end, is there any chance to get this patch in ? I think that
most users will at least appreciate the "Edit" button in the image&
ext material dialogs (as witnessed by the corresponding bug in Trac).
Plus, only if they install empty samples in their .lyx folder then
they take advantage of the auto-file-creation feature.

In the case, what further changes/improvements would be needed, and when
would be a good time to commit ?

On a related note, what's the current development/releasing status of
(the upcoming versions of) LyX ?

Thx,

T.




Personally, I would say that the "create new" feature is worthwhile, but 
the sample template files should go to the wiki, so that it is not in 
our hands to maintain and not bloating.


The other feature, automatic detection, seems to have problems though.

--
Julien

Re: Fwd: Re: Image Lifecycle (Create) Patch - Video

[Pavel Sanda]

Tommaso Cucinotta wrote:
 In the case, what further changes/improvements would be needed, and when

currently i'm no more able to insert .eps figs without some warning messages 
about
It was not possible to infer the format from the file contents or its name.
edit/create is not enabled even when the file exists.
when going to external material browse for .dia file and trying to edit it
lyx asserts.

On a related note, what's the current development/releasing status of
(the upcoming versions of) LyX ?

the feature seems to be somewhat controversial, but i'm no more the right one
to be CC-ed, Vincent took the command.

pavel

Re: Fwd: Re: Image Lifecycle (Create) Patch - Video

[Pavel Sanda]

Tommaso Cucinotta wrote:
> In the case, what further changes/improvements would be needed, and when

currently i'm no more able to insert .eps figs without some warning messages 
about
"It was not possible to infer the format from the file contents or its name."
edit/create is not enabled even when the file exists.
when going to external material browse for .dia file and trying to edit it
lyx asserts.

>On a related note, what's the current development/releasing status of
>(the upcoming versions of) LyX ?

the feature seems to be somewhat controversial, but i'm no more the right one
to be CC-ed, Vincent took the command.

pavel

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 01/08/2011 11:31, Edwin Leuven ha scritto:

no offense, but i think this feature is bloat...


I don't have at reach the numbers showing increases in:
-) compiled files size (or size of additional files to ship)
-) compilation-time
-) memory occupation

as due to this patch, especially if you consider not shipping any 
additional binary file with LyX itself, as I proposed last. However, I 
suspect those 3 numbers would be pretty low to talk about bloat.


T.

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 01/08/2011 11:31, Edwin Leuven ha scritto:

no offense, but i think this "feature" is bloat...


I don't have at reach the numbers showing increases in:
-) compiled files size (or size of additional files to ship)
-) compilation-time
-) memory occupation

as due to this patch, especially if you consider not shipping any 
additional binary file with LyX itself, as I proposed last. However, I 
suspect those 3 numbers would be pretty low to talk about "bloat".


T.

Re: Image Lifecycle (Create) Patch - Video

[Edwin Leuven]

Tommaso Cucinotta tomm...@lyx.org wrote:
 Comments ?

no offense, but i think this feature is bloat...

best, edwin

Re: Image Lifecycle (Create) Patch - Video

[Edwin Leuven]

Tommaso Cucinotta  wrote:
> Comments ?

no offense, but i think this "feature" is bloat...

best, edwin

Re: Image Lifecycle (Create) Patch - Video

[Pavel Sanda]

Tommaso Cucinotta wrote:
 Still, the easiest thing to do seems to be shipping a few binary files 

when we are talking about the easiest thing - for which application you actually
need this 'new' feature?
it might be that it already knows creating new file, when called with file
argument - as lyx is doing (or it could well be accepted by its developers).

then the edit/create button could be joined and we wouldn't need any
binary blobs.
pavel

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 31/07/2011 20:33, Pavel Sanda ha scritto:

when we are talking about the easiest thing - for which application you actually
need this 'new' feature?
it might be that it already knows creating new file, when called with file
argument - as lyx is doing (or it could well be accepted by its developers).


for GUI-based applications allowing a user to edit a picture in WYSIWYG 
mode, it doesn't seem that creating a new file as a result of being 
launched from the command-line with a non-existing file-name is among 
the topmost implemented feature :-)


Btw:
-) dia: error message, and new file with a default proposed name of 
Diagram1.dia, and defaulting to being saved in the current folder
-) LibreOffice: error message, and it doesn't even start. If started 
without args (-draw, actually), then new file with default name of 
Untitled 1, to be saved into the HOME/Documents folder
-) inkscape: error message, and new file with a default proposed name of 
New document 1, defaulting to being saved in the HOME user folder

-) gimp: error message, new file defaulting to Untitled in current folder

XFig supports that feature, but its UI is (for me) unusable.

So, how many graphics editors do support such a feature :-) ? For me, 
it's easier to patch LyX than all of the above! Btw, I mostly used dia, 
LibreOffice and Inkscape for my papers.


Every editor, spawned either from the command-line or from its icon, 
proposes a different folder where to save the new created file, from 
where I have to move over and over again to my working folder where I'm 
editing the .lyx file. So, not only I have to browse when I open my .lyx 
file that I'm editing, but additionally I also have to browse every time 
I insert an image (or having to use the terminal from another window to 
move files into proper locations all the time). With the patch I'm 
proposing, it all gets simpler, more immediate, less time wasted 
browsing, more time on doing useful things.

then the edit/create button could be joined and we wouldn't need any
binary blobs.


If you agree, a nice trade-off could be for LyX:
1) to be shipped without any binary blob;
2) to allow users for placing empty sample files in their 
$HOME/.lyx/samples folder, then being automatically recognized by this 
feature and being proposed as empty templates for new material (feature 
to be documented in the manual and its existence properly advertised in 
the tooltip of the Edit/Create button).
3) [optional]: to provide a separate package file lyx-samples, 
shipping a bunch of empty files, that a user might try to optionally 
install.


For command-line and file-browser lovers, it would simply work as before 
-- no change at all, no binary blobs, no format compatibility errors, 
etc.. Except that they would get the Edit button in those 2 dialogs 
(graphics and external material) working for free as a side effect :-)!


What do you think ? Would that work ?

Thanks,

T.

Re: Image Lifecycle (Create) Patch - Video

[Pavel Sanda]

Tommaso Cucinotta wrote:
> Still, the easiest thing to do seems to be shipping a few binary files 

when we are talking about the easiest thing - for which application you actually
need this 'new' feature?
it might be that it already knows creating new file, when called with file
argument - as lyx is doing (or it could well be accepted by its developers).

then the edit/create button could be joined and we wouldn't need any
binary blobs.
pavel

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 31/07/2011 20:33, Pavel Sanda ha scritto:

when we are talking about the easiest thing - for which application you actually
need this 'new' feature?
it might be that it already knows creating new file, when called with file
argument - as lyx is doing (or it could well be accepted by its developers).


for GUI-based applications allowing a user to edit a picture in WYSIWYG 
mode, it doesn't seem that creating a new file as a result of being 
launched from the command-line with a non-existing file-name is among 
the topmost implemented feature :-)


Btw:
-) dia: error message, and new file with a default proposed name of 
"Diagram1.dia", and defaulting to being saved in the current folder
-) LibreOffice: error message, and it doesn't even start. If started 
without args (-draw, actually), then new file with default name of 
"Untitled 1", to be saved into the HOME/Documents folder
-) inkscape: error message, and new file with a default proposed name of 
"New document 1", defaulting to being saved in the HOME user folder

-) gimp: error message, new file defaulting to "Untitled" in current folder

XFig supports that feature, but its UI is (for me) unusable.

So, how many graphics editors do support such a feature :-) ? For me, 
it's easier to patch LyX than all of the above! Btw, I mostly used dia, 
LibreOffice and Inkscape for my papers.


Every editor, spawned either from the command-line or from its icon, 
proposes a different folder where to save the new created file, from 
where I have to move over and over again to my working folder where I'm 
editing the .lyx file. So, not only I have to browse when I open my .lyx 
file that I'm editing, but additionally I also have to browse every time 
I insert an image (or having to use the terminal from another window to 
move files into proper locations all the time). With the patch I'm 
proposing, it all gets simpler, more immediate, less time wasted 
browsing, more time on doing useful things.

then the edit/create button could be joined and we wouldn't need any
binary blobs.


If you agree, a nice trade-off could be for LyX:
1) to be shipped without any binary blob;
2) to allow users for placing empty sample files in their 
$HOME/.lyx/samples folder, then being automatically recognized by this 
feature and being proposed as empty templates for new material (feature 
to be documented in the manual and its existence properly advertised in 
the tooltip of the "Edit/Create" button).
3) [optional]: to provide a separate package file "lyx-samples", 
shipping a bunch of empty files, that a user might try to optionally 
install.


For command-line and file-browser lovers, it would simply work as before 
-- no change at all, no binary blobs, no format compatibility errors, 
etc.. Except that they would get the "Edit" button in those 2 dialogs 
(graphics and external material) working for free as a side effect :-)!


What do you think ? Would that work ?

Thanks,

T.

Re: Image Lifecycle (Create) Patch - Video

[Edwin Leuven]

Tommaso Cucinotta tomm...@lyx.org wrote:
 actually, in the previous patch on the Trac by Vincent (which I discovered
 later, when I seeked for a place on Trac where to drop my own patch), the
 mouse coordinates are used to decide where to actually drop.

that's how it should be. could you use that code in your patch?

 Even though, I don't know if that patch gives you the usual visual
 feedback (I guess you're referring to a kind of cursor showing in the
 document where the image is being placed while you're dragging it before
 dropping).

yes

ed.

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 30/07/2011 06:48, Jens Nöckel ha scritto:

To me it seems that this could be a great job for an external launcher utility 
or an operating system service, but not a feature that LyX should be 
responsible for. I guess Nautilus proves this point. Sorry to be so 
conservative about this, but for LyX to start shipping binary template files of 
a myriad other programs seems the wrong approach (not to mention all those 
hard-coded file extensions).

How about creating a separate launcher application with all those templates and 
the mechanism for recognizing extensions. The user could (optionally) install 
it separately from LyX, and its presence could be detected by LyX at 
reconfigure time. Then at least one would have decoupled updating and 
development of LyX and this launcher application.


Hi,

I understand very well the rationale of your proposal, and I have to 
admit I would love it, in principle. Not only, I would push it further: 
take out of LyX the whole logic concerning file-format detection, 
conversion and launching of external editors, and just leave that job to 
such an external utility. For example, this external tool (one or more) 
could have not only the ability to detect file formats, but also to 
understand which editors/viewers are installed on the system (e.g., what 
configure.py does now for LyX), the ability to launch the proper 
viewer/editor for a given file type (e.g., what gnome-open and kde-open 
already do), to convert files from one format to another (a'la convert 
from ImageMagick, but not only images -- also spreadsheets and other LyX 
external material), etc. With a proper integration via command-line or a 
specific API (better), such a tool/library could be useful in a number 
of ways across the OS.


However, LyX for now embeds all that logic about formats and 
conversions, and is already aware of external applications (viewers, 
editors, converters) that are installed on the OS. Therefore, I don't 
see too much of a big and dangerous step if we also ship a few empty 
samples with it. Actually, it's of course simpler (for me) to think of 
this last kind of step than the one formerly sketched out above :-).


Bye,

T.

Re: Image Lifecycle (Create) Patch - Video

[Edwin Leuven]

Tommaso Cucinotta  wrote:
> actually, in the previous patch on the Trac by Vincent (which I discovered
> later, when I seeked for a place on Trac where to drop my own patch), the
> mouse coordinates are used to decide where to actually drop.

that's how it should be. could you use that code in your patch?

> Even though, I don't know if that patch gives you the "usual visual
> feedback" (I guess you're referring to a kind of cursor showing in the
> document where the image is being placed while you're dragging it before
> dropping).

yes

ed.

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 30/07/2011 06:48, Jens Nöckel ha scritto:

To me it seems that this could be a great job for an external launcher utility 
or an operating system service, but not a feature that LyX should be 
responsible for. I guess Nautilus proves this point. Sorry to be so 
conservative about this, but for LyX to start shipping binary template files of 
a myriad other programs seems the wrong approach (not to mention all those 
hard-coded file extensions).

How about creating a separate launcher application with all those templates and 
the mechanism for recognizing extensions. The user could (optionally) install 
it separately from LyX, and its presence could be detected by LyX at 
reconfigure time. Then at least one would have decoupled updating and 
development of LyX and this launcher application.


Hi,

I understand very well the rationale of your proposal, and I have to 
admit I would love it, in principle. Not only, I would push it further: 
take out of LyX the whole logic concerning file-format detection, 
conversion and launching of external editors, and just leave that job to 
such an external utility. For example, this external tool (one or more) 
could have not only the ability to detect file formats, but also to 
understand which editors/viewers are installed on the system (e.g., what 
configure.py does now for LyX), the ability to launch the proper 
viewer/editor for a given file type (e.g., what gnome-open and kde-open 
already do), to convert files from one format to another (a'la convert 
from ImageMagick, but not only images -- also spreadsheets and other LyX 
external material), etc. With a proper integration via command-line or a 
specific API (better), such a tool/library could be useful in a number 
of ways across the OS.


However, LyX for now embeds all that logic about formats and 
conversions, and is already aware of external applications (viewers, 
editors, converters) that are installed on the OS. Therefore, I don't 
see too much of a big and dangerous step if we also ship a few empty 
samples with it. Actually, it's of course simpler (for me) to think of 
this last kind of step than the one formerly sketched out above :-).


Bye,

T.

Re: Image Lifecycle (Create) Patch - Video

[Pavel Sanda]

Tommaso Cucinotta wrote:
 I'd like to gather comments on this, whether it may be acceptable for the 

the current workflow was more towards that one have figures sort-of-prepared
before writing, but we could allow another workflow as well.

for the technical part i feel uncomfortable the we should ship bunch of
empty binaries file and need to manage proper versions of them. if have
older version of third party app which doesn't load it well? if the conversion
from older version has glitches? and so on...

pavel

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 29/07/2011 11:04, Pavel Sanda ha scritto:

Tommaso Cucinotta wrote:

I'd like to gather comments on this, whether it may be acceptable for the

for the technical part i feel uncomfortable the we should ship bunch of
empty binaries file and need to manage proper versions of them. if have
older version of third party app which doesn't load it well? if the conversion
from older version has glitches? and so on...


I understand your concerns, that's why I was also proposing to have
maybe more versions of the same empty file type, corresponding to
different versions of the file-format (and corresponding application),
in order to be more compatible with possible old applications installed
on a system.

However, even without this addition, this feature would still be useful
and work most of the times, and perhaps some times fail in creating
a proper new file. In such a case the user can:
-) go with the traditional LyX workflow, i.e., launch the external app
   independently, save the file to the proper place, then include it
   in the LyX doc
-) customise LyX so as to have his/her own empty templates in the
.lyx/samples/ folder, which are matching the type and version of
the application he/she is using and so that would work 100% of
the times.

On a related note, I just checked how it works on Nautilus (Gnome
[right-click]-[Create Document] feature). There, the user is supposed
to have a $HOME/Templates folder in which he/she places the
template files to be used, then they show up in the right-click menu
(so the whole feature relies on the user making an explicit configuration
option -- that folder is normally empty).

Also, on KDE, I found this package: Create-New-OpenOffice.org-Document,
which contains templates and context menu entries for KDE and 
OpenOffice.org3.

Now you can right click in file manager or desktop and generate a new file.

So, there seems to be a common need across different applications for
creating new files from existing templates. Shipping each application distro
with an empty file in a well-known folder such as /usr/share/templates
would solve this problem, but unfortunately it doesn't happen.

Still, the easiest thing to do seems to be shipping a few binary files 
(e.g.,

one per supported file-format) with LyX itself.

T.

Re: Image Lifecycle (Create) Patch - Video

[Jens Nöckel]

To me it seems that this could be a great job for an external launcher utility 
or an operating system service, but not a feature that LyX should be 
responsible for. I guess Nautilus proves this point. Sorry to be so 
conservative about this, but for LyX to start shipping binary template files of 
a myriad other programs seems the wrong approach (not to mention all those 
hard-coded file extensions). 

How about creating a separate launcher application with all those templates and 
the mechanism for recognizing extensions. The user could (optionally) install 
it separately from LyX, and its presence could be detected by LyX at 
reconfigure time. Then at least one would have decoupled updating and 
development of LyX and this launcher application. 

I would imagine the following solution (probably needs corrections):

(a)
In the Graphics Insert dialog, the option to create a new file from a filename 
that doesn't point to an existing file would appear if the launcher application 
is also installed. 

(b)
Then, if the user says Yes, create a new file, LyX would send that filename 
(including absolute path) to the launcher application.

(c) 
The launcher application receives the filename, decides which external program 
to launch and which template to use. When it gets the result, it moves that to 
the specified filename at the specified absolute path. 

(d)
Finally, the launcher application sends the confirmation back to LyX, through 
the lyxpipe.in mechanism. Upon receiving this, if there was no error, LyX 
inserts the newly created file. 

So LyX only needs to implement the functionality to call the launcher 
application, and to receive the confirmation message in lyxpipe.in
The rest of the dirty work is done in the launcher application. This has the 
additional advantage that the launcher application could then potentially be 
re-used in other programs, depending on the creativity of the developer. All 
the customization you speak of could then be done in a directory outside of LyX 
responsibility.

Jens

On Jul 29, 2011, at 7:42 PM, Tommaso Cucinotta wrote:

 Il 29/07/2011 11:04, Pavel Sanda ha scritto:
 Tommaso Cucinotta wrote:
 I'd like to gather comments on this, whether it may be acceptable for the
 for the technical part i feel uncomfortable the we should ship bunch of
 empty binaries file and need to manage proper versions of them. if have
 older version of third party app which doesn't load it well? if the 
 conversion
 from older version has glitches? and so on...
 
 I understand your concerns, that's why I was also proposing to have
 maybe more versions of the same empty file type, corresponding to
 different versions of the file-format (and corresponding application),
 in order to be more compatible with possible old applications installed
 on a system.
 
 However, even without this addition, this feature would still be useful
 and work most of the times, and perhaps some times fail in creating
 a proper new file. In such a case the user can:
 -) go with the traditional LyX workflow, i.e., launch the external app
   independently, save the file to the proper place, then include it
   in the LyX doc
 -) customise LyX so as to have his/her own empty templates in the
.lyx/samples/ folder, which are matching the type and version of
the application he/she is using and so that would work 100% of
the times.
 
 On a related note, I just checked how it works on Nautilus (Gnome
 [right-click]-[Create Document] feature). There, the user is supposed
 to have a $HOME/Templates folder in which he/she places the
 template files to be used, then they show up in the right-click menu
 (so the whole feature relies on the user making an explicit configuration
 option -- that folder is normally empty).
 
 Also, on KDE, I found this package: Create-New-OpenOffice.org-Document,
 which contains templates and context menu entries for KDE and 
 OpenOffice.org3.
 Now you can right click in file manager or desktop and generate a new file.
 
 So, there seems to be a common need across different applications for
 creating new files from existing templates. Shipping each application distro
 with an empty file in a well-known folder such as /usr/share/templates
 would solve this problem, but unfortunately it doesn't happen.
 
 Still, the easiest thing to do seems to be shipping a few binary files (e.g.,
 one per supported file-format) with LyX itself.
 
T.
 

Re: Image Lifecycle (Create) Patch - Video

[Pavel Sanda]

Tommaso Cucinotta wrote:
> I'd like to gather comments on this, whether it may be acceptable for the 

the current workflow was more towards that one have figures sort-of-prepared
before writing, but we could allow another workflow as well.

for the technical part i feel uncomfortable the we should ship bunch of
empty binaries file and need to manage proper versions of them. if have
older version of third party app which doesn't load it well? if the conversion
from older version has glitches? and so on...

pavel

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 29/07/2011 11:04, Pavel Sanda ha scritto:

Tommaso Cucinotta wrote:

I'd like to gather comments on this, whether it may be acceptable for the

for the technical part i feel uncomfortable the we should ship bunch of
empty binaries file and need to manage proper versions of them. if have
older version of third party app which doesn't load it well? if the conversion
from older version has glitches? and so on...


I understand your concerns, that's why I was also proposing to have
maybe more versions of the same empty file type, corresponding to
different versions of the file-format (and corresponding application),
in order to be more compatible with possible old applications installed
on a system.

However, even without this addition, this feature would still be useful
and work most of the times, and perhaps some times fail in creating
a proper new file. In such a case the user can:
-) go with the traditional LyX workflow, i.e., launch the external app
   independently, save the file to the proper place, then include it
   in the LyX doc
-) customise LyX so as to have his/her own empty templates in the
.lyx/samples/ folder, which are matching the type and version of
the application he/she is using and so that would work 100% of
the times.

On a related note, I just checked how it works on Nautilus (Gnome
[right-click]->[Create Document] feature). There, the user is supposed
to have a "$HOME/Templates" folder in which he/she places the
template files to be used, then they show up in the right-click menu
(so the whole feature relies on the user making an explicit configuration
option -- that folder is normally empty).

Also, on KDE, I found this package: "Create-New-OpenOffice.org-Document",
which "contains templates and context menu entries for KDE and 
OpenOffice.org3.

Now you can right click in file manager or desktop and generate a new file."

So, there seems to be a common need across different applications for
creating new files from existing templates. Shipping each application distro
with an empty file in a well-known folder such as /usr/share/templates
would solve this problem, but unfortunately it doesn't happen.

Still, the easiest thing to do seems to be shipping a few binary files 
(e.g.,

one per supported file-format) with LyX itself.

T.

Re: Image Lifecycle (Create) Patch - Video

[Jens Nöckel]

To me it seems that this could be a great job for an external launcher utility 
or an operating system service, but not a feature that LyX should be 
responsible for. I guess Nautilus proves this point. Sorry to be so 
conservative about this, but for LyX to start shipping binary template files of 
a myriad other programs seems the wrong approach (not to mention all those 
hard-coded file extensions). 

How about creating a separate launcher application with all those templates and 
the mechanism for recognizing extensions. The user could (optionally) install 
it separately from LyX, and its presence could be detected by LyX at 
reconfigure time. Then at least one would have decoupled updating and 
development of LyX and this launcher application. 

I would imagine the following solution (probably needs corrections):

(a)
In the Graphics Insert dialog, the option to create a new file from a filename 
that doesn't point to an existing file would appear if the launcher application 
is also installed. 

(b)
Then, if the user says "Yes, create a new file", LyX would send that filename 
(including absolute path) to the launcher application.

(c) 
The launcher application receives the filename, decides which external program 
to launch and which template to use. When it gets the result, it moves that to 
the specified filename at the specified absolute path. 

(d)
Finally, the launcher application sends the confirmation back to LyX, through 
the lyxpipe.in mechanism. Upon receiving this, if there was no error, LyX 
inserts the newly created file. 

So LyX only needs to implement the functionality to call the launcher 
application, and to receive the confirmation message in lyxpipe.in
The rest of the "dirty work" is done in the launcher application. This has the 
additional advantage that the launcher application could then potentially be 
re-used in other programs, depending on the creativity of the developer. All 
the customization you speak of could then be done in a directory outside of LyX 
responsibility.

Jens

On Jul 29, 2011, at 7:42 PM, Tommaso Cucinotta wrote:

> Il 29/07/2011 11:04, Pavel Sanda ha scritto:
>> Tommaso Cucinotta wrote:
>>> I'd like to gather comments on this, whether it may be acceptable for the
>> for the technical part i feel uncomfortable the we should ship bunch of
>> empty binaries file and need to manage proper versions of them. if have
>> older version of third party app which doesn't load it well? if the 
>> conversion
>> from older version has glitches? and so on...
> 
> I understand your concerns, that's why I was also proposing to have
> maybe more versions of the same empty file type, corresponding to
> different versions of the file-format (and corresponding application),
> in order to be more compatible with possible old applications installed
> on a system.
> 
> However, even without this addition, this feature would still be useful
> and work most of the times, and perhaps some times fail in creating
> a proper new file. In such a case the user can:
> -) go with the traditional LyX workflow, i.e., launch the external app
>   independently, save the file to the proper place, then include it
>   in the LyX doc
> -) customise LyX so as to have his/her own empty templates in the
>.lyx/samples/ folder, which are matching the type and version of
>the application he/she is using and so that would work 100% of
>the times.
> 
> On a related note, I just checked how it works on Nautilus (Gnome
> [right-click]->[Create Document] feature). There, the user is supposed
> to have a "$HOME/Templates" folder in which he/she places the
> template files to be used, then they show up in the right-click menu
> (so the whole feature relies on the user making an explicit configuration
> option -- that folder is normally empty).
> 
> Also, on KDE, I found this package: "Create-New-OpenOffice.org-Document",
> which "contains templates and context menu entries for KDE and 
> OpenOffice.org3.
> Now you can right click in file manager or desktop and generate a new file."
> 
> So, there seems to be a common need across different applications for
> creating new files from existing templates. Shipping each application distro
> with an empty file in a well-known folder such as /usr/share/templates
> would solve this problem, but unfortunately it doesn't happen.
> 
> Still, the easiest thing to do seems to be shipping a few binary files (e.g.,
> one per supported file-format) with LyX itself.
> 
>T.
> 

Re: Image Lifecycle (Create) Patch - Video

[Edwin Leuven]

Tommaso Cucinotta tomm...@lyx.org wrote:
  This patch allows one to quickly insert new images
  and other type of external material into a LyX document.

fwiw, i'd rather be able to drag-n-drop

ed.

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 28/07/2011 17:29, Edwin Leuven ha scritto:

Tommaso Cucinottatomm...@lyx.org  wrote:

  This patch allows one to quickly insert new images
  and other type of external material into a LyX document.

fwiw, i'd rather be able to drag-n-drop


they are compatible: one way doesn't preclude that the other can be 
realised as well.


T.

Re: Image Lifecycle (Create) Patch - Video

[Xu Wang]

Tomasso,

This looks great! Also, sending an email is a great way to show what your
new feature does. I think more bug reports and/or fixes should have videos
attached.

Thanks, Xu

On Thu, Jul 28, 2011 at 2:29 PM, Tommaso Cucinotta tomm...@lyx.org wrote:

 Il 28/07/2011 17:29, Edwin Leuven ha scritto:

  Tommaso Cucinottatomm...@lyx.org  wrote:

  This patch allows one to quickly insert new images
  and other type of external material into a LyX document.

 fwiw, i'd rather be able to drag-n-drop


 they are compatible: one way doesn't preclude that the other can be
 realised as well.

T.

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 28/07/2011 17:29, Edwin Leuven ha scritto:

Tommaso Cucinottatomm...@lyx.org  wrote:

  This patch allows one to quickly insert new images
  and other type of external material into a LyX document.

fwiw, i'd rather be able to drag-n-drop


Please, try the attached (preliminary) patch.

If you drag'n'drop at least .eps, .fig, .dia, .png files, then they get 
automatically inserted as InsetGraphics, and immediately previewed in 
LyX. If you drag'n'drop a .lyx file, then it is regularly opened.


Is this that you meant ?

And, the funny part, is that the patch was *mainly a removal of code*. 
Comments ?


T.

Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp	(revisione 39381)
+++ src/frontends/qt4/GuiView.cpp	(copia locale)
@@ -893,12 +893,10 @@
 		vectorconst Format * found_formats;
 
 		// Find all formats that have the correct extension.
-		vectorconst Format * const  import_formats
-			= theConverters().importableFormats();
-		vectorconst Format *::const_iterator it = import_formats.begin();
-		for (; it != import_formats.end(); ++it)
-			if ((*it)-extension() == ext)
-found_formats.push_back(*it);
+		Formats::const_iterator it = formats.begin();
+		for (; it != formats.end(); ++it)
+			if (it-extension() == ext  it-name() != lyx)
+found_formats.push_back((*it));
 
 		FuncRequest cmd;
 		if (found_formats.size() = 1) {
@@ -2087,6 +2085,19 @@
 	if (filename.empty())
 		return;
 
+	FileName fname(filename);
+	if (formats.getFormatFromFile(fname) != lyx) {
+		if (!currentBufferView()) {
+			Alert::warning(_(Error), _(Need an open document where to insert));
+			return;
+		}
+		string args = string(graphics filename ) + filename;
+		FuncRequest cmd(LFUN_INSET_INSERT, args);
+		LYXERR(Debug::DEBUG, Dispatching:   cmd);
+		lyx::dispatch(cmd);
+		return;
+	}
+
 	// get absolute path of file
 	FileName const fullname(support::makeAbsPath(filename));
 

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 29/07/2011 01:19, Tommaso Cucinotta ha scritto:

Il 28/07/2011 17:29, Edwin Leuven ha scritto:

Tommaso Cucinottatomm...@lyx.org  wrote:

  This patch allows one to quickly insert new images
  and other type of external material into a LyX document.

fwiw, i'd rather be able to drag-n-drop


Please, try the attached (preliminary) patch.


btw, there was also another patch by vfr on the Trac for this:

   http://www.lyx.org/trac/ticket/4017

Bye,

T.

Re: Image Lifecycle (Create) Patch - Video

[Edwin Leuven]

Tommaso Cucinotta  wrote:
>  This patch allows one to quickly insert new images
>  and other type of external material into a LyX document.

fwiw, i'd rather be able to drag-n-drop

ed.

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 28/07/2011 17:29, Edwin Leuven ha scritto:

Tommaso Cucinotta  wrote:

  This patch allows one to quickly insert new images
  and other type of external material into a LyX document.

fwiw, i'd rather be able to drag-n-drop


they are compatible: one way doesn't preclude that the other can be 
realised as well.


T.

Re: Image Lifecycle (Create) Patch - Video

[Xu Wang]

Tomasso,

This looks great! Also, sending an email is a great way to show what your
new feature does. I think more bug reports and/or fixes should have videos
attached.

Thanks, Xu

On Thu, Jul 28, 2011 at 2:29 PM, Tommaso Cucinotta  wrote:

> Il 28/07/2011 17:29, Edwin Leuven ha scritto:
>
>  Tommaso Cucinotta  wrote:
>>
>>>  This patch allows one to quickly insert new images
>>>  and other type of external material into a LyX document.
>>>
>> fwiw, i'd rather be able to drag-n-drop
>>
>
> they are compatible: one way doesn't preclude that the other can be
> realised as well.
>
>T.
>
>

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 28/07/2011 17:29, Edwin Leuven ha scritto:

Tommaso Cucinotta  wrote:

  This patch allows one to quickly insert new images
  and other type of external material into a LyX document.

fwiw, i'd rather be able to drag-n-drop


Please, try the attached (preliminary) patch.

If you drag'n'drop at least .eps, .fig, .dia, .png files, then they get 
automatically inserted as InsetGraphics, and immediately previewed in 
LyX. If you drag'n'drop a .lyx file, then it is regularly opened.


Is this that you meant ?

And, the funny part, is that the patch was *mainly a removal of code*. 
Comments ?


T.

Index: src/frontends/qt4/GuiView.cpp
===
--- src/frontends/qt4/GuiView.cpp	(revisione 39381)
+++ src/frontends/qt4/GuiView.cpp	(copia locale)
@@ -893,12 +893,10 @@
 		vector found_formats;
 
 		// Find all formats that have the correct extension.
-		vector const & import_formats
-			= theConverters().importableFormats();
-		vector::const_iterator it = import_formats.begin();
-		for (; it != import_formats.end(); ++it)
-			if ((*it)->extension() == ext)
-found_formats.push_back(*it);
+		Formats::const_iterator it = formats.begin();
+		for (; it != formats.end(); ++it)
+			if (it->extension() == ext && it->name() != "lyx")
+found_formats.push_back(&(*it));
 
 		FuncRequest cmd;
 		if (found_formats.size() >= 1) {
@@ -2087,6 +2085,19 @@
 	if (filename.empty())
 		return;
 
+	FileName fname(filename);
+	if (formats.getFormatFromFile(fname) != "lyx") {
+		if (!currentBufferView()) {
+			Alert::warning(_("Error"), _("Need an open document where to insert"));
+			return;
+		}
+		string args = string("graphics filename ") + filename;
+		FuncRequest cmd(LFUN_INSET_INSERT, args);
+		LYXERR(Debug::DEBUG, "Dispatching: " << cmd);
+		lyx::dispatch(cmd);
+		return;
+	}
+
 	// get absolute path of file
 	FileName const fullname(support::makeAbsPath(filename));
 

Re: Image Lifecycle (Create) Patch - Video

[Tommaso Cucinotta]

Il 29/07/2011 01:19, Tommaso Cucinotta ha scritto:

Il 28/07/2011 17:29, Edwin Leuven ha scritto:

Tommaso Cucinotta  wrote:

  This patch allows one to quickly insert new images
  and other type of external material into a LyX document.

fwiw, i'd rather be able to drag-n-drop


Please, try the attached (preliminary) patch.


btw, there was also another patch by vfr on the Trac for this:

   http://www.lyx.org/trac/ticket/4017

Bye,

T.