Re: External material/graphics empty samples
Tommaso Cucinotta wrote: Il 23/07/2011 21:14, Pavel Sanda ha scritto: hmm and where is the edit button? :) there's no edit button in that dialog. The LyX workflow would be: 1) insert-external material... 2) fill details in the dialog, click Ok 3) right-click on the previewed image, choose Edit... this looks strange. context menu is nice but shouldn't be replacement for dialog. another strange thing, how is that i can't go to size tab for figure files now? what is the size tab ? when you go to the external material dialog, there are three tabs on the top. the third one for size rotation is always disabled no matter what i do. do you see it as well? So, my question: does it make sense to have these 2 separate insets ? to me yes. spreadsheat table is no graphics material. secondly its kind of API for people who want to develop their own external material. pavel
Re: about the initials module
Guenter Milde wrote: On 2011-07-25, Uwe Stöhr wrote: Independent of all your points, LyX should be designed for the average user. And he doesn't know the LaTeX internals. LyX was once invented to keep the LaTeX fiddling away from the users and this should be our aim also for the future. its actually very dependent on my points, since they define average user to have different profile. I'd rather say the aim is to help the user using LaTeX, not to keep it away from her/him. yes. pavel
Re: Translation mess in display-window
Kornel wrote: Hi, we have here some inconsistences. Appended picture shows a document whose language is set to german and the UI set to english. We see here, that the description of Table note and NoteToEditor-(inset?) are displayed in german, but inserted New Page and Marginal Note are displayed in ui-language. Also changing the NoteToEditor part to another language will change the appropriate display only on *next* lyx-run. This seems rather confusing. I would prefer everything be displayed in same language. I for one would prefer the ui-language. if the document language is set to german, then it make sense that environments (eg Abstract is translated into that language) since it will be like this in the output. on the other hand it makes sense to have structure-only info (like margin/new-page) in ui-language, since the user might not know about the language of the document. i see your point for environments which do not go into the output, but i'm not sure how to fix it in a sane way. pavel
Re: cmd-line conversion of gnumeric and ods files.
Tommaso Cucinotta wrote: 1) AFAICS, there's really no reason for keeping .dia drawings as templates. for the particular case of dia the distinction makes no big sense indeed, its more of letting user to know that we do support dia at all... (another point was to distinguish drawing formats we support out of the box with imagemagick and which require external tools, like dia. we have already broken this with eg .svg though.) pavel
Re: Image Lifecycle (Create) Patch - Video
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: SV: Towards RC4/final release
Jürgen Spitzmüller wrote Helge Hafting wrote: In this particular case, it looks like no extra GUI is needed at all, only programming. The GUI is present already: Currently, the running header paragraph types becomes available when the user selects the module. All we need then, is to remove the module from the module list, and tie it to headings style == fancy instead. IMHO, the header definition should not be done with paragraph styles (as the module does), but rather in the document dialog. Paragraph styles more flexible - because the user may want to change the running headers throughout the document. You don't get that with a definition in the document dialog. For example - different running headers in different parts, or blank headers in the preface. Also, the paragraph style (or a flex inset, if that is deemed better) automatically gives the user access to anything that LytX support. Want a logo or two? Insert-Graphics. An URL or even math? Simple. A weird latex construct? Possible if you want it. Many people want automatic headers (running headers), not some hardcoded strings. I do not think this can be achieved elegantly with the paragraph style based approach. Furthermore, we Do you mean things like page numbers and \leftmark, \rightmark? Currently ERT, but insets for these shouldn't be hard to make. should provide some customization possibilites. Also something we need the dialog for. Then, we should consider class specific issues (classes such as KOMA and memoir ship their own header interfaces that should be used instead of fancyhdr). I agree - fancyhdr is just one part of this. For other cases, it seems that LyX is moving tovards modules so powerful that a lot of things might not need any other GUI. I really hope you're wrong. Seems I wrote that too fast. To be precise - styles are getting more powerful. And they can be used by modules and/or the core styles distributed with LyX. Any LaTeX command/environment that takes exactly one parameter - the text inside it - can already be implemented as a style. So there seem to be less need for separate code supporting footnote and similiar things. There seems to be work on styles that take arguments, that would allow more things to be specified as a style, for example things like boxes. Whether to separate such things out in modules or not is a separate question. Things go in a module if it isn't natural to have it available for every document of the same class. Otherwise, it'll be part of the document class. Possibly shared with other document classes through the include mechanism. Helge Hafting
Re: SV: Towards RC4/final release
Helge Hafting wrote: IMHO, the header definition should not be done with paragraph styles (as the module does), but rather in the document dialog. Paragraph styles more flexible - because the user may want to change the running headers throughout the document. You don't get that with a definition in the document dialog. You'll need to implement a framework for different heading styles. For example - different running headers in different parts, or blank headers in the preface. But this should not be done with hardcoded \markboth definitions, but rather with structural means, i.e. things such as \frontmatter an \myheading. In general, I think your approach encourages physical markup and manual strucutring, whereas LyX should rather encourage semantic markup and structuring. At least this used to be one of LyX's main aims. Also, the paragraph style (or a flex inset, if that is deemed better) automatically gives the user access to anything that LytX support. Want a logo or two? Insert-Graphics. An URL or even math? Simple. A weird latex construct? Possible if you want it. All this is also possible with a dialog. Many people want automatic headers (running headers), not some hardcoded strings. I do not think this can be achieved elegantly with the paragraph style based approach. Furthermore, we Do you mean things like page numbers and \leftmark, \rightmark? Currently ERT, but insets for these shouldn't be hard to make. I think inset is the wrong approach. IMHO the most common (or at least the most sensible, for common documents) use case is the use of automatic running headers. Manual headers should only be used if automatic means do not provide a solution. A decent GUI should not urge you to insert some weird insets to the main body, but let you select from some sane possibilities. Imagine a heading style definition dialog such as: - Page Style name: [My Page Style] Header: First chapter page: [empty] [empty] [empty] [ ] Line above [ ] Line below Even page: [empty] [section title] [empty] [ ] Line above [x] Line below Odd page: [empty] [chapter title] [empty] [ ] Line above [x] Line below Footer: First chapter page: [empty] [empty] [empty] [ ] Line above [ ] Line below Even page: [empty] [pagination] [empty] [ ] Line above [ ] Line below Odd page: [empty] [pagination] [empty] [ ] Line above [ ] Line below - Instead of section title or pagination, you can also select and insert custom text (and others). And you can define as many page styles as you want. Then you select [My Page Style] in Document Settings Page Layout, if you want this to be your global style. To switch styles inbetween the document, select from the menu Document Change page style My other page style, the way that you start an appendix nowadays. Jürgen
Re: cmd-line conversion of gnumeric and ods files.
Il 29/07/2011 10:55, Pavel Sanda ha scritto: Tommaso Cucinotta wrote: 1) AFAICS, there's really no reason for keeping .dia drawings as templates. for the particular case of dia the distinction makes no big sense indeed, its more of letting user to know that we do support dia at all... I see - this would be addressable via a selection combo-box in the GuiGraphics dialog which could be very similar to the one you have in the GuiExternal dialog. So, the unexperienced user would simply type a tentative name for the new graphics, choose from the combo the type (and he/she would see we have .dia, and choosing it we'd have a short description saying its a vectorial graphics editor [or it could come through a tooltip]), then go for Create/Edit and proceed. (another point was to distinguish drawing formats we support out of the box with imagemagick and which require external tools, like dia. we have already broken this with eg .svg though.) Isn't ImageMagick an external tool as well ? Btw, the key point is making the user aware of (at least) the open-source tools that can be used along with LyX, for a better document writing experience. This could be documented in the user guide, plus in Debian- based packages of LyX we could have the suggested dependencies enumerating the supported editors/viewers/converters (as I'm seeing we already have). T.
Re: External material/graphics empty samples
Il 29/07/2011 10:30, Pavel Sanda ha scritto:
So, my question: does it make sense to have these 2 separate insets ?
to me yes. spreadsheat table is no graphics material.
secondly its kind of API for people who want to develop their own external
material.
Thanks for your comments, Pavel.
If you had a look at those 2 patches (images and ext material), I had a
common need, i.e., the patch below.
Do you think it may be a safe/right one, or might it be dangerous or
have unforeseeable side effects ?
Thanks,
T.
Index: src/Format.cpp
===
--- src/Format.cpp (revisione 39372)
+++ src/Format.cpp (copia locale)
@@ -128,15 +128,25 @@
}
+/// For a zipped format, try the filename extension first, then the contents
+/// (otherwise it is always guessed as zip and we're in trouble)
string Formats::getFormatFromFile(FileName const filename) const
{
if (filename.empty())
return string();
- string const format = filename.guessFormatFromContents();
- if (!format.empty())
- return format;
+ string const ex = filename.extension();
+ bool zipped_format = (ex == odg || ex == sxd
+ || ex == odt || ex == sxw || ex == docx
+ || ex == ods || ex == sxc || ex == xlsx
+ || ex == gnumeric);
+ if (!zipped_format) {
+ string const format = filename.guessFormatFromContents();
+ if (!format.empty())
+ return format;
+ }
+
// try to find a format from the file extension.
string const ext = getExtension(filename.absFileName());
if (!ext.empty()) {
@@ -151,6 +161,12 @@
return cit-name();
}
}
+
+ if (zipped_format) {
+ string const format = filename.guessFormatFromContents();
+ if (!format.empty())
+ return format;
+ }
return string();
}
Re: Image Lifecycle (Create) Patch - Video
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
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: External material/graphics empty samples
Tommaso Cucinotta wrote: > Il 23/07/2011 21:14, Pavel Sanda ha scritto: >> hmm and where is the edit button? :) > > there's no edit button in that dialog. The LyX workflow would be: > 1) insert->external material... > 2) fill details in the dialog, click Ok > 3) right-click on the previewed image, choose Edit... this looks strange. context menu is nice but shouldn't be replacement for dialog. >> another strange thing, how is that i can't go to size tab for figure files >> now? > > what is the "size tab" ? when you go to the external material dialog, there are three tabs on the top. the third one for size rotation is always disabled no matter what i do. do you see it as well? > So, my question: does it make sense to have these 2 separate insets ? to me yes. spreadsheat table is no graphics material. secondly its kind of API for people who want to develop their own external material. pavel
Re: about the initials module
Guenter Milde wrote: > On 2011-07-25, Uwe Stöhr wrote: > > > Independent of all your points, LyX should be designed for the average > > user. And he doesn't know the LaTeX internals. LyX was once invented to > > keep the LaTeX fiddling away from the users and this should be our aim > > also for the future. its actually very dependent on my points, since they define average user to have different profile. > I'd rather say the aim is to help the user using LaTeX, not to keep it away > from her/him. yes. pavel
Re: Translation mess in display-window
Kornel wrote: > Hi, > we have here some inconsistences. > Appended picture shows a document whose language is set to german and the UI > set to english. > > We see here, that the description of "Table note" and "NoteToEditor"-(inset?) > are displayed in german, but inserted > "New Page" and "Marginal Note" are displayed in ui-language. > Also changing the "NoteToEditor" part to another language will change the > appropriate display only on *next* lyx-run. > > This seems rather confusing. I would prefer everything be displayed in same > language. I for one would prefer the ui-language. if the document language is set to german, then it make sense that environments (eg Abstract is translated into that language) since it will be like this in the output. on the other hand it makes sense to have structure-only info (like "margin"/"new-page") in ui-language, since the user might not know about the language of the document. i see your point for environments which do not go into the output, but i'm not sure how to fix it in a sane way. pavel
Re: cmd-line conversion of gnumeric and ods files.
Tommaso Cucinotta wrote: > 1) AFAICS, there's really no reason for keeping .dia drawings as templates. for the particular case of dia the distinction makes no big sense indeed, its more of letting user to know that we do support dia at all... (another point was to distinguish drawing formats we support out of the box with imagemagick and which require external tools, like dia. we have already broken this with eg .svg though.) pavel
Re: Image Lifecycle (Create) Patch - Video
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: SV: Towards RC4/final release
Jürgen Spitzmüller wrote >Helge Hafting wrote: >> In this particular case, it looks like no extra GUI is needed at all, >> only programming. The GUI is present already: >> >> Currently, the running header paragraph types becomes available when the >> user selects the module. All we need then, is to remove the module >> from the module list, and tie it to "headings style == fancy" instead. > >IMHO, the header definition should not be done with paragraph styles (as the >module does), but rather in the document dialog. Paragraph styles more flexible - because the user may want to change the running headers throughout the document. You don't get that with a definition in the document dialog. For example - different running headers in different parts, or blank headers in the preface. Also, the paragraph style (or a flex inset, if that is deemed better) automatically gives the user access to anything that LytX support. Want a logo or two? Insert->Graphics. An URL or even math? Simple. A weird latex construct? Possible if you want it. >Many people want automatic >headers (running headers), not some hardcoded strings. I do not think this can >be achieved elegantly with the paragraph style based approach. Furthermore, we Do you mean things like page numbers and \leftmark, \rightmark? Currently ERT, but insets for these shouldn't be hard to make. >should provide some customization possibilites. Also something we need the >dialog for. >Then, we should consider class specific issues (classes such as KOMA and >memoir ship their own header interfaces that should be used instead of >fancyhdr). I agree - fancyhdr is just one part of this. > >> For other cases, it seems that LyX is moving tovards modules so powerful >> that a lot of things might not need any other GUI. > >I really hope you're wrong. Seems I wrote that too fast. To be precise - styles are getting more powerful. And they can be used by modules and/or the core styles distributed with LyX. Any LaTeX command/environment that takes exactly one parameter - the text inside it - can already be implemented as a style. So there seem to be less need for separate code supporting "footnote" and similiar things. There seems to be work on styles that take arguments, that would allow more things to be specified as a style, for example things like boxes. Whether to separate such things out in modules or not is a separate question. Things go in a module if it isn't natural to have it available for every document of the same class. Otherwise, it'll be part of the document class. Possibly shared with other document classes through the include mechanism. Helge Hafting
Re: SV: Towards RC4/final release
Helge Hafting wrote: > >IMHO, the header definition should not be done with paragraph styles (as > >the module does), but rather in the document dialog. > > Paragraph styles more flexible - because the user may want to change the > running headers throughout the document. You don't get that with a > definition in the document dialog. You'll need to implement a framework for different heading styles. > For example - different running headers in different parts, or > blank headers in the preface. But this should not be done with hardcoded \markboth definitions, but rather with structural means, i.e. things such as \frontmatter an \myheading. In general, I think your approach encourages physical markup and manual strucutring, whereas LyX should rather encourage semantic markup and structuring. At least this used to be one of LyX's main aims. > Also, the paragraph style (or a flex inset, if that is deemed better) > automatically gives the user access > to anything that LytX support. Want a logo or two? Insert->Graphics. An URL > or even math? Simple. A weird latex construct? Possible if you want it. All this is also possible with a dialog. > >Many people want automatic > >headers (running headers), not some hardcoded strings. I do not think this > >can be achieved elegantly with the paragraph style based approach. > >Furthermore, we > Do you mean things like page numbers and \leftmark, \rightmark? Currently > ERT, but insets for these shouldn't be hard to make. I think inset is the wrong approach. IMHO the most common (or at least the most sensible, for common documents) use case is the use of automatic running headers. Manual headers should only be used if automatic means do not provide a solution. A decent GUI should not urge you to insert some weird insets to the main body, but let you select from some sane possibilities. Imagine a heading style definition dialog such as: - Page Style name: [My Page Style] Header: First chapter page: [empty] [empty] [empty] [ ] Line above [ ] Line below Even page: [empty] [section title] [empty] [ ] Line above [x] Line below Odd page: [empty] [chapter title] [empty] [ ] Line above [x] Line below Footer: First chapter page: [empty] [empty] [empty] [ ] Line above [ ] Line below Even page: [empty] [pagination] [empty] [ ] Line above [ ] Line below Odd page: [empty] [pagination] [empty] [ ] Line above [ ] Line below - Instead of "section title" or "pagination", you can also select and insert custom text (and others). And you can define as many "page styles" as you want. Then you select [My Page Style] in Document > Settings > Page Layout, if you want this to be your global style. To switch styles inbetween the document, select from the menu Document > Change page style > My other page style, the way that you start an appendix nowadays. Jürgen
Re: cmd-line conversion of gnumeric and ods files.
Il 29/07/2011 10:55, Pavel Sanda ha scritto: Tommaso Cucinotta wrote: 1) AFAICS, there's really no reason for keeping .dia drawings as templates. for the particular case of dia the distinction makes no big sense indeed, its more of letting user to know that we do support dia at all... I see - this would be addressable via a selection combo-box in the GuiGraphics dialog which could be very similar to the one you have in the GuiExternal dialog. So, the unexperienced user would simply type a tentative name for the new graphics, choose from the combo the type (and he/she would see we have .dia, and choosing it we'd have a short description saying its a vectorial graphics editor [or it could come through a tooltip]), then go for Create/Edit and proceed. (another point was to distinguish drawing formats we support out of the box with imagemagick and which require external tools, like dia. we have already broken this with eg .svg though.) Isn't ImageMagick an external tool as well ? Btw, the key point is making the user aware of (at least) the open-source tools that can be used along with LyX, for a better document writing experience. This could be documented in the user guide, plus in Debian- based packages of LyX we could have the "suggested" dependencies enumerating the supported editors/viewers/converters (as I'm seeing we already have). T.
Re: External material/graphics empty samples
Il 29/07/2011 10:30, Pavel Sanda ha scritto:
So, my question: does it make sense to have these 2 separate insets ?
to me yes. spreadsheat table is no graphics material.
secondly its kind of API for people who want to develop their own external
material.
Thanks for your comments, Pavel.
If you had a look at those 2 patches (images and ext material), I had a
common need, i.e., the patch below.
Do you think it may be a safe/right one, or might it be dangerous or
have unforeseeable side effects ?
Thanks,
T.
Index: src/Format.cpp
===
--- src/Format.cpp (revisione 39372)
+++ src/Format.cpp (copia locale)
@@ -128,15 +128,25 @@
}
+/// For a zipped format, try the filename extension first, then the contents
+/// (otherwise it is always guessed as zip and we're in trouble)
string Formats::getFormatFromFile(FileName const& filename) const
{
if (filename.empty())
return string();
- string const format = filename.guessFormatFromContents();
- if (!format.empty())
- return format;
+ string const& ex = filename.extension();
+ bool zipped_format = (ex == "odg" || ex == "sxd"
+ || ex == "odt" || ex == "sxw" || ex == "docx"
+ || ex == "ods" || ex == "sxc" || ex == "xlsx"
+ || ex == "gnumeric");
+ if (!zipped_format) {
+ string const format = filename.guessFormatFromContents();
+ if (!format.empty())
+ return format;
+ }
+
// try to find a format from the file extension.
string const ext = getExtension(filename.absFileName());
if (!ext.empty()) {
@@ -151,6 +161,12 @@
return cit->name();
}
}
+
+ if (zipped_format) {
+ string const format = filename.guessFormatFromContents();
+ if (!format.empty())
+ return format;
+ }
return string();
}
Re: Image Lifecycle (Create) Patch - Video
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
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. >
